Hi Scott,
It's not a problem with the test framework, it is with my custom demo
data. In my demo data, I was creating workEfforts with id's of 10020
and 10030.
During testing I was creating more workEfforts. At one stage, the tests
were failing because the new workEfforts were getting
Hi Chris,
On Jan 22, 2010, at 1:29 PM, Chris Snow wrote:
Hi Scott,
It's not a problem with the test framework, it is with my custom demo data.
In my demo data, I was creating workEfforts with id's of 10020 and 10030.
During testing I was creating more workEfforts. At one stage, the
Jacopo Cappellato wrote:
Hi Chris,
On Jan 22, 2010, at 1:29 PM, Chris Snow wrote:
Hi Scott,
It's not a problem with the test framework, it is with my custom demo data.
In my demo data, I was creating workEfforts with id's of 10020 and 10030.
During testing I was creating more
I seems that data created in one test case (e.g. a created workEffort)
is still in the db when I run the next test case.
Scott Gray wrote:
There was a reason I didn't do this, I just can't remember what it was.
Thinking about it freshly, the reason was most likely that asynchronous service
Could be, like I said async services can't be rolled back at the moment. We're
usually just left with a few CommunicationEvent records from order confirmation
emails and there's also a TestingType record created by the service engine
tests which causes an entity engine test to fail on
Hi Scott,
It's no problem - I just wanted to make sure I'm not doing something wrong.
Many thanks,
Chris
Scott Gray wrote:
Could be, like I said async services can't be rolled back at the moment. We're
usually just left with a few CommunicationEvent records from order confirmation
emails
It appears that test data gets rolled back after a test, EXCEPT for
sequence id's.
I would expect all data generated during a test to get rolled back.
Any comments?
Many thanks,
Chris
In a busy system where you might have a dozen other sequenced IDs issued by the
time your transaction is either committed or rolled back... what sorts of
problems do you think this would introduce?
There are two categories I'm thinking of: performance and data consistency.
-David
On Jan
There was a reason I didn't do this, I just can't remember what it was.
Thinking about it freshly, the reason was most likely that asynchronous service
calls can't be rolled back currently (they're executed by the JobManager with a
regular delegator) and rolling back the sequence ids would
