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