Re: [Zope-dev] Re: DateTime mess
On 11/30/05, Jens Vagelpohl [EMAIL PROTECTED] 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/ ___ 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 30 Nov 2005, at 08:20, Lennart Regebro wrote: On 11/30/05, Jens Vagelpohl [EMAIL PROTECTED] 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 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 ___ 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] DateTime iso8601 bad handling of dates
This has been brought up and (rather cavalierly) dismissed before. I
challenge anyone to justify the following DateTime behavior:
DateTime('2005-01-01').strftime('%Y-%m-%d')
'2004-12-31'
DateTimes are actually timestamps, and the current implementation
assumes that a date in ISO8601 format without a timezone specifier is
UTC rather than local.
It was asserted, last time this came up, that this is compliant with the
ISO8601 spec, but my own research shows this to be false. If someone
can point me to a truly authoritative source that supports the current
behavior, I would appreciate it, but that would not change the fact that
the manifested behavior is *broken*.
This is a simple two-line fix, folks. I've already done it on my
production systems.
Cheers,
Evan @ 4-am
___
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] zope.conf extensibility
This might be the third time I hit this issue, and I've always given up before. I hope this is the last time. I have some product that would greatly benefit from being able to be configured from within zope.conf. I don't want a separate configuration file. Period. Why? Apache doesn't have separate configuration files for mod_cache or mod_anything. Chris McDonough has used the %import feature on ClockServer product, but that just works because zopeschema.xml has a multisection definition for ZServer.server type. I think it would be very useful for zopeschema.xml to have a multisection for some abstract type to allow third-party product to define their own section type extending this abstract type and thus have their configuration kept inside zope.conf Consider this a proposal *wink*. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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 22:09 +0100: ... 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. This must be a funny classification scheme... But anyway: I have a completely different strategy for you: lets see whether you will like it. You do not materialize the classification scheme at all but you have only your leaves (let's call them objects). Each object has its classification as an attribute, say category. A category thus has the form topic/subtopic/subsubtopc/ You index the category with a PathIndex (I would recommend my Managable PathIndex) and use canned searches (so called topics) the recreate the classification structure via searches (if needed). If you do the last step (use topics for the complete recreation of the classification structure), then the number of objects will not decrease (what formerly was a classification folder is now a topic). But the new structure is much more flexible. You can now assign different categories (say along different dimensions) to your objects and will get different hierarchical (topical) views on your object set. 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. 30.000 is not yet very impressing. And, how large will be your classification scheme? Usually, such a scheme is *much* smaller than the classified items (if the lowest classification level had one (or very few) element, if would be superfluous). Adding it would give a few more thousand objects in addition -- you would get 31.000 (or maybe 35.000) instead of 30.000. Do not be worried about this... You should take care to use the correct folder implementation, however. As soon as a folder is likely to have more than a few dozen of objects, you should use a BTreeFolder2 rather than a normal folder. The total number of ZODB objects will go up by this choice (but you already learned that you need not to worry about this) but access is much more efficient (if the folder contains large numbers of children). -- 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] zope.conf extensibility
On 11/30/05, Sidnei da Silva [EMAIL PROTECTED] wrote: I have some product that would greatly benefit from being able to be configured from within zope.conf. I don't want a separate configuration file. Period. Tres Seaver and I implemented this during the Goldegg sprint in Fredericksburg, which we provided a location for. This should be in Zope 2.9. I don't know that there's any real documentation for this. Feel free to add some. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ 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] zope.conf extensibility
On Wed, Nov 30, 2005 at 03:55:22PM -0500, Fred Drake wrote: | On 11/30/05, Sidnei da Silva [EMAIL PROTECTED] wrote: | I have some product that would greatly benefit from being able to be | configured from within zope.conf. I don't want a separate | configuration file. Period. | | Tres Seaver and I implemented this during the Goldegg sprint in | Fredericksburg, which we provided a location for. This should be in | Zope 2.9. | | I don't know that there's any real documentation for this. Feel free | to add some. I haven't seen this being checked in at all, maybe it's in Tres laptop? -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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] zope.conf extensibility
On 11/30/05, Sidnei da Silva [EMAIL PROTECTED] wrote: I haven't seen this being checked in at all, maybe it's in Tres laptop? These were committed to the trunk before the 2.9 branch was created: r39652 | tseaver | 2005-10-26 15:10:40 -0400 (Wed, 26 Oct 2005) | 1 line Allow custom section types to play in product-config. r39635 | tseaver | 2005-10-26 12:09:59 -0400 (Wed, 26 Oct 2005) | 7 lines Added a 'product-config' section type to zope.conf, allowing arbitrary key-value mappings. Products can look for such confgiurations to set product-specific options (see the example 'product-config' section in skel/etc/zope.conf.in for sample usage). -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ 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] zope.conf extensibility
On Wed, Nov 30, 2005 at 04:27:11PM -0500, Fred Drake wrote: | On 11/30/05, Sidnei da Silva [EMAIL PROTECTED] wrote: | I haven't seen this being checked in at all, maybe it's in Tres | laptop? | | These were committed to the trunk before the 2.9 branch was created: | | | r39652 | tseaver | 2005-10-26 15:10:40 -0400 (Wed, 26 Oct 2005) | 1 line | | Allow custom section types to play in product-config. | | r39635 | tseaver | 2005-10-26 12:09:59 -0400 (Wed, 26 Oct 2005) | 7 lines | | Added a 'product-config' section type to zope.conf, allowing arbitrary | key-value mappings. | | Products can look for such confgiurations to set product-specific options | (see the example 'product-config' section in skel/etc/zope.conf.in | for sample usage). Oh, thanks! Missed that one. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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. This must be a funny classification scheme... Well, I wanted to have the discussion to be general about this thing because I can imagine that this issue has been some point of discussion before, among others, but I will be more specific to explain : - The structure will have categories within categories. (hierarchical categories) - Each category can have custom properties which can be 'inherited' by the aqcuisition feature of zope. - Within the categories you have object's. - Each object can derive his properties through acquisition, or have their own properties (or override the acquisiton properties) - Each object will have item groups, with their own properties / files / comments / etc. - Each item group will contain items, each item will have properties, but also can have properties derived through acquisition from categories and objects : so these items will all have different properties, depending in which category they exist. With this rules I was thinking about the next structure : Category (Object Manager, within other Categories) - Object (Object Manager) - Item Group (Object Manager) - Item (Simple Item) But anyway: I have a completely different strategy for you: lets see whether you will like it. You do not materialize the classification scheme at all but you have only your leaves (let's call them objects). Each object has its classification as an attribute, say category. A category thus has the form topic/subtopic/subsubtopc/ You index the category with a PathIndex (I would recommend my Managable PathIndex) and use canned searches (so called topics) the recreate the classification structure via searches (if needed). If you do the last step (use topics for the complete recreation of the classification structure), then the number of objects will not decrease (what formerly was a classification folder is now a topic). But the new structure is much more flexible. You can now assign different categories (say along different dimensions) to your objects and will get different hierarchical (topical) views on your object set. I have been thinking about this kind of structure to use for this specific project. But there is a problem that occures (too) often (in my experience) with this approach. By doing this you really are depending on the ZCatalog : If some conflict errors occure or for some reason the objects are not indexed (correctly) or not updated, some important information is not available for the user. I have experienced alot of problems with unindexed objects, or not reindexed objects due to 'random' conflict errors'. By making a complete hierarchical structure using 'Object Managers', you can always assure that data is accessible, and if the ZCatalog is not up to date, only the search results will not represent the actual structure. 30.000 is not yet very impressing. That's good to know. It's hard to say offcourse, but what is in some way a 'limit' of the number of objects, for instance, if they all have to be indexed? Indexing objects uses ALOT of CPU time for example... In which amount of objects should you reconsider your design? (Speaking of a 'general' guideline) You should take care to use the correct folder implementation, however. As soon as a folder is likely to have more than a few dozen of objects, you should use a BTreeFolder2 rather than a normal folder. I've used the BTreeFolder2 before for a single folder containing large number of objects, and indeed, it's really boosting the perfomance a lot... Well thanks again for your thoughts, it helps in breaking patterns I'm used too, let's reconsider it using some external input :) Kind regards, Martijn. -- 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 )
Re: [Zope-dev] Re: RFC: Reunite Zope 2 and Zope 3 in the source code repository
Martin Aspeli wrote: ... and I'm one of those developers. I care, for the moment, about one thing: Plone. I want Plone to move to use more Zope 3 technology, sure, because it's clearly superior. But we're not going to re-write it from scratch, and neither, I suspect, will most large Z2 applications. That I don't know about. Plone probably should, for a number of reasons, but I guess it's quite a hard problem to tackle... So my path to Z3 is through Z2, by way of Five. Frankly, without that migration path, Z3 is nice and pretty and architecturally very cool and totally irrelevant to me. Indeed, but why does that mean people in Z3-land who feel the same way as you about Z2 and Plone should have to put up with looking after all of Z2? ;) 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: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Stephan Richter wrote: On Thursday 24 November 2005 09:17, Jim Fulton wrote: Now (well, after the December release :), I think it's time to revisit what the core of Zope 3 is and how we manage the repository. There has been a trend to manage important components separately and link them in. I see this trend continuing. The advent of eggs and continuing maturation of zpkg and testing technology will accelerate this trend, IMO. I think that in the future, there may be a much smaller core Zope 3 project that represents the object filing system (zope.ofs? :). This core project may be a client of a collection of much smaller projects, such as zope.interface, zope.component. etc.. If that vision comes to pass, Zope 2 will no longer contain the Zope 3 core, but they will both share a large number of components which neither of them contain. Obviously, this would radically change the nature of this debate. I was counting on you making exactly this suggestion. :-) I agree with all of that. +lots ;-) 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 )
Re: [Zope-dev] RE: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
Philipp von Weitershausen wrote: Bottom line: I find the risk of your having to dig through horrible Zope 2 code much lower than the chance of joint efforts on Zope 3 technology. Of course, it'd be quite surprising if I didn't believe that as the author of the proposal *wink*. I agree with the points your raise but I worry about the arrival of the pragmatists and making nasty botch jobs to help out some half broken code in Zope or Plone... 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] common datetime
Alexander Limi wrote: Can I add use a common datetime implementation? ;) Philipp is already working on this :-) (and I'm keen to help out too, if there's a sane way for me to do so...) 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 )
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Gary Poster wrote: Zope 2 depends on Zope 3, via Five. Zope 3 does not depend on Zope 2. A very good point, but one which makes me feel that Zope 2 shouldn't be merged in with Zope 3 ;-) Put differently, if we're merging in Zope 2 into the repository, then why not SchoolTool, or any of the other projects that _use_ Zope 3? Zope 2 devs don't have to touch Zope 3 unless they want to leverage some cool new feature--in which case they are Zope Five devs, probably. Zope 3 devs must touch Zope 2, in this new world order, whether they want to or not, when changes break the stuff that Zope 2 has leveraged. I don't agree. Again, if Zope 3 changes break SchoolTool, is that a Zope 3 developer problem or a SchoolTool problem? FOrcing the maintenance of Zope 2 onto the already overloaded Zope 3 devs seems a little unfair... The question here is effectively whether all Zope 3 developers must become Zope 'Five' developers. As you said, Zope 2 developers can choose to proceed essentially unaffected. Zope 3 devs could not. And this for me, means that even if the repos merge, so evil svn:externals can be avoided, the tests should not be run together on the Zope 3 side, and Zope 3 should come bundled with Zope 2, even if Zope 2 comes bundled with Zope 3 and Five! 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 )
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
Lennart Regebro wrote: I think this change can possibly make sense when we have replaced Zope 2 authentication with Zope 3s, and when we have replaces Zope 2 publisher with Zope 3s and when we have replaced the Zope 2 traversal with Zope3s, and maybe a couple of other things. At that point, Zope2 will more or less be Zope3 + App, DateTime, OFS, Products and some other stuff. Then something more of a merge might make sense. This is a really really good point ;-) I think unification is probably a good idea, but not yet... Even so, I'd much prefer to see Z3 stay light of Zope 2 and just have Zope 2 become smaller and smaller as it leverages more and more of Zope 3. Put differently, I have no problem with the repositories merging, but I'd like to see the bits of Zope 3 seperately available, without Z2. I know ZPT and testbrowser already work like that, and the more that works like that the better... 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 )
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
Stephan Richter wrote: * We have been constantly trying to make the trunk smaller, and suddenly we blow it up? This does not fit. In fact, I would claim that zwiki and bugtracker should now be moved out of the trunk and placed into top-level dirs themselves. They should be tested using the buildbot. This is a very very good point... * I have a fear that people will be motivated to make Zope 3 changes to make them work better with Zope 2, inserting special code just for Zope 2. Another good point. 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: DateTime mess
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 )
