Self-reference 1:1 limitations in Mendix: a case study of a symmetric relationship

0
​When trying to model a symmetric one-to-one self-referencing association, I encountered a structural limitation in Mendix. I would like to confirm whether this is an inherent platform constraint, or whether there is a design pattern that can achieve the desired behaviour in a clean and maintainable way.   The goal is to model a relationship between two instances of the same entity (Person), where each person can have exactly one associated person (e.g. a partner). This relationship should be symmetric - if Person A is related to Person B, Person B should automatically be related to Person A - and editable from either side, meaning either person should be able to establish, update or remove the relationship.   Mendix does not allow the creation of a one-to-one self-referencing association. When defining an association from 'Person' to 'Person', the only available options are 'one-to-many' or 'many-to-many'. The platform does not offer a one-to-one option, making it impossible to represent this type of relationship directly at the domain model level.   This forces developers to use workarounds, but both common approaches I have explored introduce unnecessary complexity or asymmetry.   One option is to create a self-reference with many-to-many relationships and enforce the 'only one related person' rule through validation logic. However, this approach introduces an important asymmetry due to Mendix's ownership model for associations.   Even in a many-to-many setup, Mendix requires an owner side to be defined for the association. Only the owner side can modify the association directly using the 'Change Object' or 'Change List' actions. The non-owner side can only view the association and cannot modify it without custom logic.   As a result: If Person A (the owner) sets Person B as their partner, it works as expected. If Person B tries to set Person A as their partner, additional logic is required to determine which side owns the association and to perform the update accordingly.   This means that every operation depends on which side owns the association, forcing the use of helper microflows to set or clear the association and reverse lookups to read from the non-owner side. The result is an asymmetric and cumbersome model for what should be a simple two-way relationship.   The alternative is to introduce an intermediate entity, for example Partnership, with two one-to-many associations to Person:   Person (Partner 1) ← Partnership → Person (Partner 2)   This effectively simulates a one-to-one relationship between persons, but it adds significant complexity in both data management and transactional logic.   Creating or modifying a relationship now involves at least three entities: The Partnership entity itself Both Person objects linked to it   Handling persistence and deletion becomes more complicated. If a user modifies a relationship from a form without committing the related Person first, it is possible to create orphaned Partnership records or references to uncommitted objects. Additional event handlers (Before Delete, After Delete) are needed to maintain referential integrity. Validation logic is required to ensure both sides are always set, and deletions or rollbacks must be handled explicitly.   From a query perspective, retrieving related persons now requires an additional join through the intermediate entity, which adds overhead for what conceptually is a single-column foreign key relationship.   In traditional relational databases, this scenario is straightforward. A self-referencing one-to-one relationship can be implemented by adding a unique foreign key constraint to the same table, for example: ALTER TABLE Person ADD CONSTRAINT fk_partner FOREIGN KEY (PartnerId) REFERENCES Person(Id) UNIQUE; This approach ensures that each person can reference at most one other person, and that the reference is unique. While application-level logic is still needed to enforce symmetry (so both sides point to each other), the database-level model is clean and simple.   Mendix, however, does not allow such a configuration at the model level, even though the underlying database would support it. This suggests that the limitation is within the Mendix metamodel rather than the database itself.   Has anyone identified a maintainable and reliable pattern in Mendix for implementing a symmetric one-to-one self-referencing relationship?   Both of the approaches described above (many-to-many with validation, or intermediate entity) appear to introduce unnecessary complexity and do not provide a fully symmetric behavior.   If there is no established solution, is this considered an accepted limitation of the platform that must be worked around through custom logic?
asked
2 answers
0

I see what you're getting at, but I also think the situation is rare. Most of the time an object will both be on the parent and the child side of a self reference, between different objects. In your particular case, it seems logical to have a unique association between partners. But:

- what if someone had a divorce or the partner died, and remarries? Now there are multiple partners, or you lose the link with the former partner.

- what if polygamy or polyandry is allowed? Also multiple partners.

 

So especially in this partnership/marriage case, I'd say the extra entity is preferable. It can then also contain the start/end date of the relationship etc.

 

The question in itself is still valid of course, so maybe others can step in to weigh alternatives for unique self-references.

answered
0

Indeed partner should be imho be a one to many relation. But why not create partner that inherits from person and set a one to one relation with that object?

Regards,

Ronald

 

answered