Tres Seaver wrote:
Frankly, anything which attempts to "fix pickles" in-place smells bad to me. "Dump and reload" is how the RDBMS world handles this kind of problem, and it isn't because they don't have smart folks working on them.
You're right, as nice as generations might be, they can't work around some of the architectural "flaws" of the ZODB.
I wouldn't call them "flaws"; schema changes are *hard* in RDBMS land, too.
Of course; this is what I meant to intend with the quoation marks.
And, of course, they've not been "battle tested", but who's going to battle test them until they are battle tested? Chicken... egg... :).
So, do I take it that you're suggesting the upgrade strategy should entail some sort of dump/reload?
Yes, and for a perfect example of why (not related to DateTime, just to fix-in-place in general) prosecution calls .... zope.org.
Pros: Is it true that you harbor pickles from software which pre-dates the original public release of the PTK, almost six years ago?
Witness (sobbing): Yes! Yes! it is true. They could have cleaned me out by doing a data migration into a fresh ZODB, but they thought they were clever enough to update me in place. I feel so *used*!
:) By the way, would it be possible to just dump DateTime objects to some format and reload them as datetime.datetime w/o having to operate on the whole database? Also, would the GenericSetup infrastructure help here? Maybe-I-should-read-some-docs-ly, Philipp ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.