On 14 May 2014 11:27, Erik de Hair <[email protected]> wrote:

>
>     @Before
>     public void setUp(){
>         this.role = container().newTransientInstance(Role.class);
>         this.role.setLabel("ROLE_ADMIN");
>         this.role.setDescription("(Reseller) admin");
>         container().persistIfNotAlready(this.role);
>
>         service(Contacts.class).create("Piet", "van de", "Pet",
> Gender.MALE, "[email protected]"<mailto:[email protected]>, "pietmetpet",
> this.role);
>         service(Contacts.class).create("Jan", "van de", "Jas",
> Gender.MALE, this.uniqueEmail, "janvandejas", this.role);
>         service(Contacts.class).create("Marie", "van de", "Markt",
> Gender.FEMALE, this.duplicateEmail, "marievandemarkt", this.role);
>         service(Contacts.class).create("Marie", "van de", "Markt",
> Gender.FEMALE, this.duplicateEmail, "marievandemarkt1", this.role);
>     }
>
>     @Test
>     public void testFindUseraccountsByEmail() throws Exception {
>         int expected = 1;
>         int actual =
> wrap(service(Contacts.class)).findUseraccountsByEmail(this.uniqueEmail).size();
>         Assert.assertEquals(expected, actual);
>     }
> }
>
> The actual value is '0' while I'm sure the requested object is inserted by
> the @Before-method and the query is all right.
>
>
Two thoughts:

1. the persistIfNotAlready(...) call only "queues up" the object to be
persisted; this doesn't actually happen until either the xactn is committed
or container.flush() is called.  So try adding a call to flush() to see if
anything changes.

2. that said, I'm pretty sure that our finders automatically call
flush(...).  Put a break point in IsisTransactionManager.flushTransaction()
to see if it gets called.

If it does, then you could enable logging via JDBC or via DataNucleus; the
persistor_datanucleus.properties or persistor.properties shows how ...
you'll need to copy into the integ tests' equivalent class (somewhere in
the vicinity of its XxxSystemInitializer class).

If flush is not called, then there's possibly a conversation to be had
about transaction demarcation in tests and how it should work; I think the
default is that each test method is in its own transaction.  But the iswf
(@Rule) also provides some method for more fine-grained control.


HTH
Dan




> Is this an Isis issue or do I have to look for a Datanucleus/other
> solution?
>
> Thanks,
> Erik
>

Reply via email to