You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Tony Giaccone <to...@giaccone.org> on 2018/08/13 21:07:08 UTC
Migrating Schemas
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
Re: Migrating Schemas
Posted by Bob Schellink <sa...@gmail.com>.
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
On Tue, Aug 14, 2018 at 9:36 AM Andrus Adamchik <an...@objectstyle.org>
wrote:
> 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 <to...@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
>
>
Re: Migrating Schemas
Posted by Tony Giaccone <tg...@gmail.com>.
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 <ma...@selbstdenker.ag> wrote:
> > Am 14.08.2018 um 13:00 schrieb Andrus Adamchik <an...@objectstyle.org>:
> >
> >> 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
>
>
Re: Migrating Schemas
Posted by Maik Musall <ma...@selbstdenker.ag>.
> Am 14.08.2018 um 13:00 schrieb Andrus Adamchik <an...@objectstyle.org>:
>
>> 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
Re: Migrating Schemas
Posted by Andrus Adamchik <an...@objectstyle.org>.
> 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 <ma...@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 <an...@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 <to...@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
>>
>
Re: Migrating Schemas
Posted by Maik Musall <ma...@selbstdenker.ag>.
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 <an...@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 <to...@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
>
Re: Migrating Schemas
Posted by Andrus Adamchik <an...@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 <to...@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