AnsweredAssumed Answered

Cycle (and Engine?) Persistence need refactoring

Question asked by bernd.ruecker on Sep 24, 2010
Latest reply on Nov 3, 2010 by bernd.ruecker
Hey guys.

We checked in the first DB persistence for Cycle in the meantime. Currently it just saved the Cycle Configuration to the database as a first step. We wanted to leverage which was already there in the DbSqlSessionFactory (e.g. create-drop mechanism). But one goal was, that cycle persistence keeps independent of the engine in a way, that we want to have the possibility to run Cycle only with the Cycle database but without any tables for the engine. But we still want to use the Bootstrapping and configuration mechanism of the Engine/PVM.

But that seems to be harder than I thought. Currently we extended the DbSqlSessionFactory with a CycleDbSqlSessionFactory and overwrote some methods to use the correct mapping and sql files. But that feels a bit hacky.

And we use the ProcessEngines.getDefaultProcessEngine()).getProcessEngineConfiguration() to create that class. This internally already starts the Engine DB Session, so we need the tables for the engine again ;-)

I think it would be good if somebody who wrote the wiring and persistence can have a look on that and maybe refactor it (after the code freeze in our branch or after the release of course). Maybe Tom?

Thanks a lot and cheers