cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <>
Subject Re: Handling database creation and migration
Date Wed, 21 Dec 2011 19:16:42 GMT
On Wed, Dec 21, 2011 at 7:06 AM, Andrus Adamchik <>wrote:

> This was the point that I was making in my comment in
> . A DB migrations
> mechanism is very important to Cayenne users (as of course their apps are
> using some DB). But IMO it is a concern that can't be adequately addressed
> by Cayenne abstractions, and hence IMO should be kept separate.

The thing is, Cayenne already comes very close to doing what I need.  It
can already generate all of the most common DDL statements for all
supported databases.  It can already generate a list of differences between
the DataMap and the DB.  All I want is more explicit control over this
existing functionality.  So what I wrote is really just a small wrapper on
top of the existing Cayenne code.

One advantage to doing it this way versus using a third-party tool is that
the SQL eventually outputted can match exactly with the SQL that is
generated using the "Generate Database Schema" button in CayenneModeler
(since it uses the same code under the hood).

> John, you are comparing your API with DbGenerator and DbMerger, and
> there's no question that it is more advanced than those two. I'd be
> comparing it with the existing migrations tools, such as
> . This may sound odd coming
> from a Cayenne guy, but I like c5 approach (and similar home-grown approach
> that I've been using on other projects) precisely because migrations are
> written in SQL.

For many things, multiple databases can be supported without needing
separate migration scripts for each DB (every operation that has a
MergerToken subclass). This is an advantage over the pure SQL approach.

However regardless of the use case for migrations (controlled DB vs unknown
> DB; migration scripts embedded in the app and run on startup vs.
> independently from the app during deployment), you'd have to write advanced
> SQL that can't be mapped to Cayenne model. E.g. you move the data to a new
> column, transforming the data in the process, generate a table aggregate
> from subsets of other tables, etc. etc. Wrapping such SQL in Java doesn't
> give you much, just obfuscates things.

For things that aren't supported (or for people that prefer raw SQL) this
lets you use raw SQL easily so you can have a hybrid approach.  There would
be no attempt to have a Java API around this sort of thing.  Although,
something like SQLTemplate could be very helpful here in reducing
duplication.  The API would only support the operations available via the

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