Forum OpenACS Q&A: Response to Data migration

Collapse
7: Response to Data migration (response to 1)
Posted by John Sequeira on
Michael,

In your case, what advantages does the intermediary steps of XML serialization/deserialization give you?

The way I've done that before (and the way I suspect Musea has done it) is:

1) grab data from 3.x (TCL)
2) emit plpgsql or pl/sql loader script (TCL)
3) load loader script into 4.x data model (pgsql/sql*plus)

If I want to repeat the migration, or the 4.x API evolves, I change the emitter in TCL.

What you're proposing, I think, is:

1) grab data from 3.x (TCL)
1x) emit XML (TCL)
2x) parse XML (TCL)
2) emit plpgsql or pl/sql loader script (TCL)
3) load loader script into 4.x data model (pgsql/sql*plus)

Yes you've improved the prospect of working on the project in parallel by presenting a data interface, but I would argue in this simple case of 3.x->4.x data migration it won't be worth the overhead of XML. I've done this kind of thing alot, both using XML (when dictated by an XML-stored data source), and more typically the way I've described above. My hunch is that the XML pays off only when complexity grows ( a lot ), when a different team of people or people with a different toolset will do the loading, or when it's already a project requirement and the overhead is marginal.