polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Design flaw in EntityStore SPI?
Date Sat, 22 Oct 2016 03:01:55 GMT
And this will has a strange side-effect that I perhaps have not thought of
well enough...

Say;

*public interface Employee extends HasAddress{}*

*public interface Company extends HasAddress{}*

Now, assume that we save Employee "niclas" and then later do;

*Company c = uow.get(Company.class, "niclas" );*

with the proposed approach, I will end up with the state of "niclas"
backing the Company type that I am loading.

Should this be allowed?

Currently, this causes a ClassCastException, as the entity is instantiated
by the EntityStore without the information of what type is wanted, and at
assignment it would fail.

In principle, there is nothing stopping this from working, other than that
the creation in the ES would need to ensure that all required state is
present, which would probably lead to a lot of @Optional everywhere.

So, currently, any entity can not become more specific (lower subclass)
than it was originally saved as, which makes sense, as there is no
API-level mechanism to create the state for any of the subtypes. And
perhaps this really how it should be, to avoid bad designs and loads of
runtime problems.

Cheers

On Sat, Oct 22, 2016 at 1:07 AM, Paul Merlin <paul@nosphere.org> wrote:

> Makes sense to me
>
> Niclas Hedhman a écrit :
> > Hi again,
> > While looking into the feasibility of implementing a Repository
> EntityStore
> > I realized that the current SPI seems flawed.
> >
> > The TYPE of an entity is stored with the entity and not the entity type
> > that is being processed by the outside world. And then type lookup is
> used
> > via the current Module associated to the current UnitOfWork.
> >
> > It seems more logical to me that an EnttyDscriptor is passed down to the
> > EntityStore, so that the type doesn't need to be looked up. For ES, this
> > seems to work well, although this doesn't solve a similar issue in the
> > Query system.
> >
> > I would like to change the EntityStoreSPI from
> >
> >
> > public interface EntityStoreSPI
> > {
> >     EntityState newEntityState( EntityStoreUnitOfWork unitOfWork,
> >                                 EntityReference identity,
> >                                 EntityDescriptor entityDescriptor
> >     );
> >
> >     EntityState entityStateOf( EntityStoreUnitOfWork unitOfWork,
> >                                ModuleDescriptor module,
> >                                EntityReference identity );
> >
> >     String versionOf( EntityStoreUnitOfWork unitOfWork,
> >                       EntityReference identity );
> >
> >     StateCommitter applyChanges( EntityStoreUnitOfWork unitOfWork,
> >                                  Iterable<EntityState> state );
> > }
> >
> > to
> >
> > public interface EntityStoreSPI
> > {
> >     EntityState newEntityState( EntityStoreUnitOfWork unitOfWork,
> >                                 EntityReference identity,
> >                                 EntityDescriptor entityDescriptor
> >     );
> >
> >     EntityState entityStateOf( EntityStoreUnitOfWork unitOfWork,
> >                                EntityReference identity,
> >                                EntityDescriptor entityDescriptor );
> >
> >     String versionOf( EntityStoreUnitOfWork unitOfWork,
> >                       EntityReference identity,
> >                       EntityDescriptor entityDescriptor );
> >
> >     StateCommitter applyChanges( EntityStoreUnitOfWork unitOfWork,
> >                                  Iterable<EntityState> state );
> > }
> >
> >
> > which I think can handle the requirements of Repository ES more
> elegantly.
> >
> > WDYT?
> >
> > Cheers
>



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

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