polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: toValue() & toEntity()
Date Sat, 23 May 2015 03:15:23 GMT
On Fri, May 22, 2015 at 5:01 PM, Paul Merlin <paul@nosphere.org> 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".
> > 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...

Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message