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 15:16:59 GMT
I took a shot at breaking out the UnitOfWorkFactory as a service lookup,
and it will create a UnitOfWork as a transient. It was easier than
expected, but the biggest question remain;

By default, there is "none", so how should we deal with the DEFAULT case?
  a. Always require people to declare it explicitly?
  b. Add it automatically in Assembly and add some "remove" option from
  c. Some other mechanism?

Also, I think Kent and Paul need to do some Thinking Beers and figure out
the exact semantics for when;

    1. Client in Module 1
    2. UnitOfWorkFactory service in Module 2
    3. UnitOfWork transient in Module 3
    4. Looked up type in Module 4

What is visible to what?? Or are we going to demand that
UnitOfWork(Factory) are never exposed cross-module?

Big Questions, and I had a whisky too many to think clearly.


On Tue, Dec 15, 2015 at 12:45 PM, Niclas Hedhman <niclas@hedhman.org> wrote:

> 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Ăžlvsten <kent.soelvsten@gmail.com>
> 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
>> 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

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

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