We use liquibase to execute SQL combined with special liquibase functions to run groovy/Java classes which are needed to do more complex migrations in code (within the Cayenne model). Those complex migrations might include adding new data to the DB or modifying existing records in ways that SQL is too cumbersome for.
Where we come unstuck is that if a bug was introduced 20 versions ago, it can be hard to recover. Phabricator (an open source project management, code review solution written by Facebook) has a neat feature: it verifies your model each time you run the upgrade. So if an index is missing, then the code will just add it. If a collation is wrong, then it is fixed. I'd be pleased to have something similar as a library for Cayenne. Obviously we'd need to add meta-data to the model like indices, but having a 'please make the DB look like my model' feature would be great. Obviously it isn't going to be able to fix everything, but for non-destructive changes like indices it would be really useful. Ari On 10/2/17 9:41am, Andrus Adamchik wrote: > FWIW, the workflow I am using is "DB-first", and Cayenne 4.0 is providing the > tools to make it practical and mostly automated: > > 1. Use a migration tool like Flyway or Liquibase to code your migrations in > SQL (even more so when wrapped in bootique-liquibase / bootique-flyway). > 2. Run cdbimport from Maven/Ant/Gradle to sync Cayenne model from DB. > 3. In the modeler fix any object naming discrepancies, map custom value > objects, map inheritance. > 4. Run cgen to sync Java classes from Cayenne model > 5. Rinse and repeat. > > Can someone please explain the workflow with ERX|cayenne migrations? What are > the advantages over the approach above? Does it handle data migrations or > only the schema? > > Andrus > > >> On Feb 10, 2017, at 7:06 AM, John Huss <johnth...@gmail.com> wrote: >> >> I pushed the changes I had pending - there was more than I thought. >> >> I'm fine with it going in, but I'm not sure that the community agrees. >> Since this can live as an independent project / jar there isn't really a >> need to merge it into the main cayenne repo. But if we are going to keep >> it separate we should move it to github or something where participation is >> easier. >> >> Another issue - I'm pretty sure this won't build or run against cayenne's >> master anymore due the to refactoring of DbMerger stuff. But I haven't >> tried. >> >> On Thu, Feb 9, 2017 at 1:14 PM Musall, Maik <m...@selbstdenker.ag> wrote: >> >>> Hi John, >>> >>> how do you (and everyone else) feel about including this in the main repo >>> after polishing? >>> >>> I'm working with Hugi here on a project and would like to continue using >>> this style of >>> migrations because our entire environment is geared towards it. I'd love >>> for this to be in >>> the main cayenne repo so we can submit our improvements. >>> >>> Maik >>> >>>> Am 09.02.2017 um 15:59 schrieb John Huss <johnth...@gmail.com>: >>>> >>>> It's current except for a single small change. I seem to have lost the >>>> push url, so I need to get it working again to update it. But it would >>> be >>>> fine for playing with as is. >>>> >>>> On Thu, Feb 9, 2017 at 9:45 AM Hugi Thordarson <h...@karlmenn.is> wrote: >>>> >>>>> Hi John, >>>>> that’s very interesting. Is your current work public or is the most >>> recent >>>>> public work in the SVN-repo I mentioned? >>>>> >>>>> Cheers, >>>>> - hugi >>>>> >>>>> >>>>>> On 9. feb. 2017, at 15:36, John Huss <johnth...@gmail.com> wrote: >>>>>> >>>>>> I'm developing and using cayenne-migrations. It works fine for me and >>>>> has a >>>>>> very similar approach to ERXMigrations. I don't think others are using >>>>> it >>>>>> though. It has the advantage of being able to auto-generate the >>>>> migration >>>>>> code from your cayenne model (DataMap), where I think the others >>> require >>>>>> hand coding. On the other hand, sometimes having all pure SQL >>> statements >>>>>> instead of mostly java code is useful. Good luck! >>>>>> >>>>>> John >>>>>> >>>>>> On Thu, Feb 9, 2017 at 9:15 AM Michael Gentry <mgen...@masslight.net> >>>>> wrote: >>>>>> >>>>>>> Hi Hugi, >>>>>>> >>>>>>> We manage schema changes outside of Cayenne using Flyway (could also >>> use >>>>>>> Liquibase). Any schema changes we make are updated by hand in Cayenne >>>>>>> Modeler. This works fairly well for us and fits in with our automated >>>>>>> builds/etc. Perhaps not the answer you were looking for, though! >>>>>>> >>>>>>> mrg >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 9, 2017 at 9:21 AM, Hugi Thordarson <h...@karlmenn.is> >>>>> wrote: >>>>>>> >>>>>>>> Hi all. >>>>>>>> In EOF/WOnder we have the most swesome ERXMigrations to manage >>> changes >>>>> in >>>>>>>> the data model between versions, i.e. upgrades of the schema (and >>>>>>>> downgrades, if applicable). >>>>>>>> >>>>>>>> I see that some years ago there was discussion of an API to handle >>> this >>>>>>> in >>>>>>>> Cayenne ( http://svn.apache.org/repos/asf/cayenne/sandbox/cayenne- >>>>>>>> migrations/ ). but how’s the situation today? Is there something >>> in/for >>>>>>>> Cayenne to do this, and if not, what tools are people using to manage >>>>>>>> versioning of their DB schemas? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> - hugi >>>>>>> >>>>> >>>>> >>> >>> > -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
