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 <[email protected]> wrote: > > Am 14.08.2018 um 13:00 schrieb Andrus Adamchik <[email protected]>: > > > >> 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. > > I don’t really understand how schemas are related to this. I use schemas > as namespaces. > > > 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? > > Only in the way that I can execute regular SQL along with the coded > migration steps. ERXMigration has an index creation feature as well, but > with cayenne-migrations I always create them using bare SQL. Of course any > data migration is possible that way too. And of course cayenne-migrations > can also be extended to cover these things. > > > (Of course a big argument *against* DB-first is schemas that don't > follow naming conventions). > > Which is probably often the case with long-term projects like mine that > started off based on EOF a decade ago. > > Maik > >
