-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Philipp von Weitershausen wrote:
Andrew Milton wrote:
-1 for any scheme that involves diddling the ZODB to 'fix' pickles, because you just know you're going to corrupt someone's ZODB, and that's just noone's idea of fun.
There are sensible ways of upgrading the ZODB. Zope 3 has had it since 3.0 (called generations) and they've been working reasonably well for these things.
They aren't well-enough "battle tested" to make Andrew's point invalid, I think (there *are* no "large" ZODB-based Zope3 sites which have undergone generational upgrades).
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.
Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Andrew Milton wrote:
-1 for any scheme that involves diddling the ZODB to 'fix' pickles, because you just know you're going to corrupt someone's ZODB, and that's just noone's idea of fun.
There are sensible ways of upgrading the ZODB. Zope 3 has had it since 3.0 (called generations) and they've been working reasonably well for these things.
They aren't well-enough "battle tested" to make Andrew's point invalid, I think (there *are* no "large" ZODB-based Zope3 sites which have undergone generational upgrades).
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. 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?
Philipp
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Philipp von Weitershausen wrote:
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.
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*!
Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
On 29 Nov 2005, at 15:47, Tres Seaver wrote:
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*!
<sound of studio audience cheering wildly>
<Moderator turns around. Camera turns to him and zooms in on his somber-looking face.>
Moderator: Amen.
<Screen goes black>
A question that then pops up is: Do we want to force people to do a migration to upgrade between say Zope 2.9 and Zope 2.10, just to replace all the DateTime pickles? Especially since we still need to provide API-compatibility?
--On 29. November 2005 17:36:51 +0100 Lennart Regebro regebro@gmail.com wrote:
A question that then pops up is: Do we want to force people to do a migration to upgrade between say Zope 2.9 and Zope 2.10, just to replace all the DateTime pickles? Especially since we still need to provide API-compatibility?
For people it might be more comfortable to have a on-the-fly migration somehow under the hood...however this leads to ugly migration code in the sources (Zope is full of such scary code). Personally I prefer a dedicated migration step.
-aj
On 29 Nov 2005, at 16:46, Andreas Jung wrote:
--On 29. November 2005 17:36:51 +0100 Lennart Regebro regebro@gmail.com wrote:
A question that then pops up is: Do we want to force people to do a migration to upgrade between say Zope 2.9 and Zope 2.10, just to replace all the DateTime pickles? Especially since we still need to provide API-compatibility?
For people it might be more comfortable to have a on-the-fly migration somehow under the hood...however this leads to ugly migration code in the sources (Zope is full of such scary code). Personally I prefer a dedicated migration step.
+1 on a dedicated migration step. Might even be a chance for some other cleanups.
jens
On 11/30/05, Jens Vagelpohl jens@dataflake.org wrote:
+1 on a dedicated migration step. Might even be a chance for some other cleanups.
So the process would be something like:
1. Make a FrankenDateTime that uses the pickles of the DateTime, but the methods of datetime. 2. Make a zope.datetime module with the enhancements we want. 3. Immediately deprecate FrankenDateTime for zope.datetime. 4. Two versions later (2.12) remov the FrankenDateTime and make a migration step necessary for the continued use of the ZODBs.
Or?
Hmm. I guess step 1 is strictly speaking optional, but then we would have to live with the broken DateTime for some time... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On 30 Nov 2005, at 08:20, Lennart Regebro wrote:
On 11/30/05, Jens Vagelpohl jens@dataflake.org wrote:
+1 on a dedicated migration step. Might even be a chance for some other cleanups.
So the process would be something like:
- Make a FrankenDateTime that uses the pickles of the DateTime, but
the methods of datetime. 2. Make a zope.datetime module with the enhancements we want. 3. Immediately deprecate FrankenDateTime for zope.datetime. 4. Two versions later (2.12) remov the FrankenDateTime and make a migration step necessary for the continued use of the ZODBs.
Or maybe...
1) Create zope.datetime the way we want it 2) Extend DateTime to also satisfy the zope.datetime API 3) Deprecate the non-zope.datetime API in DateTime to make people use the zope.datetime API (if not the objects themselves) 4) Two versions later, migrate all remaining DateTime objects to zope.datetime
jens
Andreas Jung wrote:
For people it might be more comfortable to have a on-the-fly migration somehow under the hood...however this leads to ugly migration code in the sources (Zope is full of such scary code). Personally I prefer a dedicated migration step.
+ lotz
Chris
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.
-
Andreas Jung -
Chris Withers -
Jens Vagelpohl -
Lennart Regebro -
Philipp von Weitershausen -
Tres Seaver