Cycle (and Engine?) Persistence need refactoring

[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
Bernd

[bernd_ruecker]

Hey!

This issue gets more urgent, since the persistence code in the engine already has changed and I just have quickly adopted our code to it. But we currently already have no support for the "DBSCHEMASTRATEGY_CREATE_IF_NECESSARY" strategy and the whole implementation is a bit hacky.

@Tom: Could you maybe have a look into it? It is basically the class "AbstractCycleDaoMyBatisImpl" and you will see the problem we had there…

That would be really nice!

Cheers
Bernd

[tombaeyens]

In the meantime, I think it is a good idea if the Cycle tables are separate from the Engine tables so that Cycle can run independant of the engine.   Does that answer the most important part of this topic?  Are there other outstanding questions?

Last time I looked, you had a lot of duplicated code with respect to the DbSqlSessionFactory/DbSqlSession.  Is that still the case?  If yes, do you think we could allow better reuse here?  I think it should be possible that cycle can work independent (no engine tables) but still leverage the base persistence infrastructure from the engine.  WDYT?

[bernd_ruecker]

Hey Tom.

Hmm, that's exactly what I wanted the whole time 🙂 As I already wrote, I want to get rid of the duplicated code as well, but that needs some refactoring in the SessionFactory & Session code in the engine. And this would be good, if you can have a look at it (especially AbstractCycleDaoMyBatisImpl). Would that be possible for you?

[bernd_ruecker]

Short addition: The InternalActivitiTestCase offers a method assertAndEnsureCleanDb(). This currently only works hard coded with Engine tables. So this would be nice as well to extend/improve to be usable in both components. If you have an idea to this as well? Unfortunately I will not really have much time till the GA to look into this stuff myself 😞