-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ross Patterson wrote: > Tres Seaver <tsea...@palladion.com> writes: > >> Hanno Schlichting wrote: >> >>> - Plone 4 will have a documented upgrade story >>> >>> A migration from Plone 3 to 4 does not need to be possible in an >>> almost fully automated fashion. We need to ensure we have an easy to >>> follow and understandable documented upgrade story. If we for example >>> change API's or rearrange code, we can document the new places in >>> writing and with error references for the most commonly used >>> parts. If you need to change your buildout configuration, a document >>> explaining the changes is fine, we don't need to build an upgrade >>> machinery for configuration files. >> Can I persuade you and the FWT to forego an "upgrade-in-place" >> strategy for moving from P3 to P4, and instead to have a well-tested >> ad documented "dump-and-reload" story? > > I've never actually understood how a dump-and-reload approach would be > inherently more maintainable or otherwise more trouble-free. I know > this has been discussed before, but I missed those discussions. Can > anyone shortcut the research for me and give me some links or pointers > to previous discussions?
The short answer is that in-place migrations lead to ordering-dependent arrangements of crufty bits in the site: it gets particularly bad when the representation format of the data changes. If the programmer is both careful and lucky, she can often mitigate the problem with clever defaults, properties, etc., but the downside is that the BBB-driven code has to stay around *forever*. In SQL land, you can imagine altering tables to add columns, etc., with out breaking anything (assuming that sensible defaults exist). However, if the original low-level partitioning / indexing algorithm changes, etc., then dump-reload is the only sane way forward. It is pretty much standard practice to do dump-reload in enterprise-scale RDBMS applications whenever upgrading the RDBMS software itself. Dumping the content out to a "neutral" format and loading it into a "clean" site loses the crufty bits, and leaves the code in the "new" software free of nasty BBB stuff. It also gives people a migration target (for moving content into Plone, or even out of it), as well as a non-ZODB-specific backup representation of the site (e.g., to populate a staging / testing server). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJVmtM+gerLs4ltQ4RAg29AKChL3bYfEI7NbcISkA7rnfOoVJRoQCgiB92 fpUDM0LadK3U4++MvGd93Mw= =UIzF -----END PGP SIGNATURE----- _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team