polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten <kent.soelvs...@gmail.com>
Subject Re: Visibility, again...
Date Sun, 28 May 2017 09:44:01 GMT
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, the
> ConfigurationMixin will use the Module of the ServiceComposite to locate
> 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 ==?, 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 ==> The DomainService will do call its UnitOfWorkFactory,
>> 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 ==> 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, potentialModels
>> 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 = (EntityModel) entityState.entityDescriptor();
>>
>> entityInstance = 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 (the
>> above would require the Restlet to see everything).
>>
>>
>>
>>
>> --
>> Niclas Hedhman, Software Developer
>> http://polygene.apache.org - New Energy for Java
>>
>
>


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