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 Tue, 15 Dec 2015 04:45:30 GMT
Ok, so I have created a Multi-layered testing framework for Indexing/Query,
but only populated two simple testcases.

Access Layer
and then a ConfigLayer under both the Persistence and Indexing, which might
not be needed.

I think the EntityStore should not need to have Visibiilty of Indexer
(org.apache.zest.spi.entitystore.StateChangeListener) and instead I think
it should be from the point of view of the UnitOfWork, i.e. the Module,
performing the "store+index" operation.

And it is for that reason, the test is setup so that the DomainLayer has
the Persistence and the Indexing in separate layers, so they can't see each

What I would REALLY like to get help with, is to "convert" the many
indexing/query test cases to this new structure.
For each @Test method in the old tests,

  a. Create a TestCase 'service' by modifying the TestSuite1Module
  b. Add a field for it in AbstractMultiLayeredIndexingTest
  c. Create a @Test method in AbstractMultiLayeredIndexingTest

So, what is next?

Kent suggested that UnitOfWork should have a better grip on the whole
Indexing/Query process, and I agree. I am also keen on making UnitOfWork a
user-defined composite in itself, and will look into what is required for
that. I think it is simply a matter of looking up the UnitOfWorkFactory as
a regular service, some convenience classes, and possibly more access to
the internals via the ZestSPI.


On Mon, Dec 14, 2015 at 1:55 PM, Kent SĂžlvsten <kent.soelvsten@gmail.com>

> Den 14-12-2015 kl. 03:55 skrev Niclas Hedhman:
> > 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?
> Agreed.
> I have previously created the first testcases regarding querying in a
> multi-module zest-deployment. But those are more reflecting the state
> "as-is" instead of "as-wanted".
> See for example RdfQueryMultiModuleTest.
> We could definitely use much more tests using multiple modules.
> > 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.
> >
> I will do that
> /Kent

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

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