Minor Description
Originally this ticket was much narrower in scope, simply to introduce nextTransaction() into fixture scripts.
This was implemented by adding nextTransaction() to DomainObjectContainer.
From there though I decided that DOC was become too bloated, so split it out into a number of other domain services:
- TransactionService ... for this new method and also flushTransaction
but then eventually also:
- RepositoryService (persist, allMatches, uniqueMatch, firstMatch)
- MessageService (informUser, warnUser, raiseError)
- ConfigurationService (getProperties etc)
- ServiceRegistry (lookupService, injectServicesInto)
The existing DOC methods have been deprecated, the DOCDefault impl delegates to the new services.
~~~~
The original request for this ticket was raised by Oscar:
When using FixtureScripts, there can be many actions that, on the real world, are execute in different time contexts.
For example, a user creates an Account on the webapp and after that executes different actions.
That’s relevant if using the queryResultsCache service (or the new planned “@Action” annotation extension) because the results previously created (i.e., the Account) might be available on the cache.
So perhaps some mechanism like the nextTransation() method might be also introduced on FixtureScripts.
What do you think?
~~~~~~~
Dan's reply:
Makes sense.
There is a nextTransaction() method in the AbstractIntegTest class, you could see how that is implemented and see if it can be adapted?
Or, another idea is that the framework could run each FixtureScript automatically in a separate transaction; that would be a better simulation of a sequence of user interactions?