Re: Migrating Schemas

Bob, thanks for your suggestion. Setting the schema in the model to be the actual value of the schema, in this case public, allowed the Modeler to do a detailed migrations that did not include dropping the table. Thank you On Tue, Aug 14, 2018 at 11:36 AM, Maik Musall wrote: > > Am 14.08.2018 u

Re: Migrating Schemas

> Am 14.08.2018 um 13:00 schrieb Andrus Adamchik : > >> 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

Re: Migrating Schemas

> 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

Re: Migrating Schemas

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 (original: https://github.com/johnthuss/cayenne-migrations

Re: Migrating Schemas

Not sure how the migration tool determines the diff, but at least in Postgres if the dbentity schema doesn't match the database schema Cayenne cannot find the table in the database and will drop it. When I added the schema 'public' to the dbentity Cayenne' diff worked properly. kind regards Bob

Re: Migrating Schemas

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 wrote: > > I've made some changes to the schema on a project I'm working on.