You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Erik de Hair <er...@pocos.nl> on 2014/05/14 12:27:58 UTC
integration testing: 'lost' data
Hi,
I'm writing a test with some inserts in the @Before and a query to find the inserted objects (ResellerPortalIntegTest is the original SimpleIntegTest-class):
public class ContactsTest extends ResellerPortalIntegTest {
private Role role;
private final String uniqueEmail = "jan@pokos.nl"<ma...@pokos.nl>;
private final String duplicateEmail = "marie@pokos.nl"<ma...@pokos.nl>;
private final String unkownEmail = "xyzabc@bladiblah.com"<ma...@bladiblah.com>;
@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, "piet@pokos.nl"<ma...@pokos.nl>, "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.
Is this an Isis issue or do I have to look for a Datanucleus/other solution?
Thanks,
Erik
Re: integration testing: 'lost' data
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 14 May 2014 11:27, Erik de Hair <er...@pocos.nl> 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, "piet@pokos.nl"<ma...@pokos.nl>, "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
>
Re: integration testing: 'lost' data
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
El 17/05/2014, a las 14:41, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 15 May 2014 00:57, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>> Dan, please, correct me as needed :-))
>>
>> The commands are added to a queue, and that queue is emptied on each
>> transaction.
>>
>>
> correct
>
>
>> The point is that Isis, for example, generates a new transaction on each
>> action invokation.
>>
>>
> correct
>
>
>> In the context of tests, that could be simulated by wrapping the calls (it
>> would also force other business rules) to actions, and setters.
>>
>>
> sort-of.
>
> I've just been double checking as to the behaviour of transactions in
> tests; it is fairly sane, I think, though not well documented.
>
> We set up a new transaction for each test. The same transaction is present
> for the setup and the test method itself, in a state of IN_PROGRESS.
>
> You can confirm this using
> IsisContext.getTransactionManager().getTransaction().getState().
>
> IsisSystemForTest.get() is a thread-local representation of the running
> system. Using this, it is possible to commit/abort and begin new
> transactions at any time:
>
> * IsisSystem.get().commitTran()
> * IsisSystem.get().abortTran()
> * IsisSystem.get().beginTran()
>
>
> The interaction of transactions with/without wrap() is as follows:
>
> 1. if a transaction is in progress (the default), then invoking without
> wrapping (as expected) takes place in the context of that interaction; the
> transaction is not committed
> 1. if a transaction is in progress, then wrapping - at least as far as
> transactions are concerned - has no effect; the interaction is performed in
> the context of the current transaction
> 3. if a transaction has been explicitly committed (so that none is in
> progress), then invoking without wrapping will cause an exception to be
> thrown ("no xactn in progress")
> 4. if a transaction has been explicitly committed, then wrapping will
> automatically begin and commit the transaction around the interaction.
>
> So, Oscar, your statement corresponds to option 4, and is correct if the
> xactn had already been committed explicitly (in the setup, say)
I understand. That's the reason why sometimes
this.nextTransaction();
is mandatory on BDD steps...
It can be unnecessary if you do a getContainer.flush() on each persist if it's needed mainly for sending changes to the database and for DataNucleus to automatically manage bi-directional relationships.
>
>
>
>> In our case, we have created a persist method on each repository that
>> persists the domain object and also executes a flush.
>>
>>
> A reasonable pattern. I'm pretty sure that any repository query will
> always do a flush anyway (analogous to Hibernate auto-flush function).
So if this is the case, why not the default "persist()" implementation always do a getContainer.flush() by default, in order to avoid confusions like this one?
There can be an alternative "persistWithoutFlush()" method if required.
>
>
>
>> Perhaps its performance would not be as good for bulk inserts, but in the
>> context of our domain we prefer to force the flush on each persist than the
>> performance gained by queueing the database commands to be sent in blocks.
>>
>>
> If bulk inserts are ever required, then a good pattern is to define a
> domain service to do this sort of work. Then, start out with a naive
> implementation that just does individual flushes, and switch in a more
> performant implementation (eg calling stored procedures or whatever) if and
> when required. So long as the integration tests pass...
>
> On the topic of performance (for queries), do note that in 1.4.0 we
> introduced QueryResultsCache. And, DN has various L2 caching options for
> truly immutable data.
>
We have some derived properties in our domain that are quite intensive on its computation. We are planning to use the cache method you implemented for actions.
> Cheers
> Dan
>
>
>
>
>> HTH,
>>
>> Oscar
>>
>>
>>
>>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: integration testing: 'lost' data
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 15 May 2014 00:57, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
> Dan, please, correct me as needed :-))
>
> The commands are added to a queue, and that queue is emptied on each
> transaction.
>
>
correct
> The point is that Isis, for example, generates a new transaction on each
> action invokation.
>
>
correct
> In the context of tests, that could be simulated by wrapping the calls (it
> would also force other business rules) to actions, and setters.
>
>
sort-of.
I've just been double checking as to the behaviour of transactions in
tests; it is fairly sane, I think, though not well documented.
We set up a new transaction for each test. The same transaction is present
for the setup and the test method itself, in a state of IN_PROGRESS.
You can confirm this using
IsisContext.getTransactionManager().getTransaction().getState().
IsisSystemForTest.get() is a thread-local representation of the running
system. Using this, it is possible to commit/abort and begin new
transactions at any time:
* IsisSystem.get().commitTran()
* IsisSystem.get().abortTran()
* IsisSystem.get().beginTran()
The interaction of transactions with/without wrap() is as follows:
1. if a transaction is in progress (the default), then invoking without
wrapping (as expected) takes place in the context of that interaction; the
transaction is not committed
1. if a transaction is in progress, then wrapping - at least as far as
transactions are concerned - has no effect; the interaction is performed in
the context of the current transaction
3. if a transaction has been explicitly committed (so that none is in
progress), then invoking without wrapping will cause an exception to be
thrown ("no xactn in progress")
4. if a transaction has been explicitly committed, then wrapping will
automatically begin and commit the transaction around the interaction.
So, Oscar, your statement corresponds to option 4, and is correct if the
xactn had already been committed explicitly (in the setup, say)
> In our case, we have created a persist method on each repository that
> persists the domain object and also executes a flush.
>
>
A reasonable pattern. I'm pretty sure that any repository query will
always do a flush anyway (analogous to Hibernate auto-flush function).
> Perhaps its performance would not be as good for bulk inserts, but in the
> context of our domain we prefer to force the flush on each persist than the
> performance gained by queueing the database commands to be sent in blocks.
>
>
If bulk inserts are ever required, then a good pattern is to define a
domain service to do this sort of work. Then, start out with a naive
implementation that just does individual flushes, and switch in a more
performant implementation (eg calling stored procedures or whatever) if and
when required. So long as the integration tests pass...
On the topic of performance (for queries), do note that in 1.4.0 we
introduced QueryResultsCache. And, DN has various L2 caching options for
truly immutable data.
Cheers
Dan
> HTH,
>
> Oscar
>
>
>
>
Re: integration testing: 'lost' data
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Dan, please, correct me as needed :-))
The commands are added to a queue, and that queue is emptied on each transaction.
The point is that Isis, for example, generates a new transaction on each action invokation.
In the context of tests, that could be simulated by wrapping the calls (it would also force other business rules) to actions, and setters.
In our case, we have created a persist method on each repository that persists the domain object and also executes a flush.
Perhaps its performance would not be as good for bulk inserts, but in the context of our domain we prefer to force the flush on each persist than the performance gained by queueing the database commands to be sent in blocks.
HTH,
Oscar
El 14/05/2014, a las 15:50, Erik de Hair <er...@pocos.nl> escribió:
> container.flush() did the trick in this case. I have some other cases with almost the same problem. It's not always clear how these transactions act in tests but I managed to run all my tests.
>
> Also had a case where it didn't work to persist some data in the setup-method but it worked when I did exactly the same thing at the start of my test-method. :-/
>
> It even looks like it works in a random way: sometimes an error, sometimes everything ok.
>
> Erik
>
>
> On 05/14/2014 01:23 PM, Dan Haywood wrote:
>
>
>
> 2014-05-14 11:38 GMT+01:00 GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>>:
> Hi, Erik.
>
> Perhaps DN holds them still "in memory" and has not been flushed to the database.
>
>
> I don't think that DN does, but Isis certainly does holds them in memory until the flush or commit.
>
>
> Dan
>
>
>
> Normally, it can be done by calling "flush" on the DomainContainer, similar to:
>
> this.getContainer().flush();
>
>
> HTH,
>
> Oscar
>
>
>
>
>
>
> El 14/05/2014, a las 12:27, Erik de Hair <er...@pocos.nl>> escribió:
>
>
> Hi,
>
> I'm writing a test with some inserts in the @Before and a query to find the inserted objects (ResellerPortalIntegTest is the original SimpleIntegTest-class):
>
> public class ContactsTest extends ResellerPortalIntegTest {
>
> private Role role;
>
> private final String uniqueEmail = "jan@pokos.nl<ma...@pokos.nl>;
> private final String duplicateEmail = "marie@pokos.nl<ma...@pokos.nl>;
> private final String unkownEmail = "xyzabc@bladiblah.com<ma...@bladiblah.com>;
>
> @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, "piet@pokos.nl<ma...@pokos.nl>, "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.
>
> Is this an Isis issue or do I have to look for a Datanucleus/other solution?
>
> Thanks,
> Erik
>
>
> Óscar Bou Bou
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> [cid:4C38BF6A-D280-4C7F-BFC2-4285B2033897] 902 900 231 / 620 267 520
> [cid:6DF89309-F557-4C28-BDFC-AE5B9D964612] http://www.twitter.com/oscarbou
>
> [cid:DDC0BB1F-E0FC-4120-97F8-E2D5F0DA9BC5] http://es.linkedin.com/in/oscarbou
>
> [cid:F31E93E9-D0D0-4F96-9A7C-496F094117DC] http://www.GesConsultor.com<http://www.gesconsultor.com/>
>
> [cid:04E888F1-A5E9-49D1-832D-465FE2C6C940]
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
>
>
>
>
>
>
>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: integration testing: 'lost' data
Posted by Erik de Hair <er...@pocos.nl>.
container.flush() did the trick in this case. I have some other cases with almost the same problem. It's not always clear how these transactions act in tests but I managed to run all my tests.
Also had a case where it didn't work to persist some data in the setup-method but it worked when I did exactly the same thing at the start of my test-method. :-/
It even looks like it works in a random way: sometimes an error, sometimes everything ok.
Erik
On 05/14/2014 01:23 PM, Dan Haywood wrote:
2014-05-14 11:38 GMT+01:00 GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>>:
Hi, Erik.
Perhaps DN holds them still "in memory" and has not been flushed to the database.
I don't think that DN does, but Isis certainly does holds them in memory until the flush or commit.
Dan
Normally, it can be done by calling "flush" on the DomainContainer, similar to:
this.getContainer().flush();
HTH,
Oscar
El 14/05/2014, a las 12:27, Erik de Hair <er...@pocos.nl>> escribió:
Hi,
I'm writing a test with some inserts in the @Before and a query to find the inserted objects (ResellerPortalIntegTest is the original SimpleIntegTest-class):
public class ContactsTest extends ResellerPortalIntegTest {
private Role role;
private final String uniqueEmail = "jan@pokos.nl<ma...@pokos.nl>;
private final String duplicateEmail = "marie@pokos.nl<ma...@pokos.nl>;
private final String unkownEmail = "xyzabc@bladiblah.com<ma...@bladiblah.com>;
@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, "piet@pokos.nl<ma...@pokos.nl>, "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.
Is this an Isis issue or do I have to look for a Datanucleus/other solution?
Thanks,
Erik
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
[cid:4C38BF6A-D280-4C7F-BFC2-4285B2033897] 902 900 231 / 620 267 520
[cid:6DF89309-F557-4C28-BDFC-AE5B9D964612] http://www.twitter.com/oscarbou
[cid:DDC0BB1F-E0FC-4120-97F8-E2D5F0DA9BC5] http://es.linkedin.com/in/oscarbou
[cid:F31E93E9-D0D0-4F96-9A7C-496F094117DC] http://www.GesConsultor.com<http://www.gesconsultor.com/>
[cid:04E888F1-A5E9-49D1-832D-465FE2C6C940]
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: integration testing: 'lost' data
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
2014-05-14 11:38 GMT+01:00 GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
:
> Hi, Erik.
>
> Perhaps DN holds them still "in memory" and has not been flushed to the
> database.
>
>
I don't think that DN does, but Isis certainly does holds them in memory
until the flush or commit.
Dan
> Normally, it can be done by calling "flush" on the DomainContainer,
> similar to:
>
> this.getContainer().flush();
>
>
> HTH,
>
> Oscar
>
>
>
>
>
>
> El 14/05/2014, a las 12:27, Erik de Hair <er...@pocos.nl> escribió:
>
>
> Hi,
>
> I'm writing a test with some inserts in the @Before and a query to find
> the inserted objects (ResellerPortalIntegTest is the original
> SimpleIntegTest-class):
>
> public class ContactsTest extends ResellerPortalIntegTest {
>
> private Role role;
>
> private final String uniqueEmail = "jan@pokos.nl"<ma...@pokos.nl>
> >;
> private final String duplicateEmail = "marie@pokos.nl"<
> mailto:marie@pokos.nl <ma...@pokos.nl>>;
> private final String unkownEmail = "xyzabc@bladiblah.com"<
> mailto:xyzabc@bladiblah.com <xy...@bladiblah.com>>;
>
> @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, "piet@pokos.nl"<mailto:piet@pokos.nl <pi...@pokos.nl>>,
> "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.
>
> Is this an Isis issue or do I have to look for a Datanucleus/other
> solution?
>
> Thanks,
> Erik
>
>
>
> Óscar Bou Bou
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> 902 900 231 / 620 267 520
> http://www.twitter.com/oscarbou
>
> http://es.linkedin.com/in/oscarbou
>
> http://www.GesConsultor.com <http://www.gesconsultor.com/>
>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo -
> 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia).
> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
> adjuntos no contengan virus informáticos, y en caso que los tuvieran
> eliminarlos.
>
>
>
>
>
>
Re: integration testing: 'lost' data
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Hi, Erik.
Perhaps DN holds them still "in memory" and has not been flushed to the database.
Normally, it can be done by calling "flush" on the DomainContainer, similar to:
this.getContainer().flush();
HTH,
Oscar
El 14/05/2014, a las 12:27, Erik de Hair <er...@pocos.nl> escribió:
> Hi,
>
> I'm writing a test with some inserts in the @Before and a query to find the inserted objects (ResellerPortalIntegTest is the original SimpleIntegTest-class):
>
> public class ContactsTest extends ResellerPortalIntegTest {
>
> private Role role;
>
> private final String uniqueEmail = "jan@pokos.nl"<ma...@pokos.nl>;
> private final String duplicateEmail = "marie@pokos.nl"<ma...@pokos.nl>;
> private final String unkownEmail = "xyzabc@bladiblah.com"<ma...@bladiblah.com>;
>
> @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, "piet@pokos.nl"<ma...@pokos.nl>, "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.
>
> Is this an Isis issue or do I have to look for a Datanucleus/other solution?
>
> Thanks,
> Erik
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.