I've commented on this in the past (at least my feelings on the matter).
Once I get an initial schema mapped out and checked into CVS (or
Subversion or whatever source control tool you use), I prefer to update
the DB manually (creating an update script for the SQL) and then update
the model manually, too. This way I don't lose any pre-existing data.
The update script gets checked into CVS (easier to keep these in a
separate directory), too. You can call them updateSchema.01,
updateSchema.02, etc. Whenever you need to update a schema from one
revision to another, you know precisely what steps to go through to get
it up to a particular model revision (just apply the needed schema
changes in order). This also gives you a history of all the changes,
plus different developers can be using different development DBs and
upgrade their schemas relatively easy. Of course, once you go into
production, the same procedure applies there, too (you don't want your
production data wiped out). To me, it makes more sense to perfect the
update process in development than in production -- use the same
procedure everywhere.
So, while it would be cool if the tool could just "make it so", I don't
think this is the best approach in the real world.
Just my $0.02...
/dev/mrg
-----Original Message-----
From: Kevin J. Menard, Jr. [mailto:nirvdru..egativetwenty.net]
Sent: Tuesday, September 07, 2004 8:13 AM
To: Andrus Adamchik
Cc: cayenne-use..bjectstyle.org
Subject: Re[2]: Update DB Schema
Hello Andrus,
Tuesday, September 7, 2004, 1:00:09 AM, you wrote:
AA> If this is just such simple change, I would manually add a column to
AA> DB, and then manually add a corresponding attribute to DbEntity in
AA> CayenneModeler (and then you can "Sync ObjEntity with DbEntity).
Ok. That's what I was figuring. But what should one do in a not so
trivial case? I know enough forethought should go in at the beginning,
but people make mistakes while others change their minds (user
requirements). Hopefully this all happens during the dev stage, so
you're not impacting a production system, but even on a dev system, it
would be a pain in the neck to lose all that data.
Steve's DBUnit ant solution looks nice, but it might be nice for data
modeler to have an import/export dump facility.
AA> Reverse-engineering may be an overkill, as you may loose some of the
AA> model customizations (if you made any), such as flattened
relationships
AA> or non-default names.
Ahh, I hadn't considered this. I'll make sure not to do that then. My
intention with the reverse engineering was to make sure that what I did
in data modeler definitely matched against the db (i.e., that I didn't
miss a step).
-- Best regards, Kevin mailto:nirvdru..egativetwenty.net
This archive was generated by hypermail 2.0.0 : Tue Sep 07 2004 - 11:09:54 EDT