Gang, I have been working on putting this feature into the core, and a few things have turned up which needs a bit discussion.
1. I placed the methods in Qi4jSPI, since many similar methods are located there. But since a UnitOfWork is required for both methods, wouldn't it make more sense to place them in the UnitOfWork interface?? 2. Now we can have Associations in Values.... but we can't populate them. Currently, when one try to set any of the Associations with a Value, the runtime traps this as the object not being an EntityComposite. This surfaced when trying to put into a test the semantics of how associations should be handled. Can't set the association from a builder, only from the toValue() method. So, before discussing semantics, should the builder logic be changed to only require "implements Identity"?? 3. Semantically, I don't think that the toEntity() should bother to validate (or modify) the referenced entity with the value held in the Association, just take the Identity as-is. I am thinking of the Rest API usecae, where the toValue() would only pass the identity back to the client, which avoids "pulling in everything". HOWEVER, it might make sense to make a distinction between a regular Association and an @Aggregated one... Cheers -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
