A knowledge-base article has one section and may have multiple tags. A section needs a reference in the article; tags need a join table. Configure both in Generator UI and see their generated-application behavior below.
An article belongs to a section
Select Article in Content, click Create relation → Many-to-one, and choose target Section. The editor creates a reference field, such as sectionId, and its owning relationship.
Choose Required if every article needs a section, otherwise Optional. This coordinates field/relationship requirements. Select title as the section label so authors see names rather than technical identifiers.
Check target, requirement and display name in Basic settings. Advanced settings contains physical keys and database policies; change these with the schema in mind. Finish and wait for the list to update.
To edit later, open the FK field or Relations tag. Save field saves the field, owning relationship and selected inverse-view changes together. Do not create a second belongsTo for the same reference.
Display articles inside a section
Add One-to-many view to Section. This inverse view shows articles whose sectionId points to the current section. Choose the existing owning relationship on Article; no additional foreign key is created.
When changing an owner or target, choose inverse-collection handling: Keep unchanged, Update with this relationship, or Remove. On a move, separately inspect the old address that will disappear.
If the required FK field is missing, return to the owner and fix the model. The list does not fabricate arbitrary missing fields.
Add multiple tags
Choose Many-to-many between Article and Tag. Basic selects the target and tag display field. Advanced configures the join table and keys. sourceField and targetField are entity primary keys, not join-table columns.
Choose one owner: its form edits tag membership. An inverse name on Tag creates neither another owner nor another table. Set inverseDisplayField for readable inverse labels; For Tag.articles, Article.title is usually suitable.
inverseName defines the inverse model name, not membership-editing permission. The many-to-many inverse view remains read-only.
After Generate
Finish saves the relationship in the manifest. Generate, apply migrations and restart to use it in the application. Sections can be selected by name; options load asynchronously with bounded results. Related records opens inverse collections. Viewing them requires related-record read permissions, not update permissions.
An empty optional field means no relationship selected. Wait while the label loads. An unavailable-record message means the selected section cannot be read; retry after request errors. Never replace an unknown record with an invented label.
Saving, deletion and errors
Collection editors have Basic/Advanced tabs and fixed Cancel / Delete / Finish buttons. Switching tabs retains input. A Finish validation error opens the relevant tab. Delete needs separate confirmation and does not save other edits.
The editor cannot close while saving. With unsaved changes, Cancel/close asks whether to continue editing or discard. Refresh after revision conflicts. For an unknown save result, Refresh and check before repeating Create.
See relationship models for foreign-key policies and prohibited physical changes.
Optional: CLI
Automate these actions with relationship CLI.
Complete editor reference
All parameters are in Content: relationships. See relationship models for foreign-key structure.