On Fri, May 22, 2015 at 5:01 PM, Paul Merlin <[email protected]> wrote:
> Niclas Hedhman a écrit : > > 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?? > It would make more sense, indeed. > > > 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"?? > What I understand here is that builders would accept any type that > implements Identity to set Associations. For now it only accept > EntityComposites. > This could prove useful for the usecases that drive this discussion. It > would also allow to set Associations with Value types that do not have > an Entity type counterpart. This is not new as type constraints don't > prevent using any object that implement the associated type even if it's > not a composite, but would obviously fail at runtime. > Yes that is correct. > What about composites whose Identity impl comes from a private mixin? > Well, for Entities, this is not possible. Since module.entities( Abc.class )... will ensure that the resulting Composite indeed implements EntityComposite, which is a subtype of Identity. The way the State is handled internally to the Composite, any "@This Identity id;" reference which users may perceive as a private mixin, will be the same Identity as the one implicitly introduced in the above method call. So, for any existing code, I don't think there is an issue. For non-entities, I think it is a non-issue and we simply require values to have public Identities. > 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". > LGTM > > > HOWEVER, it might make sense to make a distinction between a regular > > Association and an @Aggregated one... > Do you mean that (de)serialization of @Aggregated associations should > traverse them instead of only handling identities? > Yes, that is a possible semantic option, which *I* don't have a strong opinion about yet. But if we relate @Aggregated to the Aggregate concept in DDD, which effectively requires that operations on Aggregates (but only on Aggregates) to be atomic, then it would make sense to traverse the entire entity graph and convert to Values... Cheers -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
