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.
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to