As I don’t like and use the DB-first approach [1], I use cayenne-migrations for this. It works a lot like ERXMigration in WOnder.
https://github.com/hugith/cayenne-migrations <https://github.com/hugith/cayenne-migrations> (original: https://github.com/johnthuss/cayenne-migrations <https://github.com/johnthuss/cayenne-migrations> but outdated) Maik [1] We make changes to the application, including model changes, which then go into staging, and eventually end up in production. Staging and dev databases are replaced by fresh copies of the production database every week. So code and model are first, and also the model may differ between branches as we develop several features in parallel. I have no idea how anyone who has more than just a single production database could use a db first approach. > Am 14.08.2018 um 09:36 schrieb Andrus Adamchik <and...@objectstyle.org>: > > The modeler migrate schema functionality is not sophisticated enough for > production workflows. So I suggest Liquibase for migrations and DB-first > approach to ORM. > > Andrus > > >> On Aug 14, 2018, at 12:07 AM, Tony Giaccone <t...@giaccone.org> wrote: >> >> I've made some changes to the schema on a project I'm working on. I >> selected Migrate Schema, and worked through the Wizard and in the end it >> wants to drop tables. Some of my tables are rather large, and recreating >> them would be... painful. Is there a way to find the diffs that the model >> identified, as opposed to the drop table that it suggested? >> >> Any suggestions? I can of course figure out the differences by hand the >> number of tables is small, only 5.. but I'd like to understand how the >> modeler decides what path to take when it sees diffs. >> >> >> Tony >
