Talk:AD Migration

This Wiki is read-only for reference purposes to avoid broken links.

Thanks Paul, very good suggestion. I like the global idea although I foresee problems for some tables, i.e. non-primary key tables, or AD_Tree, etc. But taking it as a seed we can evolve the idea.
Now, I'm wondering why to create a new table for that - maybe we can simply use AD_Session and AD_ChangeLog (defining a special type of session as migration session maybe?).
Also a sequence in steps is needed.
And I guess the migrations must be uploaded/downloaded to repository as XML files, so we would need the buttons to create xml file, to upload an xml file, and to apply it.
Finally, a result message, retry options, etc, can be useful also.
CarlosRuiz_globalqss 11:22, 11 June 2009 (PDT)

Hi Carlos,

In the first place we can always fall back to executing sql for the edge cases, though I would hope we could eventually move things into the AD (for example, database view definitions.) As for composite-key tables -- I think we should do away with them. Any existing composite key tables can be supplemented with a single primary key column, while retaining the unique index on the old composite key columns. There are many things that don't work with composite keys (archive, chat, change log, web service etc.), it adds complexity to every process, and the only benefits appear to be saving an extra index column in the database, and simplified generation of records from cross-joins as you don't need to generate a key. Any way, that's a discussion for another time.

I decided not to use AD_Changelog (although I do use AD_Session) because:

• the data format didn't suit (no option for sql, multiple records for a PO update)
• Change log is used for other purposes and you want to be able to edit/manipulate migration scripts, when creating them.
• It should be relatively easy to add a process that converts a range of change log actions into a migration (if you forget to switch on log migration).

So far I've coded the following steps:

• AD changes required
• Automatically generate PO migration steps if "log migration" is enabled.
• Basic process to apply and rollback a single step.
• Process to export a migration to XML
• Process to import a migration from XML

Still to do:

• Process to run entire migration
• Process to run all migrations for a release
• Testing

Phib 18:09, 11 June 2009 (PDT)

Integrating to 2Pack?

• I am seeing this as a intra-version migration manager (to manage in between versions), and i wonder if it can be also such within the 2Pack in due time.
• So that 2Pack eventually can do both things:
  • Module v1.0 pack
  • Module v1.a upgrade

- WDYT? -- red1 06:42, 20 June 2009 (PDT)