Property Translation Ordering

[geoffreywiseman]

It can be important that properties be translated in a particular order, particularly when dealing with the translation cache.

This example comes from a client project:

• An application domain object refers to an insurance application.
• These applications can be grouped together, and when they are, the application contains a reference to the group.
• The group contains references to all of the applications within that group, and they're stored in a map structure indexed by the primary id of the application.

When you translate an application that belongs to a group, you start translating an application, "A", which refers to group "G". When translating the map containing "G"'s members, a reference back to "A" will result in a hit on the translation cache. However, A's primary key may not have been translated, and if the translation results in reindexing the map, A's lack of a primary key could cause the translated map to have a null key.

This specific scenario could be resolved by informing Moo that you would like it to translate the application's id before it translates the application's group. Unfortunately, there is no way to indicate desired ordering or bump the priority of a particular property, which means that this scenario must be avoided, or corrected after the translation is complete.

[geoffreywiseman]

This is not likely to affect simple use cases of Moo; it took nearly three years for this scenario to arise in the client project. That said, when confronted with this situation, it would be nice to have a way of addressing it with Moo rather than forcing you to refactor your existing object structure/code or add additional post-translation logic to correct a translation weakness.

What's the right way of dealing with this? Explicit ordering options like sequence numbers? Some kind of happens-before marking? Simply a way of marking a few properties as "do these first"? There's some tradeoff here between making this a solveable problem and making the configuration options too complicated that needs to be managed carefully, particularly since this is probably not a common need.

[geoffreywiseman]

This could potentially be solved by supporting a contructor option (see #13), although in practice, many domain objects support adding the id later, since it might be derived from the database (sequence, autonumber).

Another option that might go a long way is to ensure that we translate from higher on the class hierarchy on down to lower (superclasses first, essentially). This would solve id-like problems in many cases, simply because they're often inherited from some superclass.

That might be a good stop-gap measure that would solve a lot of potential problems without requiring more complex ordering capabilities.