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

WDYT?

Niclas

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

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