Hi John,
I guess I don't understand what you are proposing. How does the
list of
MigrationOperations get populated, by whom? The naming convention,
combined
with the meta-data table (maybe TABLE_VERSIONS), allows the system to
determine which ones to apply, and in what order.
This would be defined by the developer while in a MetaData class that
implements the Migration interface (which has the migrateForward/
migrateBackward methods). In these methods you create a list of of
MigrationOperations, which in their turns would typically by inner
classes (or even anonymous inner classes).
Actually, the list could be a TreeMap instead with Integer versions
as the keys and MigrationOperations as the values.
- 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.
I wasn't thinking about figuring out schema differences
automatically. When I
talk about "diffs," I meant figuring out what migrations are
necessary to get
from the current version to the desired one.
Yes, that's what I meant too, but this is extremely difficult when
basing it on the existing database schema due to information simply
not being available. Doing it on a constraints basis would be better
I think.
Also, in my mind, the install method is the trigger for all this.
If a
Indeed that is what I thought of too.
TABLE_VERSIONS record does not exist for a table, the current creation
functionality kicks in. 2nd case is that the system detects
DataMigrations
that have a higher order (by convention) than the version in the
table, and
runs those in order--an auto-upgrade. 3rd case is that some
environment
property identifies a desired version, in which case all the
DataMigrations
between the desired version and that from the table are run.
Sounds good! I still would like to find a way to do this without
having to require a mandatory database table that tracks this. As
said before, I fear that this is not possible though :-/
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.
Sounds possible, and very cool, but probably not necessary initially.
- 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?
java -cp <blah> DoDataMigrations <desired-version> [table,[table..]]
- where no tables specifies means all that have a MetaData class.
Agreed
This is fun. Is this the right list for this kind of discussion?
Thanks
again.
Hmmm, it hasn't been used much in the past, but I suppose that this
discussion is better suited in the rife-devel list. We can start
using it ;-)
Best regards,
Geert
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
