> I have no idea how anyone who has more than just a single production > database could use a db first approach.
Why would using multiple schemas be any different? I usually partition models by schema, but doing a reverse-engineering from more than one is not a problem. What I never understood with ORM-based migrations is how do you migrate your *data* or describe more advanced DB artifacts, like indexes? Do ERXMigration and the cayenne-migrations frameworks below address that in some way? (Of course a big argument *against* DB-first is schemas that don't follow naming conventions). Andrus > On Aug 14, 2018, at 12:59 PM, Maik Musall <m...@selbstdenker.ag> wrote: > > 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 >> >
