Gang, (my Christmas present to you all)
I have a series of upcoming demands to support entity-local
identities, and in some cases the number of entities are numerous, in
the 1000s of the aggregating entity. Worse is that I don't really
control the implementation, downstream developers will make the domain
models, and I want to make their experience the best.
One option is to do Identity mangling, having semantics built into the
identity string itself, and build some kind of support library that
deals with this. But that feels like a hack, and I would like to
tackle this at the root itself; Support for entity-local identities.
I would like to present the following suggestion for further discussion;
Let's look at an Entity with two types of associations, both aggregated;
public interface Car
{
@Aggregated
Assocation<Tyre> leftFrontTyre();
@Aggregated
ManyAssociation<Cable> cables();
}
For Association, the local identity is in the qualified name of the
Association itself, and the creation of it should simply be tied to
the association itself;
EntityBuilder<Tyre> builder = leftFrontTyre().newEntityBuilder();
builder.newInstance();
I think this is much more straight forward than something like;
EntityBuilder<Tyre> builder = uow.newEntityBuilder( Tyre.class,
identity.get() + "/leftFrontTyre" );
leftFrontTyre().set( builder.newInstance() );
The underlying implementation *could* be doing the above, but more
about that later.
For ManyAssocations (which is my actual usecases)
EntityBuilder<Cable> builder = cables().newEntityBuilder( "Ignition - Red" );
builder.newInstance();
To do the creation with identity mangling;
EntityBuilder<Cable> builder = uow.newEntityBuilder( Cable.class,
identity.get() + "/cables/Ignition - Red" );
cables().add( builder.newInstance() );
It requires quite a lot of documentation for managing the identities
within the team, as the number of entities (and its aggregated
entities) grows.
I think the @Aggregated should be required, as I can't see a need for
this for non-Aggregated ones.
I think that for Association, no other new methods would be needed
(beyond newEntityBuilder() ).
For ManyAssocation, we should also add method;
T get( String localIdentity );
To locate an Entity quickly within the collection.
On the implementation front, there are several ways to do this. The
simple solution is just to work with mangled identities, i.e. if the
identity of the Car = "123", then the Batter cable would end up
something like;
123+org.hedhman.niclas.Car.cables+Battery - Red Cable
But that opens up issues with which characters are allowed in
identity() and so on, which feels like hack to me.
A more advanced approach is to start investigating whether Identity
being a simple string is a good choice.
We could potentially support derived Identity types, and one such type
for Aggregated identity types. I think a straight forward approach
would to make the Identity into a ValueComposite, and utilize toJSON()
for DB level format. Some serious consideration needed for
compatibility with existing entities...
If Identities are changed to be ValueComposites, I think that the
above can be implemented quite neatly, where
public interface AggregationIdentity extends IdentityValueComposite
{
Property<String> aggregate();
Property<String> member();
}
public interface ManyAggregationIdentity extends IdentityValueComposite
{
Property<String> aggregate();
Property<String> collection();
Property<String> member();
}
But then the Identity type should not be coded into the Entity itself,
but applied for usecase. This seems to suggest that Identity handling
is in fact more complex than we have initially assigned to it, and
perhaps this discussion will end being more about Identity than
aggregation, which just exposes the issues that I am having about
manual mangling of identity strings.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
