Liquibase Integration Clearance

[catandgrep]

Tijs, Joram,

Can you confirm that you abandoned liquibase implementation efforts in activiti. I have seen several commits from tijs starting to integrate it, but last week joram suddenly reverted all the changes.

Whats the background on this commit history? Are you still planning to integrate it in the near future? Would be great if you can share your last thoughts on that.

I personally like the as is solution. So please don't consider this as a liquibase feature request

Thanks.
Andreas

[jbarrez]

Good question. Tijs has spent quite some time the last few weeks on Liquibase integration.
And the results looked good: one file for DDL definition and changesets.
But every time we thought we were 'done', a new issue arised. In the end, we felt we wouldn't see the end of it in feasable time.
Hence, we reverted.

I pinged Tijs, he will be able to give more insights.

[trademak]

Hi,

I reverted the changes myself, maybe it also came back in Joram's master merge.
In short, yes we abandoned the Liquibase implementation and reverted back to the old script approach.
With some more background. We had a community contribution that gave us a head-start for a Liquibase implementation.
For us maintaining the scripts for every database is a time consuming job, and if something like Liquibase could do the hard work, that would be great.
With a couple of startup hurdles the Liquibase implementation was progressing quite well. A week ago most of our QA jobs were running green and it looked quite okay.
Until….., we investigated a JTA issue a bit further and we noticed that we couldn't control the commit call in Liquibase.
Of course, this is also a quite logical choice in Liquibase, because updating your schema doesn't require a JTA transaction.
But the way Activiti is setup with transaction handling and command execution this didn't work.
Then we decided to generate the database scripts from Liquibase and still use the script approach so we can control the transaction ourselves.
That worked okay, but there were some subtle changes in the generation of the schema for, for example MSSQL.
And since we also have to focus on proving decent upgrades this didn't work either.
When we could start over and we wouldn't have done any releases, Liquibase script generation would be a fine solution for us. But with the releases already out there, there are just too many subtle differences in the SQL.
Hope this provides some more insight in our reasoning.

Best regards,

[catandgrep]

Hi,
…
Hope this provides some more insight in our reasoning.
…

Yes. Thanks.

[thilka]

Hello Activiti Team,

I am really sad to hear about your decission to revert the changes and discard Liquibase.
Having worked in product development for several years and after rolling out an own implementation of a database schema change tool, we switched to Liquibase when we started developing our new product with Activiti in it.

For me, it seems like we always try to re-invent the wheel. It's like saying to people, do not implement your own process engine, use existing ones like Activiti from the beginning. Might be harder to start, but in the end it pays of a hundred times.

I can totally understand why you don't want to have the switch to liquibase now, after having more than 10 releases.

Still, I never want to start a project again without Liquibase (if a database is involved) and without Activiti (if processes are involved).

Let's focus on business value, not on technical issues. There are frameworks out there that let you get rid of (most of) dirty details of the underlying technology.

Tobias

[trademak]

Hi,

I fully agree that Liquibase is an excellent framework and I'm not happy that we had to revert back from it.
But there are just too many issues we run into with respect to backwards compatibility.

Best regards,