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: <ce80dc5d-142f-715b-f228-31f1764db7a3@gmail.com>
References: <CADmm+KcBefzTj1YPaKsWzH63dE+wLCQLHx_691Cx9NT0fMupBg@mail.gmail.com>
 <CADmm+KfVWyQvTJnNhhgn4y7LHD8raZfFT2XP+gd_REouq1WfVw@mail.gmail.com> <ce80dc5d-142f-715b-f228-31f1764db7a3@gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Sun, 28 May 2017 17:59:25 +0800
Message-ID: <CADmm+KfZ2Rvu3YrtsbCQLAVr4gHfb-m6fFS_W5kSR7M8PeLnNA@mail.gmail.com>
Subject: Re: Visibility, again...
To: dev@polygene.apache.org
Content-Type: multipart/alternative; boundary="001a11407f24566dc5055092a127"
archived-at: Sun, 28 May 2017 09:59:58 -0000

--001a11407f24566dc5055092a127
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Indexers used to have some inconsistency, but I don't recall what. After
all, they only return the Entity Reference, and the caller will end up
loading the entities.

"Home Service" ? End of the day, for domain models, I tend to end up with
entities in Visibility.module, only accessible by services in that module,
and if the entities are used elsewhere, to expose via that service. I think
that works well.

My struggle at the moment is the balancing act of the Infra+Config setup;

   * Caching, Indexers and EntityStores uses configuration
   * UnitOfWork uses Caching and EntityStores
   * Configuration uses UnitOfWork and Serialization

And to get that right for the Yeoman generator, in all cases has surfaced
the peculiarity of Deserializer visible from the ServiceComposite is used
to initially populate the Configuration, but the Configuration entity's
module is used to persist it.


Niclas

On Sun, May 28, 2017 at 5:44 PM, Kent S=C3=B8lvsten <kent.soelvsten@gmail.c=
om>
wrote:

> Regarding the description below (which entitystore is used), I recall
> looking at this a year or 2 ago, coming to more or less the same
> conclusion:
> *The EntityStore closest to the location of the model itself is used*
> (i even recall filing a JIRA issue regarding an inconsistency, since
> this is not the case for indexers/querying).
>
> I agree it is generally a good, consistent principle: The model is King!
>
> I imagine something like a (possibly hidden to application code) "Home
> service" existing for each model, responsible for saving, finding and
> loading entities of a specific type.
> And with that mental image I think it makes sense using the entitystore,
> and the (de)serializer nearest to that imaginary HomeService (and thus
> to the model).
> And the same should go for the querying/indexing stuff.
>
> I sense some refactorings and possibly deprecations coming up, during
> 3.1, 3.2 releases .....
>
> /Kent
>
>
> Den 28-05-2017 kl. 10:50 skrev Niclas Hedhman:
> > Ok,
> > I have figured out why I ended up writing the above.
> >
> > There is a small inconsistency when it comes to Configuration.
> >
> > ConfigurationComposites as they are formally called, is a subtype of
> > EntityComposite that is tied to a ServiceComposite, and can be
> > pre-populated with values from other sources, such as properties files.
> >
> > Now, if I register the ConfigurationComposite in Config Module/Layer, t=
he
> > ConfigurationMixin will use the Module of the ServiceComposite to locat=
e
> > deserializer when reading those external files.
> >
> > I think the consistent behavior should be that the Deserializer visible
> > from the module of the ConfigurationComposite should be used.
> >
> >
> > WDYT?
> >
> >
> > Niclas
> >
> > On Sun, May 28, 2017 at 1:45 PM, Niclas Hedhman <niclas@hedhman.org>
> wrote:
> >
> >> Hi,
> >>
> >> ( If someone wants low-hanging fruit; Take the information below, and
> >> rewrite it as documentation in markdown, under some internal-ish page.
> Or,
> >> extract what the user really need to know and check that we have that
> >> documented already or add it.)
> >>
> >> I am getting more and more uncertain on how the Visibility rules work.
> >> This mail is writing my notes trying to figure out what actually
> happens,
> >> and whether that is semantically correct.
> >>
> >> Let's say we have;
> >>
> >> Connectivity Layer
> >>     MemoryEntityStore
> >>     Restlet does a  newUnitOfWork()
> >>
> >> Service Layer
> >>     FileEntityStore
> >>     DomainService doing uow.get( DomainEntity.class, "123" )
> >>
> >> Domain Layer
> >>     JdbmEntityStore visibiliy application
> >>     DomainEntity
> >>
> >> Infrastructure Layer
> >>     LevelDBEntityStore
> >>
> >> And all of them have the DefaultUnitOfWorkAssembler in effect.
> >>
> >>
> >> So, from which EnittyStore will the entity be read from?
> >>
> >>
> >> Connectivity Layer =3D=3D?, the Restlet would have a module local
> >> UnitOfWorkFactory which will create a UnitOfWorkInstance with
> "Connectivity
> >> Layer" as Module argument. It will also create a ModuleUnitOfWork as a
> >> Transient and therefor receive ModuleDescriptor for Connectivity Layer=
.
> >>
> >>
> >> Service Layer =3D=3D> The DomainService will do call its UnitOfWorkFac=
tory,
> >> which will "find" the UnitOfWorkInstance from above (with the
> Connectivity
> >> Layer module in it) and then instantiate a new ModuleUnitOfWork, which
> will
> >> have the ModuleDescriptor of Service Layer
> >>
> >>
> >> Domain  and Infrastructure Layers =3D=3D> are totally passive.
> >>
> >>
> >> So what happens at uow.get() in DomainService?
> >>
> >> EntityDescriptor for DomainEntity is looked up inside ModuleUnitOfWork
> in
> >> Service Layer, useing the module in Service Layer as visibility
> argument.
> >> I.e. the DomainEntity must be Visibility.application.
> >>
> >> Then UnitOfWorkInstance.get() is called, with identity, potentialModel=
s
> >> and the ModuelUnitOfWork as arguments. It loops through the potential
> >> models, takes the Module in these, creates a EnityStoreUnitOfWork with
> that
> >> EntityStore and tries to load the state. If successful create a
> >> EntityInstance with this;
> >>
> >> model =3D (EntityModel) entityState.entityDescriptor();
> >>
> >> entityInstance =3D new EntityInstance( uow, model, entityState );
> >>
> >>
> >> where uow is the ModuleUnitOfWork, i.e. from the module in the Service
> >> Layer and the model containing a Module of potentialModel
> >> selected/successful.
> >>
> >>
> >> So, my conclusion is;  it seems that the Entity Store that is visible =
to
> >> the DomainEntity will be used... And that is what I think has been the
> >> intention all the while since back in 2007/2008 somewhere when the
> >> Visibility design was utterly flawed in the first iteration of Qi4j (t=
he
> >> above would require the Restlet to see everything).
> >>
> >>
> >>
> >>
> >> --
> >> Niclas Hedhman, Software Developer
> >> http://polygene.apache.org - New Energy for Java
> >>
> >
> >
>
>


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

--001a11407f24566dc5055092a127--