polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Visibility, again...
Date Sun, 28 May 2017 11:43:09 GMT
I now have a fix for this locally. Didn't break any tests, but could
potentially break apps out there, so good to get this fixed pre-3.0.


Niclas

On Sun, May 28, 2017 at 5:59 PM, Niclas Hedhman <niclas@hedhman.org> wrote:

>
> 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Ăžlvsten <kent.soelvsten@gmail.com>
> 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,
>> 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
>> >>
>> >
>> >
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>



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

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