-
1. Re: persistence extension and liquibase
bmajsak Jun 10, 2013 5:36 AM (in response to kumm0307)Hi Tamas,
thanks a lot for looking at it and welcome in the community! Even though the code is just a proof-on-concept, it clearly shows that's it is relatively easy to integrate with Liquibase. My main goal for this integration is not only to use it through @CreateSchema but also through "data sets" annotation. The only thing I'm not yet sure how to deal with is how to provide data comparison through @ShouldMatchDataSet, so that you verify database content by comparing the current state with provided datasets/changelogs. Do you have any idea if it's doable through Liquibase API?
In fact I started working on SPI to facilitate such needs like Liquibase or NoSQLUnit integration, but it's currenty put aside, as I was working on some other improvements and fixes in APE. Nevertheless it looks like it should give it highest prio back.
There is one important question we need to address upfront - shall we have "only one SPI" approach or we do allow having multiple implementations on the classpath. In other words - do we want to use both DBUnit and Liquibase together in one test case or we rather stick to mutually exclusive approach?
Would you be interested to continue the work on Liquibase once I introduce SPI mechanism? Of course you can count on my help any time.
Cheers,
Bartosz
-
2. Re: persistence extension and liquibase
kumm0307 Jun 10, 2013 4:57 PM (in response to bmajsak)Hi!
My main goal for this integration is not only to use it through @CreateSchema but also through "data sets" annotation. The only thing I'm not yet sure how to deal with is how to provide data comparison through @ShouldMatchDataSet, so that you verify database content by comparing the current state with provided datasets/changelogs. Do you have any idea if it's doable through Liquibase API?
I'm afraid there is no such diff functionality in liquibase.
The only diff liquibase can generate is the diff between two database. It's main purpose is to compare the stucture. Data comparing is limited (never used this, but the liquibase site says).
There is no information about the kind of the limitation, but it's the smaller problem. I think the two database thing is not what we want.
Supporting Liquibase in @ShouldMatchDataSet is a hard goal.
You can define data by native sql, insert changeset, or loaddata changeset. And what if it contains update, or delete?
You don't know what data defined before you run on a real database. It's like sql, and more.
Maybe is the plan to support just the few changeset type designed for data loading? (loadData, loadUpdateData)
There is one important question we need to address upfront - shall we have "only one SPI" approach or we do allow having multiple implementations on the classpath. In other words - do we want to use both DBUnit and Liquibase together in one test case or we rather stick to mutually exclusive approach?
I'm pretty sure i want use dbUnit too. Liquibase data loading supports only csv data format. (I don't count sql, and insert changeset as data format)
Would you be interested to continue the work on Liquibase once I introduce SPI mechanism? Of course you can count on my help any time.
Thanks, of course i'm interested