Ordering of relationship updates

[tdmartin102]

Lets say you MOVE a member of a to-one relationship from one owner to another. If the integrity rule is to nullify on removal then the ORDER in which the update occurs is critical. It would have to do the remove first and the add second. If the order was add first and remove second, the nullify rule would cause the to-one undone. The way things work now, it goes through the owning objects one at a time and updates all relationships. There IS no ordering. I suspect this may even be the case in EOF. The only way to fix this would be to resolve relationships in a separate pass after all objects in all contexts have been updated from the objects. BUT, this may be difficult without breaking the API. This situation applies to all relationships: to-one, to-many and many-to-many.

[tdmartin102]

I propose adding a phase. Right now in the EODatabaseContext there is recordChangesInEdintgContext where the EODatabsaeOperation objects are created, and then there is performChanges where the EOAdaptorOperations are created and then executed. currently relationships are resolved in EODatabaseOperation. I think there needs to be a step between the two where relationships are set, NOT in recordChangesInEditingContext. It would need to be a separate task so that when there are multiple databaseContexts it could be called after all databaseContexts are finished creating databaseOperations. There may be an alternative way of doing this such as pushing the update into performChanges, but this seems inappropriate to me.

[tdmartin102]

Okay, this is NOT how I dealt with this, which is good, because the above idea would have caused major changes. It would be difficult to describe how it was handled, but basically it was solved by creating a relationship change dictionary and processing the remove objects before the insert objects.