Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <566E59BF.2030207@gmail.com>
References: <566D4467.1030108@gmail.com>
 <CADmm+KcKNVhZC=O+MZdw8iS-qz+ccm2kOMRd-+f+eJDzYw24Xg@mail.gmail.com>
 <566DE323.2080503@gmail.com>
 <CADmm+Kf013h+20M1zxTm4UseUax5iKcO0sTtZc1tFSuwEfYBLw@mail.gmail.com>
 <CADmm+Kcf_b5BG3oPwstFQLCQNCmqHyUj9r65xAfgeJEMd3dk_g@mail.gmail.com>
 <566E59BF.2030207@gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Tue, 15 Dec 2015 12:45:30 +0800
Message-ID: 
 <CADmm+KfDc5_whH8GLUP0Ne_Ys+4xiGb-OsNf+18k+BB-a7nM+Q@mail.gmail.com>
Subject: Re: Inconsistency between indexers and stores?
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a11c3f502bb34330526e876a6

--001a11c3f502bb34330526e876a6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ok, so I have created a Multi-layered testing framework for Indexing/Query,
but only populated two simple testcases.

Access Layer
   DomainLayer
      PersistenceLayer
      IndexingLayer
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
other.

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.


Niclas

On Mon, Dec 14, 2015 at 1:55 PM, Kent S=C3=B8lvsten <kent.soelvsten@gmail.c=
om>
wrote:

> 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 problem=
s
> in
> > the current Indexing/Query semantics. Of course, those testcases will b=
e
> > failing and that is the whole point of bringing this out of the 'develo=
p'
> > 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 so=
me
> > 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
>


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

--001a11c3f502bb34330526e876a6--