[Zope-dev] Re: RFC: product initialization cleanup and improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Ouch! I thought everything is in place for that feature, but an > important piece of the puzzle is missing: The fix for checkPermission. > > http://www.zope.org/Collectors/Zope/1774 > > _verifyObjectPaste uses a hack to work around that checkPermission > issue, making 'action' required. > > Tres: You did have a look at issue #1774 a while ago. What do you think: > How much work would it be to resolve this issue? I'm not a C programmer > so I can't do it myself... I have uploaded a patch, with tests, to the collector issue: http://www.zope.org/Collectors/Zope/1774/collector_1774.patch/view I could use another pair of eyeballs on the C part of the code -- the refcount idioms in that code are pretty nasty, and I finally rewrote them using 'goto' and Py_XDECREF. The patch (against the 2.8 branch) applies cleanly to the 2.9 branch and the trunk, and all tests pass. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjR2h+gerLs4ltQ4RAuuNAJ9NW7onXtqWahhbpAGg3zsJl3dC/QCghz9c WfFBTxOeDLDyS/Gp1AN8KxY= =bz/Y -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] Re: DateTime mess
On 29 Nov 2005, at 16:46, Andreas Jung wrote: --On 29. November 2005 17:36:51 +0100 Lennart Regebro <[EMAIL PROTECTED]> 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 ___ 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 )
[Zope-dev] Re: PermissionGeddon
Florent Guillaume wrote: Ok I just fixed SecurityInfo, could you update AccessControl/ and recheck please? Florent Hi Florent. All our unit tests pass again. I'm really looking forward for having a new Zope .0 release which might be compatible with an existing Plone release ;) Great work, thanks so much! Hanno ___ 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 )
Re: [Zope-dev] Folderish or SimpleItem object types for structural content
Hello Dieter. ...For every object that can contain subobjects you could derive it from 'Folder' (or Object Manager). But when you derive all these product types from 'Folder' you end up with ALOT of objects in your database. It that a problem? It might become one once you get millions of objects... Usually, I would expect that most objects come from you leaves and not from the classification structure... That will be true, but I was wondering where to draw the line, for example with perfomance issues. All the objects will be in a ZCatalog, to allow searching for example. But one 'ObjectManager' step less in the choice what to do with the products results in much less objects in the catalog. The estimation about the amount of objects, with only the leave nodes as 'SimpleItem' objects will be 30.000. I never had so many objects in a ZODB, that's why I'm asking this, but as your answer suggests it's still the preferred way. Thanks for the comments! -- Martijn Jacobs Four Digits, internet solutions e-mail: [EMAIL PROTECTED] | web: http://www.fourdigits.nl tel: +31 (0)26 44 22 700 | fax: +31 (0)84 22 06 117 ___ 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 )
[Zope-dev] Re: PermissionGeddon
Florent Guillaume wrote at 2005-11-29 15:32 +0100: >... >I'm a bit peeved though at the lack of willingness from the few people that >have reimplemented their version of _setObject/_delObject (which could be >considered "private" APIs, seeing that they're prefixed with an underscore) All methods necessary to implement your own "ObjectManager" have the "_" at the start. There is no official API allowing to add new objects to an ObjectManager... > ... >This is supposed to be open source, can't we be reactive to change in such >situation? Why must "_setObject/_delObject" grow a new parameter "suppress_events"? Where is it used for? Up to now, the methods called "manage_afterAdd/manage_beforeDelete" indiscrimently -- without the need to suppress these calls (the predecessors of events). In the very few places where "manage_afterAdd/manage_beforeDelete" should behave specially, a specialized fake object was used. Can classes no longer control event creation (such that a parameter to "_setObject/_delObject" must be used to prevent normal (event generating behaviour). >Are folks really going to ship their framework code with >_setObject unmodified from the current version when they ship it for Five >1.2 or Zope 2.9? I am quite happy, when a single version of my "framework" works with many Zope versions. I am even happier when nothing needs to be changed for a new version (because it may take me quite a long time before I/we accept a new Zope version and support it). The following products installed here define their own "_setObject": * "LocalFS" * "PluggableAuthService" * several private products (for versioning, temporary instance creation, "multi container") -- Dieter ___ 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 )
Re: [Zope-dev] Folderish or SimpleItem object types for structural content
Martijn Jacobs wrote at 2005-11-29 01:02 +0100: > >All those products are different 'types', with different functionality >and different 'roles' as what they represent, so I write different >products for every type. For every object that can contain subobjects >you could derive it from 'Folder' (or Object Manager). But when you >derive all these product types from 'Folder' you end up with ALOT of >objects in your database. It that a problem? It might become one once you get millions of objects... Usually, I would expect that most objects come from you leaves and not from the classification structure... >In a lot of real world cases you have categories and items, that makes >things easy, but what about the structure explained above? I would use "ObjectManager"s to implement the classification structure and "SimpleItem"s for the leaves. -- Dieter ___ 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 )
Re: [Zope-dev] Re: DateTime mess
--On 29. November 2005 17:36:51 +0100 Lennart Regebro <[EMAIL PROTECTED]> 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 pgppUUYRDzhKC.pgp Description: PGP signature ___ 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 )
Re: [Zope-dev] Re: DateTime mess
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? ___ 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 )
Re: [Zope-dev] Re: DateTime mess
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*! somber-looking face.> Moderator: Amen. ___ 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 )
[Zope-dev] Re: PermissionGeddon
Dieter Maurer wrote: Hanno Schlichting wrote at 2005-11-26 09:28 +0100: ... I hope to have tracked the ~200 failing tests down to two of your changes in OFS.CopySupport. The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. This breaks the reference implementation of Archetypes because it uses something based on BTreeFolder2 to store references and BTreeFolder2 overwrites both _setObject and _delObject with its own versions. Several "Folder" like classes are likely to overwrite "_setObject" and "_delObject". Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. I checked in a backward compatibility check for this too. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 )
Re: [Zope-dev] Re: Python2.4 Security Audit ETA???
--On 29. November 2005 15:13:45 +0100 Florent Guillaume <[EMAIL PROTECTED]> wrote: The security audit already happened, and led to checkins by Jim on October 26 that preceded the release of Zope 2.8.4. Zope 2.8.4 is safe to use with python 2.4. Let's say it this way: it's safer than with Zope 2.8.3 but it is still not supported :-) -aj pgpLBMkb7XQdX.pgp Description: PGP signature ___ 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 )
[Zope-dev] Re: DateTime mess
-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 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjHgT+gerLs4ltQ4RAhV5AJ9RkELpcCehxidfHX3to+i35WKt5ACcDOyk +oqPpq0HwiU0whiwvVOIdlc= =8Ixv -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] Re: PermissionGeddon
Hi Florent Em Ter, 2005-11-29 às 15:32 +0100, Florent Guillaume escreveu: > [...] > I'm a bit peeved though at the lack of willingness from the few people that > have reimplemented their version of _setObject/_delObject (which could be > considered "private" APIs, seeing that they're prefixed with an underscore) > to just modify their code for forward compatibility and be done with it, but > instead have us embark in a year-long deprecation strategy. > > This is supposed to be open source, can't we be reactive to change in such > situation? Are folks really going to ship their framework code with > _setObject unmodified from the current version when they ship it for Five > 1.2 or Zope 2.9? They probably will change it, people don't like their code to generate deprecation warnings. But the greatest beneficiaries of the deprecation strategy are not the framework builders, but the users. Suppose a Zope change breaks, say, Plone (to pick two arbitrary examples :-). This means, that in order to upgrade to the next Zope version, I need to upgrade Plone first. If Plone, on the other hand, depends on Zope features that are only available in the newer Zope version, I'm forced to upgrade both layers of my running site simultaneously, making it much more expensive to calculate the migration overhead and procedures. I don't want to start a discussion about whose responsability is to keep compatibility with what software, but I, for one, prefer to upgrade the lower layers of my solutions before the upper layers if possible: Python before Zope, Zope before Plone, Linux kernel before glibc. This is not always possible, and there are loads of counter-examples, but if we can avoid forcing the poor user to upgrade more than one piece of software at a time, I think this is something we should try to achieve. Cheers, Leo ___ 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 )
[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1851 Blamelist: efge BUILD FAILED: failed test sincerely, -The Buildbot ___ 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 )
[Zope-dev] Re: PermissionGeddon
On 26 Nov 2005, at 09:28, Hanno Schlichting wrote:
The second change is actually related to your permission work.
First of all I have to thank you for your great work :) But I have
found one nasty thing.
CopySupport had the following security declaration:
__ac_permissions__=(('Copy or Move', (), ('Anonymous', 'Manager',)),)
...
Globals.default__class_init__(CopySource)
which changed into:
security = ClassSecurityInfo()
security.setPermissionDefault(copy_or_move, ('Anonymous', 'Manager'))
...
InitializeClass(CopySource)
Now the InitializeClass call is actually an alias for the former
Globals call, so no change here. But as you wrote yourself, you had
some trouble with the mysterious __ac_permissions format.
Looking at the actual code in App.class_init in the last paragraph
I'm quite sure that the former code did effectivly nothing so far.
The actual setattr call is inside a 'for mname in mnames:' loop
where mnames is the second element of each security tuple - in this
special case the mysterious () which results in not going through
the 'for mname in mnames:' loop at all.
Ok I just fixed SecurityInfo, could you update AccessControl/ and
recheck please?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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 )
[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1849 Blamelist: benji_york,efge,philikon,rafrombrc,tseaver,yuppie BUILD FAILED: failed test sincerely, -The Buildbot ___ 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 )
[Zope-dev] Re: PermissionGeddon
Dieter Maurer wrote: Hanno Schlichting wrote at 2005-11-26 09:28 +0100: ... I hope to have tracked the ~200 failing tests down to two of your changes in OFS.CopySupport. The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. This breaks the reference implementation of Archetypes because it uses something based on BTreeFolder2 to store references and BTreeFolder2 overwrites both _setObject and _delObject with its own versions. Several "Folder" like classes are likely to overwrite "_setObject" and "_delObject". Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. Ok, due to popular demand I'll make such a change. I'm a bit peeved though at the lack of willingness from the few people that have reimplemented their version of _setObject/_delObject (which could be considered "private" APIs, seeing that they're prefixed with an underscore) to just modify their code for forward compatibility and be done with it, but instead have us embark in a year-long deprecation strategy. This is supposed to be open source, can't we be reactive to change in such situation? Are folks really going to ship their framework code with _setObject unmodified from the current version when they ship it for Five 1.2 or Zope 2.9? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 )
Re: [Zope-dev] Re: PermissionGeddon
Hi all, Em Dom, 2005-11-27 às 21:26 +0100, Florent Guillaume escreveu: > Dieter Maurer wrote: > >>The first change is in the manage_pasteObjects method of CopyContainer. > >>There are some _setObject and _delObject calls which grew a new > >>suppress_events parameter. [...] > > > > > > Several "Folder" like classes are likely to overwrite > > "_setObject" and "_delObject". > > Maybe, the code that calls these methods with an additional parameter > > should be prepared to meet implementations that do not support > > the extra parameter. > > Maybe. But on the other hand I'd rather not have object manager code > slowed down and uglified to suit the negligibly small number of classes > that are in this case, and that can be trivialy upgraded in a > forward-compatible manner. "Not gathering crust" is a nice an laudable goal, but so is "keep backward compatibility". I humbly suggest that the workaround code on ObjectManager be created with a deprecation warning whenever it's triggered, declaring that the backward compatibility will go away in, say, version 2.11, when it won't be uglified and slowed down anymore. You are, in essence, changing the API. IMHO this should take the same deprecation treatment as everything else. Cheers, Leo. ___ 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 )
[Zope-dev] Re: Python2.4 Security Audit ETA???
The security audit already happened, and led to checkins by Jim on October 26 that preceded the release of Zope 2.8.4. Zope 2.8.4 is safe to use with python 2.4. Florent Alan Milligan wrote: Aeons ago someone promised that said Zope security audit of Python 2.4 was scheduled for October. I've not yet seen any happy announcements that Zope is now 2.4 compliant, and do want to highlight the importance of achieving this goal. Python2.4 has been out for almost a year now, and it's fairly ubiquitous. There've been many statements made on this list about people quite happily running their Zope's - contrary to white hat advice. With the major distro's, Python is entrenched in their installer and gui processes and *all* packaging is focused around a single python (2.4 for everyone excepting our BastionLinux). In reality it is infeasible to support a second version of Python for Z2. Many modules have SWIG bindings (while core Z2 doesn't require much of this, a number of products do), requiring multiple package versions - build systems cannot cope with this scenario without massive spec customisations (which is all pointless given the window of this requirement - and of course that we've all actually learnt something for python2.5, python2.6 ) We are getting an increasing number of people attempting to load incompatible packages. It is not possible to downgrade python. Most of userland is not competent to get a secondary python2.3 installation running - especially when packages such as python-ldap are simply not available for their old python and new ldap etc etc which all requires custom package builds. We are also stuck in a time-warp actually having to back-port a large proportion of recent linux packages because we'd like to make new features available, increasing costs and testing requirements. It is also no longer possible for customers to subscribe to just a single channel because our core is substantially different to their chosen vendor's installation, and packages will be installed into meaningless python paths etc. Can someone please give me an ETA on this, so I can decide if and how to support zope in light of other pressing linux requirements for our distro. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 )
Re: [Zope-dev] Re: UI improvements
Chris Withers schrieb: Tino Wildenhain wrote: Not sure which objects would fall in this category. All Objects in ZODB have their history - they just dont show it by default. Comparison is of course specific to a class. Indeed, how will this work? Historycopy is of course another thing. It works for all objects but especially folders are a bit sensible if some subobjects got renamed - thats why I dont support history copy on folders. OK. So, how's this coming? ;-) You can check the principle with my old monkey-patch proof of concept. Due to changes of the extensionclasses, it only works with 2.7. I've got working code for 2.8 here, but I dont want to maintain it as monkey patch anymore. http://www.zope.org/Members/tino/PatchHistory/view Regards Tino ___ 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 )
Re: [Zope-dev] Re: UI improvements
Tino Wildenhain wrote: Not sure which objects would fall in this category. All Objects in ZODB have their history - they just dont show it by default. Comparison is of course specific to a class. Indeed, how will this work? Historycopy is of course another thing. It works for all objects but especially folders are a bit sensible if some subobjects got renamed - thats why I dont support history copy on folders. OK. So, how's this coming? ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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 )
[Zope-dev] Re: UI improvements
Alexander Limi wrote: On Thu, 24 Nov 2005 02:06:11 -0800, Chris Withers <[EMAIL PROTECTED]> wrote: Indeed, but my comment wasn't so much about this particular change, it was about the principle of it. If 2.9 is already feature-frozen, then we're setting a dangerous precedent for allowing feature changes on it. "well, if he did it, why can't I? My changes are just as small" etc... Well, there was a statement saying that 2.9 isn't frozen yet, IIRC? Indeed, sorry, I jumped the gun on that one, but double check with Andreas in case it now _has_ been frozen... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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 )
[Zope-dev] Re: DateTime mess
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. ___ 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 )
