polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Inconsistency between indexers and stores?
Date Mon, 14 Dec 2015 02:27:28 GMT
On Mon, Dec 14, 2015 at 5:29 AM, Kent SĂžlvsten <kent.soelvsten@gmail.com>

<snip content="The Brilliant Stuff" />

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

Ok. I have never worked on the Indexing, nor do I use it very often (in
fact almost never), so I have been happily unaware of this problem.
It also explains why the ElasticSearch Indexer had problems and ended up
being incorrectly implemented... As you say, it is massively flawed

> 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) ).

Yes, that would be the most straight forward option...

One interesting observation is that the EntityFinder is implemented using
standard Zest constructs, while the UnitOfWork isn't, and that we have
discussed else-thread that perhaps UnitOfWork should be a user assembled
artifact (like EntityFinder in reality is). But with multi-layered
applications, will this introduce too much assembly requirements.

Hope I am more clear now?

I would be delighted if you could write the Visibiility section in the
core/api/src/docs/structure.txt. It is currently empty, and it needs some

I think I will look into this soon-ish. I have created
https://issues.apache.org/jira/browse/ZEST-132 to track it.

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

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