Mailing-List: contact dev-help@polygene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@polygene.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <2b7672ee-ab14-4a4e-5779-e9f0d3c10ff1@gmail.com>
References: <CADmm+KeYutZOVuSN8WqaYXFNnUXDX3J0x4J9Oz23_JH4v+ew_Q@mail.gmail.com>
 <59104647.1010206@apache.org> <CADmm+KeMGev-Obn7iJm-bj_2GUDxM-h=V6=YcNMVEyU4gBwedw@mail.gmail.com>
 <2b7672ee-ab14-4a4e-5779-e9f0d3c10ff1@gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Tue, 9 May 2017 00:07:18 +0800
Message-ID: <CADmm+KfHxKb3uC--HKyTL6rdnW62d-oJC0nQu9jq7ji9XgVvDA@mail.gmail.com>
Subject: Re: SPI issue?
To: dev@polygene.apache.org
Content-Type: multipart/alternative; boundary=94eb2c184bfa2e23c8054f0570d6
archived-at: Mon, 08 May 2017 16:07:45 -0000

--94eb2c184bfa2e23c8054f0570d6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey Kent, been a while....

yeah, why not? I will try to make one sweep across all API, SPI and
Bootstrap interfaces to ensure,

a. Consistent ordering,
b. lambdas at the end of parameter list.

Cheers
Niclas

On Mon, May 8, 2017 at 11:26 PM, Kent S=C3=B8lvsten <kent.soelvsten@gmail.c=
om>
wrote:

> A small nitty-gritty thought ...
>
> is it worthwhile swapping the arguments of #entityStateOf, such that all
> methods have an entityReference as 1st argument? (another way of
> creating a bit more consistency)
>
> /Kent
>
> public interface EntityStoreUnitOfWork
> {
>     EntityState newEntityState( EntityReference anIdentity,
> EntityDescriptor entityDescriptor )
>         throws EntityStoreException;
>
>     EntityState entityStateOf( ModuleDescriptor module,
> EntityReference anIdentity )
>         throws EntityStoreException, EntityNotFoundException;
>
>     String versionOf( EntityReference anIdentity ) throws
>
> EntityStoreException;
>
> > }
>
> Den 08-05-2017 kl. 16:34 skrev Niclas Hedhman:
> > Yeah, you kind of got to the same conclusion as I did... i.e. not sure
> what
> > to do. If we add the EntityDescriptor, there should be some semantics o=
n
> > what it means, not arbitrarily from ES to ES.
> >
> > I think we just keep it as it is.
> >
> > On Mon, May 8, 2017 at 6:19 PM, Paul Merlin <paulmerlin@apache.org>
> wrote:
> >
> >> Hey Niclas,
> >>
> >> Niclas Hedhman a =C3=A9crit :
> >>> Peddling with this JOOQ ES (or whatever it ends up being called), I
> found
> >>> an inconsistency in the EntityStore SPI.
> >>>
> >>>
> >>> public interface EntityStoreUnitOfWork
> >>> {
> >>>     EntityState newEntityState( EntityReference anIdentity,
> >>> EntityDescriptor entityDescriptor )
> >>>         throws EntityStoreException;
> >>>
> >>>     EntityState entityStateOf( ModuleDescriptor module,
> >>> EntityReference anIdentity )
> >>>         throws EntityStoreException, EntityNotFoundException;
> >>>
> >>>     String versionOf( EntityReference anIdentity ) throws
> >> EntityStoreException;
> >>> }
> >>>
> >>>
> >>> It is not consistent to pass the EntityDescriptor in newEntityState()
> but
> >>> not in entityStateOf(). In the latter case, it is expected that the
> >>> EntityStore have saved away the type, and able to look it up from the
> >>> Module, when the caller already have the EntityDescriptor readily
> >> available.
> >>> Can anyone think of a case where it is not better to pass the
> >>> EntityDescriptor from the caller?
> >>>
> >>> It might be related to looking up via a super type, and if then savin=
g,
> >>> then there is a chance that the "old fields" are no long present. And
> to
> >>> avoid that, push the whole "what is the lowest subclass of this
> identity"
> >>> to the entitystore.
> >>>
> >>> I think my question is, what is the proper semantics around entity
> >>> subclasses? Is it really the "saved type" that is the deserialized
> type,
> >> or
> >>> is it the "requested type" that should be the deserialized type?
> >>>
> >>> I am not sure either way, and would like to hear more arguments one w=
ay
> >> or
> >>> the other.
> >> Yeah, agreed that it doesn't feel consistent at first sight.
> >>
> >> BUT,
> >> When creating an entity we don't have anything else than its
> >> EntityDescriptor.
> >> When saving the entity its `type` is set to the main type of its
> >> EntityDescriptor.
> >> Then, when fetching an entity the ES will load the whole state and use
> >> the stored `type` to lookup the corresponding EntityDescriptor, and fa=
il
> >> with a NoSuchEntityTypeException if not found.
> >>
> >> As you wrote, this means that you can fetch an Entity using a super
> >> type, the loaded state will however contain all the data described by
> >> the EntityDescriptor used on creation. API-wise you'll only be able to
> >> mutate the entity using the "requested type" but under the hood, the
> >> whole state is kept.
> >>
> >> I think it makes sense. Especially when thinking about key/value backe=
d
> >> EntityStores where the whole state is a "blob".
> >>
> >> If we change that SPI so that `entityStateOf(..)` takes an
> >> EntityDescriptor then it would mean that EntityStores could have the
> >> opportunity to only load a "view" of the entity and have to handle
> >> supplementary fields non destructively. As I see it adds a feature to
> >> the SPI and a new responsibility for EntityStores.
> >>
> >> Key/Value stores could then still do as they do today, possibly
> >> validating that the saved EntityDescriptor types include all of the
> >> requested EntityDescriptor types. Or some sort of validation. It's an
> >> extra responsibility for the EntityStores.
> >>
> >> More evolved EntityStores could then only load "views" of entities, no=
t
> >> the whole saved state. But they also should be able to update state no=
n
> >> destructively.
> >>
> >> I'd say it's a tradeoff between capabilities and implicit
> >> responsibilities for implementations. I'm not against adding the featu=
re
> >> to the SPI but then we should at least properly document it so
> >> asumptions are crystal clear.
> >>
> >> Does that help?
> >>
> >> Cheers
> >>
> >> /Paul
> >>
> >>
> >>
> >
>
>


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

--94eb2c184bfa2e23c8054f0570d6--