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:55:49 GMT
I think that the key to solving this problem is creation of testcases that
highlights the many problems. And I don't think I am capable of making
those on my own, we need a collaborative effort here...

Soooo, I have pushed a new branch ZEST-132, which currently is 'develop',
but I want this branch to get new testcases which shows all the problems in
the current Indexing/Query semantics. Of course, those testcases will be
failing and that is the whole point of bringing this out of the 'develop'



On Mon, Dec 14, 2015 at 10:27 AM, Niclas Hedhman <niclas@hedhman.org> wrote:

> On Mon, Dec 14, 2015 at 5:29 AM, Kent SĂžlvsten <kent.soelvsten@gmail.com>
> 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

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

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