Hi John,
So here are my thoughts on data migration.
- What you want to be able to do is "patch" a database with all
the changes
since some point in time, or "roll-back" to some point in time.
- I like the idea of MigrationOperation classes. I think these
need to be
identifiable by some ordinal, sortable data--by naming convention,
static
field, etc. E.g. newsItem-2006-05-20 or newsItem-1.03.RC1-a.
Well, instead of relying on naming conventions, this would simply be
handled by the order in the list that is returned from migrateForward/
migrateBackward. People will most probably adopt such a naming
convention though.
- Rife could keep some meta data on Rife-installed/maintained
tables, maybe
as simple as table_name and last_update_id (again, the sortable data).
I was thinking about that beforehand, but I really would like to
prevent that. I don't really like to 'pollute' the database with such
information. Sadly though, it might be the only truly predictable
solution to this problem.
- Then, at runtime, the install method could look for any
MigrationOperations
greater than the last_update_id. Or, given some property for the
*desired*
version, calculate the difference and apply all the migrateForward-
s or
Calculating differences is extremely complex, certainly when
relationships, custom database features, indexes, triggers, ... come
into play. Also not all databases support jdbc meta data
introspection in full. Which makes it virtually impossible to obtain
the required information from the current structure of the database.
migrateBackward-s in order. Install would still create the table
from scratch
if no meta data for it exists.
I think we should just focus on playing migration sequences.
Here's another thought: we could also add support for calculating the
differences between two domain models. Ie. you keep the old versions
of your domain model in a class or package (just copying them to a
dedicated package might be easy). RIFE would then compare those with
the current model and figure out the migration operations on the fly
to go from one to the other. This is still complex, but doable.
- Along with all this, it would be cool to provide a utility that
does all
the diffs for all tables in the meta data.
What do you mean by that?
Okey dokey, there are my ideas. FWIW and all that. I'm just sorry
I can't
take this on right now.
As much as I would like to have this in, I personally don't have time
to take it on either :-(
Best regards,
Geert
--
Geert Bevin Uwyn bvba GTalk: [EMAIL PROTECTED]
"Use what you need" Avenue de Scailmont 34 Skype: gbevin
http://www.uwyn.com 7170 Manage, Belgium AIM: geertbevin
gbevin at uwyn dot com Tel: +32 64 84 80 03 Mobile: +32 477 302 599
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
