This was the point that I was making in my comment in https://issues.apache.org/jira/browse/CAY-1633 . A DB migrations mechanism is very important to Cayenne users (as of course their apps are using some DB). But IMO it is a concern that can't be adequately addressed by Cayenne abstractions, and hence IMO should be kept separate.
John, you are comparing your API with DbGenerator and DbMerger, and there's no question that it is more advanced than those two. I'd be comparing it with the existing migrations tools, such as http://code.google.com/p/c5-db-migration/ . This may sound odd coming from a Cayenne guy, but I like c5 approach (and similar home-grown approach that I've been using on other projects) precisely because migrations are written in SQL. However regardless of the use case for migrations (controlled DB vs unknown DB; migration scripts embedded in the app and run on startup vs. independently from the app during deployment), you'd have to write advanced SQL that can't be mapped to Cayenne model. E.g. you move the data to a new column, transforming the data in the process, generate a table aggregate from subsets of other tables, etc. etc. Wrapping such SQL in Java doesn't give you much, just obfuscates things. Andrus On Dec 20, 2011, at 9:47 PM, Aristedes Maniatis wrote: > On 21/12/11 7:01 AM, John Huss wrote: >> *I’m interested in having more flexible support for database migrations in >> Cayenne, so I wrote a new migrations API on top of the existing DbMerger >> constructs. > > My question: why not use a third party tool like liquibase? > > Or even write tighter connections between liquibase and Cayenne by allowing > Cayenne to output the liquibase migration script. Liquibase solves lots of > problems, like knowing which migrations have run, conditional migrations, > logging, locking, etc. > > > Ari
