I see, I need to be more precise :-) I have (currently) no intention to change the flow for saving/updating/get'ing/finding entities. What i would like to change is the algorithm for selecting *which* indexer is used for querying (in a setup with multiple indexers).
The "Closest Entity Store" is not a new concept - but simply my way of saying the-entity-store-found-by-the-servicefinder-in-the-entitymodels-module. So i guess it is more correct to say, that I would like to change the rules for *which* servicefinder is used to resolve the EntityFinder/Indexer. So more precisely: When we create an entity inside a UOW it is put into the UOWcache - and the state is registered inside an EntityStoreUOW - using the entitystore found as model.module().entityStore() That is, we use the servicefinder inside the mode's module to locate an EntityStore. State is then flushed to that EntityStore on completion of the UOW. When we get() an entity from a UOW, we first ask the cache inside the UOW - and then go on to ask EntityStores. The algorithm for finding entitystores are similar: - we find all entitymodels implementing the type of entity we wish to get() - for each model we find the relevant entitystore (using potentialModel.module().entityStore()) - for each entitystore we attempt to get the EntityState - and then use the model to create an EntityInstance holding that state. Brilliant stuff - i see no reason to change that. We are doing domain-driven design here - the model is king. It makes complete sense that (1) I can create an entity if and only if i can see it's model (according to visibility rules) (2) I can get an existing entity if and only if i can see it's model (according to visibility rules). As a caller, "my module" is used to locate a model, and then the module for that model is used to locate an entitystore. Whether the calling module can see the entitystore or not is an irelevant detail - as it should be. For querying the current status is much more complex. (3a) I can query for an existing entity, if i can see it's model, *and* i can see an indexer, *and* the entitystore in which the entity is persisted can see the same indexer. Ouch! Much, much complicated! A lot of machinery going on there. My suggestion is to change that to a simpler (3b) I can query for an existing entity, if and only if i can see its model. just like for the create/get cases. That would require, that when querying, we always use the servicefinder of the model.module() to locate an EntityFinder (maybe introduce model.module().entityFinder() ???) And it would require, that when complete()'ing a UOW, instead of notifying all indexers/entityfinders visible to the EntityStore we instead notify the (single) indexer found by model.module() (model.module.findServices(StateChangeListener.class) ). Hope I am more clear now? /Kent Den 13-12-2015 kl. 12:41 skrev Niclas Hedhman: > I think this is a topic that needs a few brains and a whiteboard. > > The "Closest Entity Store" is not a concept that makes sense to me right > now, as we have only worked with Visibility rules. > > That said, the query process should in my opinion be very straight forward; > The returned values are ONLY Identities and the Query should use the > UnitOfWork to get() the values from there, and skip any unreachable > entities. > > That, in my current understanding, should give the best consistency and be > compatible with pluggable types. > > Or are you discussing something completely different? > > Niclas > On Dec 13, 2015 18:12, "Kent Sølvsten" <[email protected]> wrote: > >> Hi >> >> We seem to have som inconsistencies between indexers and entitystores. >> >> When we get() an entity, it is fetched from the EntityStore that is >> "closest" to the corresponding EntityModel. >> When we save an entity, it is persisted in the EntityStore that is >> "closest" to the corresponding EntityModel. >> >> but ... >> >> The EntityStore propagates state to all indexers that are visible *from >> the store* >> When we query, we use the EntityFinder (indexer) that are "closest" to >> *the caller* to ifnd EntityReferences - which are then converted to >> entities. >> >> I believe this inconsistency should be fixed to a more consistent tale. >> Even today it leads to some confusion in multi-module projects - and it >> will get even worse, when we >> (which is the goal for 3.0) add more persistent types. >> >> What I suggest (details should possibly be fleshed out): >> >> When we get() an entity, it is fetched from the EntityStore that is >> "closest" to the corresponding EntityModel. >> When we save an entity, it is persisted in the EntityStore that is >> "closest" to the corresponding EntityModel. >> When we save an entity, the EntityStore notifies the indexer that is >> "closest" to the corresponding EntityModel. >> When we query for entities, we find all model implementing that entity >> type and perform the query against the indexers that are closest to each >> type. >> - that is, if a type is implemented by more entities, these might not >> all be in the same indexer. >> >> Thoughts? >> >> I know this will not be backwards compatible in all cases - but still >> think we should go for it. >> >> /Kent >> >> >> >> >> >>
