Uploaded image for project: 'Isis'
  1. Isis
  2. ISIS-1228

Reorganizing/splitting out DomainObjectContainer service.

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: core-1.8.0
    • Fix Version/s: 1.12.0
    • Component/s: Core
    • Labels:
      None

      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?

        Attachments

          Activity

            People

            • Assignee:
              danhaywood Dan Haywood
              Reporter:
              danhaywood Dan Haywood
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: