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 ....
>   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?



This message was sent using IMP, the Internet Messaging Program.
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to