All,

Just a quick status update.

I've been plugging away on the refactoring of OIDs to make them immutable,
I now have:

- RootOid - for root adapters
- CollectionOid - for List/Set instances of a root
- AggregateOid - for aggregated adapters (either a type annotated as
@Aggregated or by the property/collection).

This gave me a chance to get into the nitty-gritty of the NoSQL object
store and how it handles persistence of aggregates.  I think the separation
of collections vs aggregates is a good thing.

Along the way I've also been tidying up some of our test code, generally
trying to simplify wherever possible.  That's led me into the
TestProxySystem class and its three different variants (which are used to
bootstrap the default runtime in order to have an IsisContext singleton to
query); bottom line is that I'm refactoring this and are aiming to have a
single equivalent, currently called IsisSystemWithFixtures, that can be
used to bootstrap Isis and easily run different end-to-end tests.  Part of
this is in prep to - hopefully - having a common "TCK" contract tests for
the object stores (so we know that they can all persist the same set common
domain objects).

As a teaser, the IsisSystemWithFixtures is used as follows:

public class IsisSystemWithFixturesTest_basicTest {

    @Rule
    public IsisSystemWithFixtures iswf = new IsisSystemWithFixtures();

    @Test
    public void savePojo() throws Exception {

        assertThat(iswf.fixtures.testPojoRepository.findAll().size(),
is(0));
        iswf.container.persist(iswf.fixtures.testPojo1);
        assertThat(iswf.fixtures.testPojoRepository.findAll().size(),
is(1));
    }
}

To use a different object store, it'd be something like:

    @Rule
    public IsisSystemWithFixtures iswf = new IsisSystemWithFixtures() {
        protected PersistenceSessionFactory
createPersistenceSessionFactory() {
            // some other implementation here...
        }
    };

~~~
Since the amount of changes I had in my local workspace was getting
worrying large, I've decided to do a commit to a local branch.  Since I
hadn't planned this originally, what I actually did was:

1. copy the current trunk/framework to branches/0.3.0-incubating-OLD-OIDs
2. commit my changes to trunk/framework
3. move trunk/framework to branches/0.3.0-incubating-NEW-OIDs
4. move branches/0.3.0-incubating-OLD-OIDs back to trunk/framework

I hope to get this work finished by the end of next week, so if I could ask
you to minimize any changes on trunk/framework to the absolute minimum, I'd
very much appreciate it.


Cheers
Dan

Reply via email to