Four relationship types, always as a pair
A relationship connects two models: an order belongs to a customer, a customer has many orders. In the Hub you create one side, and the opposite side is created automatically with the matching inverse type. Remove one side and the other goes with it.
- 1:1 – exactly one object on each side
- 1:n and n:1 – one object has many, many belong to one
- n:m – many on both sides, such as groups and roles
What a relationship allows
When writing, Data Management sets both ends itself. You write a link from whichever side suits your use case and see it from both sides when reading.
By default a request may only link through a relationship, that is, point to an existing object. Creating, updating and deleting related objects along the way must be enabled explicitly per relationship. Parts of a whole – the line items of an invoice – typically get all three, references to independent things – the customer of an invoice – get none.
Every related object is checked against the permissions of its own model. Anyone creating employees through a company also needs the right to create employees – or a role that grants exactly this path.
Nested writes, all or nothing
An invoice with its line items, a company with new employees: you write what belongs together in one request. An entry without an identifier is created, one with an identifier is updated or only linked – depending on what the relationship allows. If a single child fails a rule or a permission check, nothing is saved, not even the parent.
A list describes the state afterwards. Whatever is no longer in it is unlinked or – for dependent parts – deleted. Deletion also walks every relationship: dependent children are deleted along with the parent, all others are only unlinked. If the delete permission is missing for a single child, everything stays as it was.
Links with their own data
If an n:m link needs data of its own – since when, in which function – you define it as a separate link model with two references and its own fields. For simple assignments the n:m relationship is enough.
When reading, Data Management follows relationships only as deep as the request asks. When writing, it processes every object in a request exactly once. Nesting can never go round in circles.
What this means day to day
Relationships become a property of the model instead of manual work in every service.
- No half-saved transactions: parent and parts are created together or not at all.
- Back-references do not have to be maintained by hand.
- Cascading deletion is a deliberate decision on the model, not a surprise in the code.