On Mon, Dec 14, 2015 at 5:29 AM, Kent Sølvsten <[email protected]> wrote:
<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 design... > 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 love... I think I will look into this soon-ish. I have created https://issues.apache.org/jira/browse/ZEST-132 to track it. Cheers -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
