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 <nic...@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.soelvs...@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 <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 >> >> >> > >> > >> >> > > > -- > Niclas Hedhman, Software Developer > http://polygene.apache.org - New Energy for Java > -- Niclas Hedhman, Software Developer http://polygene.apache.org - New Energy for Java
