polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: toValue() & toEntity()
Date Fri, 22 May 2015 09:01:00 GMT
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
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.

What about composites whose Identity impl comes from a private mixin?

> 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?


View raw message