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: Inconsistency between indexers and stores?
Date Sun, 13 Dec 2015 21:29:07 GMT
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" <kent.soelvsten@gmail.com> 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
>>
>>
>>
>>
>>
>>


Mime
View raw message