polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: Design flaw in EntityStore SPI?
Date Sat, 22 Oct 2016 12:25:10 GMT
Niclas Hedhman a écrit :
> 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.

Indeed!

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

If one do not add @Optional's everywhere, ES would fail validating the
required state. If one wants to view the same state as very distinct
Entity types he would have to model it properly, having some @Optional
state makes it easy. It sounds like an interesting modeling facility and
does not feel so wrong to me. But adding the responsibility to do this
validation to ES may not be something we want to do.



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

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