AnsweredAssumed Answered

splitting persistence into modules

Question asked by tombaeyens on Feb 7, 2011
Latest reply on Feb 9, 2011 by tombaeyens
as a side track of (Distill db name from the datasource), I split up the persistence modules.  create, drop and update of tables is done per component.  The 4 components are
* engine
* history
* identity
* cycle

In the ProcessEngineConfigurationImpl, those 4 components can be turned on or off:

  protected boolean isDbEngineUsed = true;
  protected boolean isDbIdentityUsed = true;
  protected boolean isDbHistoryUsed = true;
  protected boolean isDbCycleUsed = false;

But spontaneously it looks a bit wired to create all tables in the engine, than the two modules get really tightly coupled. What is the motivation?

The dependency basically remains the same: a library dependency.

The only thing we have have to revisit is how you build your service.  you have to create a ProcessEngineConfiguration.  You could create a CycleConfiguration and then inherit from ProcessEngineConfiguration or have a ProcessEngineconfiguration member field depending on which config items you want to expose.

In various refactorings I have bumped into the cycle specific persistence behaviour.  Also in the QA/CI scripts.  This needs to be unified for consistency and ability to manage it.

I have taken into account your feature request that it should be possible to create and work only with the Cycle tables.   This can be achieved by setting isDbCycleUsed to true and the other 3 booleans to false.  This could be done e.g. in a CycleConfiguration as described above.