toValue() & toEntity()

[Niclas Hedhman <ni...@hedhman.org>]

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

Re: toValue() & toEntity()

[Paul Merlin <pa...@nosphere.org>]

Niclas Hedhman a écrit :
>> 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.
Roger that.

>  > 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...
At first sight I can't see why this could be problematic. And yes,
closer to DDD.

As a side note, the ElasticSearch state indexer do something like this
to record @Aggregated entities in order to ease traversal queries
generation.

What do you others think about this?

/Paul

Re: toValue() & toEntity()

[Niclas Hedhman <ni...@hedhman.org>]

On Fri, May 22, 2015 at 5:01 PM, Paul Merlin <pa...@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".
> 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

Re: toValue() & toEntity()

[Paul Merlin <pa...@nosphere.org>]

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.

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

/Paul