+1 for the documentation of database changes.We alreadyy do this for customer projects, along with (database specific) data migration scripts.
I'm not sure if we can afford to provide sophisticated additional tool support which is maintained continiously?
As a conclusion, I think we should setup a convention that any database model change has to provide a proper change log and migration script for the embedded database (if applicable).
Thanks, Michael Am 01.09.17 um 15:24 schrieb Taher Alkhateeb:
Groovy scripts are also great and can do the job. To comment on the "advantage" of something like flyway or liquibase I can try to list some: - The scripts might get too big or complex to accommodate different databases and platforms. - Out of the box, these solutions are database independent - Ability to redo / undo on schema changes - Supporting declarative style for schema definitions based on multiple formats (YAML, XML, JSON, etc ..) - The DSL is easier to use (declarative and short) So in short, both solutions are viable, and existing solutions might be a bit easier to implement especially if you consider additional features in those solutions. On Fri, Sep 1, 2017 at 2:23 PM, Nicolas Malin <nicolas.ma...@nereide.fr> wrote:I'm in favor to tracking the different migration but at this time I didn't see the advantage to use flyway or other instead of manage easily by ofbiz throw groovy script. I'm available to help for design or create a POC do realize it because many time in the past (and currently ow) I want to refactoring some code/db schema with data migration but we haven't clean process to do that. Nicolas Le 31/08/2017 à 12:37, Jacques Le Roux a écrit :Le 31/08/2017 à 12:32, Taher Alkhateeb a écrit :I would personally prefer to not go any earlier than 13, or preferably just 16 to trunk, which means we design this solution for the future, not necessarily the past.+1 Jacques
smime.p7s
Description: S/MIME Cryptographic Signature
