cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <johnth...@gmail.com>
Subject Re: Cayenne and migrations
Date Thu, 09 Feb 2017 23:17:13 GMT
> Can someone please explain the workflow with ERX|cayenne migrations? What
are the advantages over the approach above? Does it handle data migrations
or only the schema?

Mainly schema migrations.

I think the advantages are:
1) Cross-database support from a single representation. So you can run the
same migrations on different databases without having to code specifically
to each DB. This seems to fit well within an ORM.
2) Auto-generation of java migration code from DataMap. This is currently
only supported for the initial migration (whole database), but you can
still use that to copy/paste code for new tables.  In the future it could
connect to your DB to generate a delta migration automatically, but I'm not
sure it would be worth doing.
3) You retain the ability to write raw SQL as part of the migration, and
this can be targeted at a specific database vendor if needed.  This is how
data migrations would be handled.
4) In the future the library could optimize DB changes, like combining
multiple add column statements into a single statement, which could provide
better performance.

On Thu, Feb 9, 2017 at 4:45 PM Andrus Adamchik <andrus@objectstyle.org>
wrote:

> > 1. Use a migration tool like Flyway or Liquibase to code your migrations
> in SQL (even more so when wrapped in bootique-liquibase / bootique-flyway).
>
> "even more so" -> "especially easy to run"
>
>
> > On Feb 10, 2017, at 9:41 AM, Andrus Adamchik <andrus@objectstyle.org>
> wrote:
> >
> > FWIW, the workflow I am using is "DB-first", and Cayenne 4.0 is
> providing the tools to make it practical and mostly automated:
> >
> > 1. Use a migration tool like Flyway or Liquibase to code your migrations
> in SQL (even more so when wrapped in bootique-liquibase / bootique-flyway).
> > 2. Run cdbimport from Maven/Ant/Gradle to sync Cayenne model from DB.
> > 3. In the modeler fix any object naming discrepancies, map custom value
> objects, map inheritance.
> > 4. Run cgen to sync Java classes from Cayenne model
> > 5. Rinse and repeat.
> >
> > Can someone please explain the workflow with ERX|cayenne migrations?
> What are the advantages over the approach above? Does it handle data
> migrations or only the schema?
> >
> > Andrus
> >
> >
> >> On Feb 10, 2017, at 7:06 AM, John Huss <johnthuss@gmail.com> wrote:
> >>
> >> I pushed the changes I had pending - there was more than I thought.
> >>
> >> I'm fine with it going in, but I'm not sure that the community agrees.
> >> Since this can live as an independent project / jar there isn't really a
> >> need to merge it into the main cayenne repo.  But if we are going to
> keep
> >> it separate we should move it to github or something where
> participation is
> >> easier.
> >>
> >> Another issue - I'm pretty sure this won't build or run against
> cayenne's
> >> master anymore due the to refactoring of DbMerger stuff.  But I haven't
> >> tried.
> >>
> >> On Thu, Feb 9, 2017 at 1:14 PM Musall, Maik <maik@selbstdenker.ag>
> wrote:
> >>
> >>> Hi John,
> >>>
> >>> how do you (and everyone else) feel about including this in the main
> repo
> >>> after polishing?
> >>>
> >>> I'm working with Hugi here on a project and would like to continue
> using
> >>> this style of
> >>> migrations because our entire environment is geared towards it. I'd
> love
> >>> for this to be in
> >>> the main cayenne repo so we can submit our improvements.
> >>>
> >>> Maik
> >>>
> >>>> Am 09.02.2017 um 15:59 schrieb John Huss <johnthuss@gmail.com>:
> >>>>
> >>>> It's current except for a single small change.  I seem to have lost
> the
> >>>> push url, so I need to get it working again to update it.  But it
> would
> >>> be
> >>>> fine for playing with as is.
> >>>>
> >>>> On Thu, Feb 9, 2017 at 9:45 AM Hugi Thordarson <hugi@karlmenn.is>
> wrote:
> >>>>
> >>>>> Hi John,
> >>>>> that’s very interesting. Is your current work public or is the
most
> >>> recent
> >>>>> public work in the SVN-repo I mentioned?
> >>>>>
> >>>>> Cheers,
> >>>>> - hugi
> >>>>>
> >>>>>
> >>>>>> On 9. feb. 2017, at 15:36, John Huss <johnthuss@gmail.com>
wrote:
> >>>>>>
> >>>>>> I'm developing and using cayenne-migrations. It works fine for
me
> and
> >>>>> has a
> >>>>>> very similar approach to ERXMigrations.  I don't think others
are
> using
> >>>>> it
> >>>>>> though.  It has the advantage of being able to auto-generate
the
> >>>>> migration
> >>>>>> code from your cayenne model (DataMap), where I think the others
> >>> require
> >>>>>> hand coding.  On the other hand, sometimes having all pure SQL
> >>> statements
> >>>>>> instead of mostly java code is useful.  Good luck!
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>> On Thu, Feb 9, 2017 at 9:15 AM Michael Gentry <
> mgentry@masslight.net>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Hi Hugi,
> >>>>>>>
> >>>>>>> We manage schema changes outside of Cayenne using Flyway
(could
> also
> >>> use
> >>>>>>> Liquibase).  Any schema changes we make are updated by hand
in
> Cayenne
> >>>>>>> Modeler.  This works fairly well for us and fits in with
our
> automated
> >>>>>>> builds/etc.  Perhaps not the answer you were looking for,
though!
> >>>>>>>
> >>>>>>> mrg
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Feb 9, 2017 at 9:21 AM, Hugi Thordarson <hugi@karlmenn.is>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi all.
> >>>>>>>> In EOF/WOnder we have the most swesome ERXMigrations
to manage
> >>> changes
> >>>>> in
> >>>>>>>> the data model between versions, i.e. upgrades of the
schema (and
> >>>>>>>> downgrades, if applicable).
> >>>>>>>>
> >>>>>>>> I see that some years ago there was discussion of an
API to handle
> >>> this
> >>>>>>> in
> >>>>>>>> Cayenne (
> http://svn.apache.org/repos/asf/cayenne/sandbox/cayenne-
> >>>>>>>> migrations/ ). but how’s the situation today? Is there
something
> >>> in/for
> >>>>>>>> Cayenne to do this, and if not, what tools are people
using to
> manage
> >>>>>>>> versioning of their DB schemas?
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> - hugi
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message