[Zope-dev] Re: CatalogBrains.getObject and unrestricted code
In article [EMAIL PROTECTED], Florent Guillaume [EMAIL PROTECTED] wrote: In ZCatalog's brains, getObject currently does a restrictedTraverse to get the object. That's a problem for unrestricted code that needs to get to the object nevertheless, even if the user cannot get to it. For instance CMF is impacted, when it tries to reindex the security of all subobjects of a given object. Unless someone is opposed to it, I'll add a _getObject method that does an unrestrictedTraverse, and make CMF use it if available. Florent getObject must be restricted since it can be called by untrusted code. It has been argued that it is currently too restrictive, and it should only validate the leaf object, but nothing has been done about this AFAIK. You can work around this issue by using:: unrestrictedTraverse(brain.getPath()) A (restricted) convenience method to do this could be added, but it doesn't really seem worth the effort IMO. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Running Zope tests in 2.7 fails
IIRC this is caused by having a Python compiled without UCS4 support. Some pre-built pythons that come with certain Linux distros (RedHat is one I think) are built with different unicode support then the default. I would suggest building your own python from source and trying it with that instead. -Casey On Fri, 20 Aug 2004 12:12:31 +0200 Lennart Regebro [EMAIL PROTECTED] wrote: I have finally realized that the way tests are run in 2.7 is different from earlier version of Zope, and I'm trying to get them to run. It's Zope 2.7.2 on Debian. Python 2.3.4 and 2.3.2, so I guess 2.3.3 would give the same error. Could it be a side effect of the compiling or something? Here is the traceback: Running unit tests from /home/regebro/Zopes/Zope-2.7.2-0 /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/cDocumen tTemplate.so: undefined symbol: PyUnicodeUCS4_DecodeLatin1 ['/home/regebro/Zopes/Zope-2.7.2-0/lib/python', '/home/regebro/Zopes/Zope-2.7.2-0', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', '/usr/local/lib/python2.3/plat-linux2', '/usr/local/lib/python2.3/lib-tk', '/usr/local/lib/python2.3/lib-dynload', '/usr/local/lib/python2.3/site-packages'] Traceback (most recent call last): File test.py, line 841, in ? process_args() File test.py, line 831, in process_args bad = main(module_filter, test_filter, libdir) File test.py, line 629, in main files = find_tests(module_filter) File test.py, line 460, in find_tests os.path.walk(walkdir, finder.visit, rx) File /usr/local/lib/python2.3/posixpath.py, line 290, in walk walk(name, func, arg) File /usr/local/lib/python2.3/posixpath.py, line 290, in walk walk(name, func, arg) File /usr/local/lib/python2.3/posixpath.py, line 282, in walk func(arg, top, names) File test.py, line 439, in visit __import__(pkg) File /home/regebro/Zopes/Zope-2.7.2-0/lib/python/AccessControl/__init__.p y, line 16, in ? import DTML File /home/regebro/Zopes/Zope-2.7.2-0/lib/python/AccessControl/DTML.py, line 18, in ? from DocumentTemplate import DT_Util File /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/__init_ _.py, line 22, in ? from DocumentTemplate import String, File, HTML, HTMLDefault, HTMLFile File /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/Documen tTemplate.py, line 112, in ? from DT_String import String, File File /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/DT_Stri ng.py, line 17, in ? from DT_Util import ParseError, InstanceDict, TemplateDict, render_blocks, str File /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/DT_Util .py, line 42, in ? from cDocumentTemplate import InstanceDict, TemplateDict, \ ImportError: /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/cDocumen tTemplate.so: undefined symbol: PyUnicodeUCS4_DecodeLatin1 Any ideas why this is? The Zope in itself seems to work fine. I have a 2.7.0 instance to, it also fails, but with a completely different error. //Lennart ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 maillist - [EMAIL PROTECTED] 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: Referencial Integrity in ZCatalogs
You should be able to access it now anonymously. -Casey On Mon, 02 Aug 2004 17:07:30 -0300 Leonardo Rochael Almeida [EMAIL PROTECTED] wrote: Forgot to Cc: zope-dev -Mensagem encaminhada- From: Leonardo Rochael Almeida [EMAIL PROTECTED] To: Santi Camps [EMAIL PROTECTED] Subject: Re: [Zope-dev] Referencial Integrity in ZCatalogs Date: Mon, 02 Aug 2004 17:05:53 -0300 I would suggest you take a look at mxmRelations, however Zope.org workflow is keeping it out of reach, and I couldn't find it on MaxM's own site. The URL for it would be: http://www.zope.org/Members/maxm/products/mxmRelations but right now it requires a login. If any kind soul from the Zope web team could release it, or if MaxM could post it somewhere else, that would be very nice. Cheers, Leo ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 maillist - [EMAIL PROTECTED] 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: any limits on object number?
On Wed, 14 Jul 2004 13:46:57 +0530 Nagarjuna G. [EMAIL PROTECTED] wrote: We are builiding a large portal using Zope. We need to create a large number of objects. The data component of the objects is small, but each object carries lots of metadata. My question is: Is there any limit on the number of objects in a given folder? I am not planning to use any external RDBMS. Are there any known performace isssues when the numbeer of objects increase, particularly when we store them in the same folder? Normal zope folders should probably not be used to hold more than a few dozen items. They store a list of their children in a single ZODB record, and as their numbers increase so do the size of the transactions that change the folder. Also normal Zope folders do not handle concurrent updates and will thus not perform well when multiple users are adding items to the folder. Shane Hathaway's BTreeFolder2 product solves these problems. It is the thing to use when you want to store large numbers of objects in a single folder. It also handles concurrency much better. hth, -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: hasattr geddon
On Fri, 9 Jul 2004 16:22:17 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: [..] The hasattr replacement in Python's __builtin__ could look like: _marker = [] def hasattr(obj, attr): return getattr(obj, attr, _marker) is not _marker Opinions? +1 Another advantage to a global patch is that 3rd party products (such as CMF) would benefit automatically. I noticed yesterday some hasattr calls in DCWorkflow that could cause inaccurate results if the hasattr returned false due to a ConflictError. It might be worth profiling this and an alternate implementation in C to see if the latter is worthwhile. I can't imagine the C implementation would be all that complex. That would dispense with any performance disadvantage of the patch. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: AccessControl Problems on Mac OSX
It looks like this bug was closed due to lack of feedback from the
original poster. I would suggest opening a new collector issue and
reference that one if you think it is the same issue (it certainly
appears to be on the surface).
The collector issue would stand a much better chance of being acted on
if you also submit a patch with a cooresponding unittest that fails on
Mac OS X with the current implementation.
-Casey
On Thu, 8 Jul 2004 15:12:13 +1000 (EST)
Terry Kerr [EMAIL PROTECTED] wrote:
Hi,
I seem to be having problems relating to AccessControl on MacOSX. I
have a python product which I previously ran in Zope2.4.3/Python 2.1.3
and have upgraded it to run in Zope2.7.1/Python2.3.3. It runs fine on
Linux and FreeBSD, however I get this traceback with some actions
within the product on Mac OSX 10.1
Module Products.PageTemplates.Expressions, line 201, in __call__
Module Products.PageTemplates.Expressions, line 189, in _eval
Module Products.PageTemplates.Expressions, line 145, in _eval
__traceback_info__: shopper
Module Products.PageTemplates.Expressions, line 340, in
restrictedTraverse
__traceback_info__: {'path': ['name'], 'TraversalRequestNameStack':
[]}
SystemError: NULL result without error in PyObject_Call
I narrowed this down to a guarded_getattr() problem in the
AccessControl module. One thing I notice is that there is a C and a
Python implementation of the access control stuff.
If I explicitly set name='PYTHON' at the beginning of
AccessControl/Implementation.py::setImplementation(), my product works
fine, so I gather the problem is related to the C implementation.
Has anyone experienced any similar problems on MacOSX?
I notice this related issue in the zope collector, but it was
rejected? http://zope.org/Collectors/Zope/232
Should I add another issue to the collector?
terry
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 maillist - [EMAIL PROTECTED]
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: CatalogBrains since Zope2.7.1b1
On Sat, 19 Jun 2004 20:14:47 -0300 Leonardo Rochael Almeida [EMAIL PROTECTED] wrote: On Wed, 16 Jun 2004 11:16:55 +0200 Eric Brun [EMAIL PROTECTED] wrote: Hi, I have a problem with 'getObject' method of CatalogBrains class on Zope271b1 : it's return None. But with a Zope2.7.0 my object is correctly find and returned. The permissions are right. Em Qua, 2004-06-16 às 11:28, Casey Duncan escreveu: getObject was refactored recently and its security was increased. It uses restrictedTraverse() now, which means that you need access to all of the enclosing folders as well as the object. Before, no security checking was performed by getObject. I suspect you do not have access to one of the containing folders. I certainly hope he'd get a permission error instead of silent 'None' for '.getObject()' in this case or I'd consider it a bug :-) Me to, except that changing this behavior will break existing apps. There is an implicit contract the getObject should not raise errors. Perhaps this means we need a different method with better behavior. Somehow that doesn't seem all that appealing, however. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: CatalogBrains since Zope2.7.1b1
On Thu, 24 Jun 2004 19:04:55 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Casey Duncan wrote at 2004-6-18 09:58 -0400: ... Security was tightened for getObject recently as part of a general refactor of that code. I am happy to consider whether the security is too tight, in which case it could be backed off a bit. I think, you should only require access rights to the object itself and not to all folders from the root to the object. It is not uncommon that upper levels are more restricted than subhierarchies. This is what Zope's URL traversal allows: Only the object identified by URL traversal is accessed checked. That ZCatalog identifies objects by physical path is an implementation artifact. It should not make it impossible to access an object via the catalog that otherwise can be accessed without problem. ... For hysterical raisins, REQUEST.traverse() does not behave this way. It instead checks only the final object traversed. That's a good behaviour... Except when it isn't ;^) OTOH it is closer to the behavior of getObject in 2.7.0. Ironically it used to use restrictedTraverse long ago... -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: CatalogBrains since Zope2.7.1b1
On Thu, 24 Jun 2004 09:59:30 + Santi Camps [EMAIL PROTECTED] wrote: Security was tightened for getObject recently as part of a general refactor of that code. I am happy to consider whether the security is too tight, in which case it could be backed off a bit. Previously getObject performed no security checks and returned objects for catalog results regardless of security permissions (it used unrestrictedTraverse). I switched it to use restrictedTraverse which checks security all the way down on all of the containing folders and on the final object itself. This is how path expressions work, for example. I think this new security checks could be a problem in some cases. They are Ok when using restricted code, but from trusted code I'm not sure that force to use restrictedTraverse could be considered a goal. That is a good point, however since getObject is not itself a protected method, and cannot tell whether it is being called by restricted code, it must always do its own checking. For instance, imagin an application with employees of one department managing dossiers with economic data inside. Employees of accounting department shouldn't have access to these dossiers objects, but they need to obtain some reports with a sum of all dossiers economic data. So, accounting department users shouldn't have access to dossiers objects, but from reports trusted code these dossiers need to accessed. I think a possible solution could be an additional optional parameter of .getobject used from trusted code when unrestrictedTraverse want to be used. What do you think ? Optional arguments will still allow untrusted code to bypass security checks. Here are three solutions to this, two of which do not involve catalog changes: - Use a proxy role on the script that invokes getObject which grants the permissions needed. - Use self.unrestrictedTraverse(brain.getPath()) from trusted code - Add a private method: unrestrictedGetObject() to the catalog brain API which does no security checking, but is inaccessible to untrusted code. I think the last one is a good idea and I will implement it. The other two are available options for now. The problem is that if the existing getObject offers a mode to do no checking, it is conceivable for untrusted code to arrange for an object to be cataloged whos path actually points to an otherwise inaccessible object (granted a more likely senario is that the object is already cataloged). It could then find that catalog result, call getObject() and then pass it to the publisher to render it. This would allows a scripter to publish any object in Zope, because it effectively gives them a way to call unrestrictedTraverse. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: zope-dev list policies
On Fri, 25 Jun 2004 10:06:21 +0200 Godefroid Chapelle [EMAIL PROTECTED] wrote: [..] I am administring plone-i18n mailing list. Non members cannot post. I always post through gmane and my messages get accepted ! As long as posting from Gmane still works, then I'm fine with restricting postings to members. If we decide to go ahead I suggest restricting just one list first to see if there are issues. IMO zope-dev is a reasonable candidate for a trial list. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: CatalogBrains since Zope2.7.1b1
On Fri, 25 Jun 2004 20:26:30 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Casey Duncan wrote at 2004-6-25 09:36 -0400: On Thu, 24 Jun 2004 19:04:55 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: ... I think, you should only require access rights to the object itself and not to all folders from the root to the object. ... That ZCatalog identifies objects by physical path is an implementation artifact. It should not make it impossible to access an object via the catalog that otherwise can be accessed without problem. ... For hysterical raisins, REQUEST.traverse() does not behave this way. It instead checks only the final object traversed. That's a good behaviour... Except when it isn't ;^) OTOH it is closer to the behavior of getObject in 2.7.0. Ironically it used to use restrictedTraverse long ago... Have you gotten the main argument? Yes, I intend to change it to use unrestrictedTraverse and then validate the returned object. So there... 8^P -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: zope-dev list policies
-1 on changing the list policy. I read and post to all of the public lists through Gmane, which won't work if the policy is changed. I rarely see spam get through list either (unless Gmane is filtering it all out for me), so I fail to see the problem from that point of view. -Casey On Wed, 16 Jun 2004 21:24:07 -0400 Tim Peters [EMAIL PROTECTED] wrote: Over on the zope and zope-dev lists, there's currently agitation to make them members-only mailing lists. The point is that spam could not get thru then (unless posted by a member). What would zodb-dev members like? Posting by a list member would not be affected, unless you attempted to send a message from an email account other than one you subscribed with. In the latter case, your message would be bounced back to you. You could worm around that by subscribing to zodb-dev with that address too, then going to your list membership page on the web and checking the box to suspend email delivery on that account. Then you could post using that account too, but wouldn't also get zodb-dev email on that account. I'm the list admin for zodb-dev, and don't have a preference. If you do, and it's strong enough to scream it, shout. The loudest screamer will winwink. By default, I won't change the current policy (anyone can post here, member or not). ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Prohibiting Spams on the List
On Tue, 15 Jun 2004 20:41:16 -0400 Tim Peters [EMAIL PROTECTED] wrote: [Mohsen Moeeni] Fristly excuse me for cross-posting. Actually, I did not like to be the person who comes this up however the amount of spams which is propagated thru the lists is annoying. I wonder why the guys at Zope Inc. does not tweak the list settings so posting is only allowed by the members. Perhaps just the weight of history, and/or trying to keep the barriers to participation as low as possible. Speaking as zodb-dev's list admin, I'd be happy to restrict posting to members, *if* people don't object to the idea. I spend an increasingly resented part of each day doing list-admin triage(for zodb-dev and about 6 other mailing lists). A predictable irritation is that Mailman's answer to member? is based on the posting's sender's email address, but many people post from more than one account. If you want the default action for non-member posts to behold for review, I won't do it -- I can't afford the additional time sink.reject is the no-manual-intervention default action, but it would place a new burden on members posting from non-member accounts (their posts would be rejected, at least until they asked the list admin to add their other posting accounts to Mailman's list of non-members to accept -- and they would need to do that on a per-list basis). Another issue is posting from Gmane, which I am doing right now. Although that may look like a post from me to mailman, I dunno. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: CatalogBrains since Zope2.7.1b1
getObject was refactored recently and its security was increased. It uses restrictedTraverse() now, which means that you need access to all of the enclosing folders as well as the object. Before, no security checking was performed by getObject. I suspect you do not have access to one of the containing folders. -Casey On Wed, 16 Jun 2004 11:16:55 +0200 Eric Brun [EMAIL PROTECTED] wrote: Hi, I have a problem with 'getObject' method of CatalogBrains class on Zope271b1 : it's return None. But with a Zope2.7.0 my object is correctly find and returned. The permissions are right. is there any bug here ? Thanks Eric Brun Ingénieur de développement [EMAIL PROTECTED] Pentila Bâtiment Euclide 73370 Le Bourget du Lac Savoie Technolac http://www.pentila.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 maillist - [EMAIL PROTECTED] 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: Bad idiom to access optional attributes
On Mon, 7 Jun 2004 07:46:41 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: [..] Meanwhile, the best way to access optional attributes seems to be if getattr(aq_base(obj), attrname, notFound) is not notFound: attr = getattr(obj, attrname) ... Ahhh, the miracle of acqfuscation... -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: {Spam?} Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
On Mon, 24 May 2004 17:25:19 +0300 Steve Alexander [EMAIL PROTECTED] wrote: Of course, Steve suggested: ob:adaptername context:dc/title This really doesn't make sense. To me it reads In the namespace of context get the title of dublin core. I'm not reading : as having anything to do with namespaces. Rather, I see '/' as the traverse operator, and : as the adapt operator. Understood, that's just how it reads to me. Adapters are in a sense like mini-namespaces, enough so that I think it is confusing to reuse the XML namespace token here. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope Bug Day - Friday 28th May?
On Fri, 21 May 2004 19:57:08 +0100 Chris Withers [EMAIL PROTECTED] wrote: Hi People, I offered to schedule and organise the Zope bug days for the last Friday of each month, and the first one of those is looming. Do people have any objections to Friday 28th May as a bug day? If I hear nothing, I'll begin more widely advertising next week... +1, count me in. How does this coincide with the 2.7.1 schedule? -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope Bug Day - Friday 28th May?
On Fri, 21 May 2004 21:27:02 +0200 Andreas Jung [EMAIL PROTECTED] wrote: --On Freitag, 21. Mai 2004 15:19 Uhr -0400 Casey Duncan [EMAIL PROTECTED] wrote: On Fri, 21 May 2004 19:57:08 +0100 Chris Withers [EMAIL PROTECTED] wrote: Hi People, I offered to schedule and organise the Zope bug days for the last Friday of each month, and the first one of those is looming. Do people have any objections to Friday 28th May as a bug day? If I hear nothing, I'll begin more widely advertising next week... +1, count me in. How does this coincide with the 2.7.1 schedule? I am planning to release beta1 next Monday. Sounds pretty much perfect to me. That leaves 3-4 days for beta bugs to get submitted before bug day. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [ZODB-Dev] Re: BTrees strangeness (was Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)
On Mon, 17 May 2004 19:00:16 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Chris McDonough wrote at 2004-5-15 13:04 -0400: ... Dieter, do you think you can read this patch and give a thumbs up or down on it? The patch looks good. On a different subject, the publisher probably shouldn't pass around traceback objects (e.g. when it calls into err_hook) as Tres believes that may be a memory leak waiting to happen. The traceback is vital for error analysis. It may not be necessary that ZPublisher touches the traceback but we will definitely need access to it during error handling. Perhaps the traceback can be passed as a string to avoid leaks? Furthermore why can't the traceback be retrieved later from sys.exc_info()? -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Dis-allow anonymous bug posting?
On Mon, 10 May 2004 13:21:26 +0100 Chris Withers [EMAIL PROTECTED] wrote: Casey Duncan wrote: No, some very valuable bugs are submitted anonymously. People can be very paranoid (rightly) about their privacy. We do want to encourage bug submissions even if that means more noise. So on the one hand we say we rarely care about anonymous bug posts and on the other close anonymous bug posts as soon as we can. I didn't say that. To me a bug is a bug. The only difference is that anonymous postings can't really be replied to for more info, so vague anonymous bug reports will likely be closed quicker because of this. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Dis-allow anonymous bug posting?
On Fri, 07 May 2004 09:56:45 +0100 Chris Withers [EMAIL PROTECTED] wrote: Tim Peters wrote: While that *should* be a good example, it isn't: I only knew that bug existed because someone closed it on Bug Day (and I'm subscribed to the Collectors, and read the email they generate). *bangs head against desk* Some bugs are so vaguely described nobody could guess -- and when they're anonymous too, there's no effective way to get more info. Those ought to be closed. Indeed. How about removing the ability for people to post bugs withotu specifying n email address? And, if they do specify an email address, using that to contact them by sending notification mails to it? No, some very valuable bugs are submitted anonymously. People can be very paranoid (rightly) about their privacy. We do want to encourage bug submissions even if that means more noise. AFAIK the collector does mail the poster on state change if they have an email address. For all I know, this happens already, but people don't perceive it as happening so the ythink anonymous bug postings will never be heard from and so close them straight away as anonymous, therefor we don't care Nope, many times we do care. But when we don't we will close them. To be clear: big -1 on restricting anonymous posting -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Bug day report
On Thu, 6 May 2004 10:45:03 -0400 Tim Peters [EMAIL PROTECTED] wrote: [..] On the Python bug tracker, I don't close vague bug reports instantly. Instead I add a note, saying that unless more information is added, the bug will be closed a month later. It's rare that more info gets added then, so they usually do get closed -- but it's more graceful when the OP does add more info. I intend to do this as well in the future. I assumed that bug reports posted years ago with no followup had little or no chance of ever being clarified now. I will try to tread a little lighter on the Reject button and add a comment requesting clarification regardless of age. If I don't hear any for a month or so, then the bug will be closed. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Collector] Strange reject policy
On Thu, 06 May 2004 12:09:18 -0300 Leonardo Rochael Almeida [EMAIL PROTECTED] wrote: On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote: From: Ken Manheimer [EMAIL PROTECTED] All the actions are verbs, won't fix is not a verb. Can you suggest a verb the more clearly indicates the result is won't fix? Tough one... Live with Ignore Keep this bug as is Zenify Featurize (as in This is not a bug, it's a feature) Shove under carpet Forget Procrastinate Pretend to be deaf How about: Dis Blow-off Lose Getouttahere Or perhaps a passive-aggressive bent: Agree Yup IDontDisagree HowNice Or my personal favorite: Interesting -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Collector] Strange reject policy
In retrospect I probably should have just marked it as deferred rather than rejected, the idea was more to provoke action (which I did) then to reject it as not-a-bug. -Casey On Fri, 30 Apr 2004 17:54:58 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: I got a reject message for http://collector.zope.org/Zope/444; with the comment: ZClasses are not being actively maintained, so unless you provide a patch, it is not likely to be fixed. I see this as a strange reject policy. In my view, bug reports in the collector should only be rejected when they are not bugs or when they can not longer occur. We want that people with strange effects look into the collector to find out whether this is a known problem, don't we? Rejected bug reports are much more difficult to find than open ones. In this case, the issue reports a true bug which pose a potential security risk because a permission mapping unexpectedly has no effect. I do not argue that this bug needs a fix but the report should at least be easily found. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Collector] Strange reject policy
On Fri, 30 Apr 2004 13:46:26 -0400 Chris McDonough [EMAIL PROTECTED] wrote: On Fri, 2004-04-30 at 13:43, Casey Duncan wrote: In retrospect I probably should have just marked it as deferred rather than rejected, the idea was more to provoke action (which I did) then to reject it as not-a-bug. I think there needs to be another category named wontfix that doesn't imply that it will ever be fixed like deferred seems to. This category should also be selected in the default search settings. +1 I volunteer Chris to implement it ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Bug day report
On Fri, 30 Apr 2004 20:14:30 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Casey Duncan wrote at 2004-4-29 22:19 -0400: I'm happy to report a successful bug day with a final tally of almost 40 issues closed. The specific issues we squashed were: #28,#181,#321,#340,#349,#439,#444,#495,#511,#532,#540,#543, #544,#545,#546,#553,#562,#574,#584,#602,#637,#644,#654,#658,#666, #678,#724,#800,#810,#811,#875,#1003,#1042,#1050,#1148,#1227,#1298, #1300. However, you closed (at least one) bug reports without resolving the the issue. I do not think this is good practice... Bug reports should remain open until they are either fixed or can no longer occur. They should not be closed just because you do not plan to fix them in the near future... If a bug will not be fixed, judged by:: - The bug description - The time it has remain open without action - The lack of a patch provided for the bug - The lack of assignment or interest of a sponsor This means it is an unsponsored bug. It should not remain open forever. The bug collector is not a substitute for documentation and issues that will never be resolved should be closed. Otherwise it wastes the time of volunteer bug-fixers. I think the current collector is a bit flawed in the available statuses. There is no specific way to denote an issue as won't fix which means that it is possibly a bug, but either it is not fixable, is not deemed worth fixing, cannot be fixed with the information provided, or nobobdy has fixed it for years so it's not gonna happen. I chose to reject the bug hoping that it would cause a reaction, which it did. I'll admit that reject is not exactly the right status, however the right status is not currently an option for the collector. Since I can see you feel strongly about this issue, please feel welcome to reopen to bug or change it to a status that better suits it. At this point I see no chance of it being fixed without a champion, however. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Bug day!
Just a reminder that bug day is on today. Meet us over on the #zope-dev channel of irc.zope.org if you can! -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Bug day report
I'm happy to report a successful bug day with a final tally of almost 40 issues closed. The specific issues we squashed were: #28,#181,#321,#340,#349,#439,#444,#495,#511,#532,#540,#543, #544,#545,#546,#553,#562,#574,#584,#602,#637,#644,#654,#658,#666, #678,#724,#800,#810,#811,#875,#1003,#1042,#1050,#1148,#1227,#1298, #1300. Thanks to all who participated! -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 Bug Day Next Thursday (April 29)
I proposed this yesterday, but I wanted to make sure that everyone say it. I think we should have a bug day, we're long overdue. I'm proposing we hold it on Thursday, April 29. We'll convene on the #zope-dev irc channel. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: The bleak Future of Zope?
On Wed, 21 Apr 2004 20:36:29 +0200 Andreas Jung [EMAIL PROTECTED] wrote: --On Mittwoch, 21. April 2004 10:41 Uhr -0400 Casey Duncan [EMAIL PROTECTED] wrote: On a bright note, I think zopewiki.org could change that. It *greatly* lowers the bar on contributing substantive docs for Zope. I would implore all of you (as in you, the reader of this message, yes you!) to go there and write something, now! You know something that has not been written down yet, so go write it down! You can even do so anonymously. Yeah...just had a look a zopewiki.org it seems to be a great place. I wonder why we were not able to built a such place there were it would belong to: zope.org? I see no reason why it being or not being on Zope.org is relevant. Its a social thing: Simon decided to do something and had the software, bandwidth and hardware to do it. People have gravitated to it and it looks like it has momentum. I see no downside, Darwin has spoken... ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Patch for CMFActionIcons: make edit work if icon expr is empty
On Tue, 20 Apr 2004 13:03:32 +0200 Joachim Bauch [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, as it's possible to create an action icon with an empty icon expression, but this action icon can never be edited again (a KeyError is raised), I propose the attached patch against ActionIconsTool.py After applying this patch, you can edit the empty action icons. Post this to the CMF collector so that the patch doesn't just wither away in the mailing list archives: http://zope.org/Collectors/CMF -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: I want to fix App.Management.Tabs.manage_workspace
On Mon, 19 Apr 2004 10:16:08 +0100 Chris Withers [EMAIL PROTECTED] wrote: Hi there, App.Management.Tabs.manage_workspace sucks as I've described in http://zope.org/Collectors/Zope/1286: 1. manage_workspace is only protected by the Authenticated role, and that is done directly, not even through a permission. I think that is probably because this method is an abstraction for the default managment screen. It does not know what the correct permission is, but assumes you at least must be logged in to see any management screen. What are you suggesting to do about this? 2. self.filtered_manage_roles then limits the options of what can be shown, which might end up being nothing. But, because the method is only protected by 'Authenticated', no chance is given to specify other user credentials (say, from a user folder higher up in the tree) which might be able to see something. Can you give a concrete use case for what you describe? 3. There's a bare try/except which masks errors. From what I can see, it should ONLY catch IndexError's. Yep, bare excepts == bad. Kill it. 4. The raise TypeError could do with some explanation. Ok. 5. The Unauthorized could raise a more helpful message You are not authorized to view an of this object's management itnerface -0, I think it may be better to say nothing which discloses less information to would-be attackers. Perhaps VerboseSecurity might be able to elaborate, I dunno. What do people feel about the right way to solve this? 3,4 and 5 I'm comfortable with fixing, but I'm stumped as to what the right thing is to do on 1 and 2 which combine to create a thorny problem. The semantics I want are: Show the 1st management tab the user is allowed to see, if they're not allowed to see anything, check if a user of the same name further up the userfolder tree can see anything Why? Is this consistent with behavior elsewhere? Are you concerned that lower user folders could lock out global managers by creating non-privileged users with the same name locally? I say YAGNI unless this behavior is somehow inconsistent. Is that right? If so, how do I go about implementing it? Finally, what branches should I do this on? 2.7 and the HEAD are likely suspects for bug fixes. I doubt there will be another 2.6 release. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: RFC: A proposal for ZODB schema migration in Zope 3
On Sat, 17 Apr 2004 08:14:35 -0400 Jim Fulton [EMAIL PROTECTED] wrote: I've posted a proposal: http://dev.zope.org/Zope3/DatabaseGenerations for a framework for managing the migration of application/database schemas in ZODB databases in an orderly manner. The proposal is to apply this new framework in Zope 3, however, if it works well, it would be applicable to Zope 2 and other ZODB applications. Comments are welcome. +1 It might be nice if some of this mechanism was distributed in ZODB itself, or at least the ZODB docs pointed to the implementation as an example of how it could be done. This is definitely a problem not limited to Zope. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope + Ape + Subversion (was: RE: Using a truely revis ion based storage for Zope ?)
On Thu, 15 Apr 2004 20:40:09 -0400 (EDT) Shane Hathaway [EMAIL PROTECTED] wrote: On Wed, 14 Apr 2004, Kapil Thangavelu wrote: although i wonder if there is some hand waving in progress here that i can't see. i guess my semantic notion of versions has been that of long lived transactions, and is there a better means of thinking of them? how do they play across with multiple mounted zodbs? what would something like merge mean in the context of a catalog? By my understanding, outside the storage, different versions are completely independent. You could even simulate multiple databases using versions. It is the storage that knows how to create new versions, merge versions, and prevent objects being used in a version from being changed. Mounted databases try to use the same version as the root connection. To merge a catalog, you could bring one of the stored catalogs to life within the storage and replay the sequence of transactions that occurred in the other catalog. This could be tricky, and opening a catalog within a ZEO server would make the ZEO server less stable. Ok, running the catalog on the storage server. Now that's crazy talk ;^) running-awayly y'rs, -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope + Ape + Subversion (was: RE: Using a truely revis ion based storage for Zope ?)
On Wed, 14 Apr 2004 06:59:05 -0400 Kapil Thangavelu [EMAIL PROTECTED] wrote: On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote: On Tue, 13 Apr 2004, Kapil Thangavelu wrote: since objects modified in a version are in essence locked from participating in other transactions, actions like modifying content in a version in a cmf site amounts to locking the catalog from changes outside of the version, which amounts to shutting down write activities to a cmf site. This is only true of FileStorage. Some other storage could implement ZODB versions with merging capability rather than locking. good point, just because hasn't been doesn't mean it can't ;-) although i wonder if there is some hand waving in progress here that i can't see. i guess my semantic notion of versions has been that of long lived transactions, and is there a better means of thinking of them? how do they play across with multiple mounted zodbs? what would something like merge mean in the context of a catalog? Catalogs are actually fairly easy to handle, at least in theory. The state of the catalog directly depends (and is derived from) the current state of the cataloged objects. So merging the catalog should mean: merge the content first and then reindex it. From this pov, it would be possible to get cataloging right in the current version machinery as well. This machinery would need to allow objects to override the locking behavior in some way. In the case of the catalog it would be fine for a current catalog and the one in the version to ignore each other (i.e., changing the one in the version does not lock the current one). Then when the version is saved/merged, the affected objects are recataloged. In practical terms this would mean that the versioned catalog would need to keep track of the uids that had been cataloged, uncataloged and reindexed in the version. The merge would mean cataloging, uncataloging and reindexing those same uids in the current catalog. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope + Ape + Subversion (was: RE: Using a truely revis ion based storage for Zope ?)
On Wed, 14 Apr 2004 09:50:17 -0400 Casey Duncan [EMAIL PROTECTED] wrote: [..] In practical terms this would mean that the versioned catalog would need to keep track of the uids that had been cataloged, uncataloged and reindexed in the version. The merge would mean cataloging, uncataloging and reindexing those same uids in the current catalog. A complicating factor to this though is that it would need to be done *after* all of the other content merges. That implies some sort of dependancy graph, *bleah*. I've never been terribly fond of the idea of catalogs as top-level instance space objects (i.e., peers to the content they catalog), and things like this are one of the reasons why. In any case it might be good enough for an object to be able to say merge me last. Other toolsy and servicey sorts of objects that depend on content (like a workflow state repository) might want to do so as well. As long as the state of the tools doesn't depend on each other, then it's ok. That last sentence is making me a little ill, however ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope and zope
+1 this is a problem. The question is whether curing it is *more* of a problem. -Casey On Wed, 14 Apr 2004 09:00:26 -0400 Jim Fulton [EMAIL PROTECTED] wrote: Jim Fulton wrote: Zope 2 has a package named Zope. Zope 3 has a package named zope. Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both Zope and zope packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows). A typical Zope installation will probably add at least two directories to the Python path, for: - The Zope software - Instance (site) specific packages So adding two directories, rather than one for the Zope software isn't a big deal. Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? I should have been clearer. The first question is: Is it a problem to have two packages with names differing only in case? I haven't gotten as many responses on this as I expected. I'll try to summarize so far: - Chris feels strongly that this is a problem - I've been swayed by Chris' response from neutral to thinking that this is a problem. - Tres seems not to think this is a problem, but I'm not sure. - Fred doesn't seem to think this is a problem. - I can't tell from Robert's and Stephans responses whether they think this is a problem or not. Perhaps we can get more input on whether there's a problem. A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: circular referenced persistent objects
On Sat, 10 Apr 2004 14:11:56 -0500 [EMAIL PROTECTED] wrote: I have the following setup (unrelated lines are omitted): class Deliverer(Folder): def manage_afterAdd(self, item, container): if item is self: self.__ac_local_roles__ = dr_localroles(self) class dr_localroles(Persistent): def __init__(self, dr): self.dr = dr dr_localroles implements a few methods of the dictionary interface, so I can always check the effective settings via the Security/local roles zmi page. In order to computing roles, dr_localroles requires its parent object instance (Deliverer), that's why I store a reference to it as an attribute. Question: - Is there a way for dr_localroles to refer its parent without holding a reference to it or using weak reference? Yes, use acquisition. Make dr_localroles inherit from Acquisition.Implicit or Acquisition.Explicit. - Is there an equivalent of sys.getrefcount for ZODB persistent objects? Cycles like this will not be a problem for ZODB. When either object is deleted it will no longer be reachable from the root, regardless of cycles between them. When the database is packed, unreachable objects are removed. Also a note for the archives: I wanted to make sure that if I delete a Deliverer object, it will indeed be removed from ZODB. Once you pack, yes. For this I got the oid of the object, deleted it and than tried to get it back via the oid. The trick is, that you'll only get a POSKeyError if you pack the database and flush the cache. This latter one was not obvious for me. Such tricks are not necessary and cause your app to rely too much on the curent implementation of ZODB. Just let the database take care of this for you. In any case, there is a (new) persistent weakref class in ZODB 3.3 which allows you to weakly refer to other persistent objects without causing them to stay in the database like normal references do. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: circular referenced persistent objects
On Mon, 12 Apr 2004 10:57:43 -0500 [EMAIL PROTECTED] wrote: Casey, Thanks for the clarification. - Is there an equivalent of sys.getrefcount for ZODB persistent objects? This is still a question. Is there any way, to determine how many times a zodb persistent object is referenced? sys.getrefcount seems to tell me only those references which are currently loaded in the memory. Also another very interesting question is that who referring to a specific object. Not from a given object. You would need to walk the forward references (which are tracked) of all the objects to find this out. I posted some code to do this from any starting object in the ZODB a long time ago. Search the mail archives if you're interested. For this I got the oid of the object, deleted it and than tried to get it back via the oid. The trick is, that you'll only get a POSKeyError if you pack the database and flush the cache. This latter one was not obvious for me. Such tricks are not necessary and cause your app to rely too much on the curent implementation of ZODB. Just let the database take care of this for you. I used this trick only for exploring ZODB behavior. The application doesn't do any nasty tricks. ok. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Unique ID generation with ZODB.
On 05 Apr 2004 14:18:25 +0200 Syver Enstad [EMAIL PROTECTED] wrote: How does one implement a unique id generator in ZODB. The id's should be strictyl ascending and be a an int. Would opening a temporary connection increment a persistent counter and commit do the trick? Why does it need to be ascending? If you remove that requirement it makes it nearly trivial to implement. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Proposal: Sanitize HelpSys API Reference, was Re: Reasons for the current API reference docs implementation?
On Sun, 4 Apr 2004 17:50:13 -0400 Paul Winkler [EMAIL PROTECTED] wrote: I've posted my proposal: http://dev.zope.org/Wikis/DevSite/Proposals/SanitizeHelpSysAndAPIReference I am 100% for this proposal and I have been thinking on and off about the same thing for years. I agree that we need to create interfaces everywhere. With that I propose the following to prevent future help skew: - That all interfaces in the system be verified in unittests. - We eliminate the duplicate interfaces currently used by the help system (Some of these are actually fairly up-to-date, so we should look at them first). - If we create examples that they be runnable doctests, which are executed by test.py The latter may mean we need a better integration test framework, I don't know. I think we'd need to try out a few and see. I can certainly help here. IMO this is a task ripe for a divide and conquer strategy. Maybe we should have a Help Day to kick this off? -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Proposal: Sanitize HelpSys API Reference, was Re: Reasons for the current API reference docs implementation?
On Mon, 5 Apr 2004 11:00:59 -0400 Paul Winkler [EMAIL PROTECTED] wrote: On Mon, Apr 05, 2004 at 09:44:30AM -0400, Casey Duncan wrote: On Sun, 4 Apr 2004 17:50:13 -0400 Paul Winkler [EMAIL PROTECTED] wrote: I've posted my proposal: http://dev.zope.org/Wikis/DevSite/Proposals/SanitizeHelpSysAndAPIReference I am 100% for this proposal and I have been thinking on and off about the same thing for years. I agree that we need to create interfaces everywhere. With that I propose the following to prevent future help skew: - That all interfaces in the system be verified in unittests. Pardon my ignorance, but what tests can you write for an interface? You can verify that a class or object implements an interface using the Verify module of the Interface package. It give you at least some protection against interface changes. It doesn't protect against all skew (the object can implement a superset of the interface and still verify), but it at least performs a sanity check. Whenever I write tests, the first one is generally an interface check. It might be nice to think about ways to make this check more rigorous. For example, methods protected by permissions or marked public should *always* be part of an interface. We could write a check to make sure that the interfaces implemented by an object cover all of the published API of that object. The deep inheritance in Zope2 might make that tricky, but it's food for thought. A *very nice* side-affect of all this will be that we will have interface coverage throughout Zope2 (and at least minimal test coverage to check the interface). This will obviously help integrating with Zope3 down the line. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [ZODB-Dev] Re: BTrees strangeness (was Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)
On Wed, 10 Mar 2004 17:50:41 -0500 Chris McDonough [EMAIL PROTECTED] wrote: Nevermind. http://zope.org/Collectors/Zope/789 and http://zope.org/Collectors/Zope/786 The bug neglector is really living up to its name lately (not pointing fingers, mea culpa). 'Bout time fer a bug day I reckon... ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Folderish object's __call__ fails
On Thu, 4 Mar 2004 13:03:20 -0800 (PST) Dirksen [EMAIL PROTECTED] wrote: Hi, I'm developing a product, which extends ObjectManager. Meanwhile, I'd like it to behave like a script object, similar to DTML method. So I define a __call__ method. But it never gets run if called from the browser. If I change the base class to SimpleItem, it works. How can I make __call__ works for folderish object? Try adding a class attribute index_html and set it to None. This is what the CMF does to get __call__ invoked. It's what we affectionately call a dead chicken, a sacrafice to the Zope gods... hth, -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: server for new protocol?
On Mon, 1 Mar 2004 10:09:36 -0500 Fred Drake [EMAIL PROTECTED] wrote: On Sunday 29 February 2004 11:21 pm, Nikolay Kim wrote: P.S. i'm developing smtp server for zope and already have working code. Ooh! This is really cool. Will this be open source? I'll be a lot of people will be interested in this. Me too, me too! ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Usability tweaks
On Mon, 01 Mar 2004 20:25:54 + Christian Theune [EMAIL PROTECTED] wrote: Hi, as I'm tweaking stuff here and there right now, I stumbled over the findSupport dtml that has a multiple select menu with a height of 4. It's almost impossible to find what you look for easily. Increasing the height to 8 would be good. Anything against that? Sounds great to me. Christian PS: Anything against simply doing those small changes? I say go ahead. Just make sure you write liberal check-in comments and test in various browsers (even stupid stuff breaks on *some* browsers). Also update CHANGES.txt so people can tell what they're getting into when they install the new release. I think enough of us monitor the checkins to catch anything wacky pretty early. At least that's my opinion... -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope 2.7 and objects turning into None
On Fri, 20 Feb 2004 22:18:33 +0100 Dieter Maurer [EMAIL PROTECTED] wrote: Casey Duncan wrote at 2004-2-20 10:53 -0500: ... This is a guess, but perhaps the Catalog is masking some other low-level error and returning None instead? I'll see if that seems possible from the code. Some time ago, I found out that OFS.Traversable.Traversable.unrestrictedTraverse catched ConflictError and returned default if a default has been specified. I filed a bug report but I am not sure whether this was fixed (it is fixed in our Zope version, of course). I think so, I was just checking this code the other day working on similar ConflictError swallowing happening in the Catalog. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope 2.7 and objects turning into None
On Fri, 20 Feb 2004 09:47:47 +1100 Richard Jones [EMAIL PROTECTED] wrote: On Friday 20 February 2004 05:52, Dieter Maurer wrote: We have a report for Zope 2.7 about an object magically turning into None (1 or 2 weeks ago). Sorry, I haven't been following this thread, but I will note that I've seen (repeatably) in my test Zope environment this behaviour. This is probably unrelated though... For me, the situation comes about when I am loading up my fresh (ie. clean ZODB) test Zope with a thousand users. While the load script is running (it runs on the command-line and goes TTW using urllib to register the users) if I access a page which summarises all users, I *sometimes* get None for some of the users. The page uses a Catalog to find basic user info, and sometimes uses getObject() to find the real user object. The getObject() appears to return None sometimes. This is a guess, but perhaps the Catalog is masking some other low-level error and returning None instead? I'll see if that seems possible from the code. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Image ranges
On Thu, 19 Feb 2004 14:55:08 +0100 Florent Guillaume [EMAIL PROTECTED] wrote: Is there a reason why OFS.Image.Image does not __implement__ HTTPRangeInterface like OFS.Image.File does ? As far as I can see there's no reason it shouldn't, as their index_html method (and HEAD inherited from webdav.Resource) are the same. No reason comes to mind. Are there any tests for range support? -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Strange loop with ZCatalog
I already replied to this, but I never heard back from you. What does the following return for a value: len(list(context.TheCatalog.searchResults(Type='TypeTest'))) ?? -Casey On Fri, 13 Feb 2004 13:01:35 +0100 Pascal Samuzeau [EMAIL PROTECTED] wrote: Hi, For some tests I have done : - Create about 5000 folders under the Root Zope Site - Inside those folders, I have created about 30 000 objects ( as document, just an id, title and a Type). - I've catalogued all inside a catalog named TheCatalog I have written just this function, in intend to test my CPU ( that why I've written it like this): allobject = context.TheCatalog.searchResults(Type='TypeTest') l=len(allobject) i = 0 #for i in range(len(allobject)): for object in allobject: #path = allobject[i].getPath() #course = allobject[i][0] path = allobject.getPath() course = allobject[0] thepath = string.split(path,'/') lepath = string.join(thepath[:-1],'/') lieu=context.restrictedTraverse(lepath) lieu.manage_delObjects(course) i+=1 return Len: %s and Number parsed: %s %(i,l) Phase A: I have 30 000 objects and the message following: Len: 3 and Number parsed: 15001 In my catalog: 15000 object only were destroyed. !!! Phase B: I de-comment my comment lines, but I've got the same message. I try to understand what it happens, but I can't. Anyone has a brillant idea? Sincerily PS -- Oreka ! Nous sommes l'internet moins cher ! Surfez 25% moins cher avec http://www.oreka.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 maillist - [EMAIL PROTECTED] 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] Strange loop with ZCatalog
On Fri, 13 Feb 2004 16:14:05 +0100 Pascal Samuzeau [EMAIL PROTECTED] wrote: Hi, I already replied to this, but I never heard back from you. I haven't seen your answer before, I'll search for it. That's ok. I think there are inconsistencies in the loop code. In my message I explained what didn't make sense to me. What does the following return for a value: len(list(context.TheCatalog.searchResults(Type='TypeTest'))) Just for now 62418. len (context.TheCatalog.searchResults(Type='TypeTest')) returns 62418 too. Good, so that means that len() of the result set isn't lying. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Strange loop with ZCatalog
On Fri, 13 Feb 2004 19:10:07 +0100 Pascal Samuzeau [EMAIL PROTECTED] wrote: Hi Casey, Yes it doesn't lie at all, but i've tried till I suppress all and even with 2 it suppressed only one. Can you tell me more about your message, I haven't found it. Bud, Google is your friend: http://aspn.activestate.com/ASPN/Mail/Message/zope-List/1993758 -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] How to make Zope fail nicely under high load?
On Wed, 11 Feb 2004 20:25:14 +0800 Bjorn Stabell [EMAIL PROTECTED] wrote: Toby wrote: [...] Zope's ZServer manages a queue of requests that have been recieved over http, but not dispatched to the publisher. This is handled in PubCore/ZRendezvous.py. I suspect this queue will be holding your backlog. You might get some benefit from capping the length of that queue. Thanks Toby. It doesn't seem like that queue (the requests list) has a cap at all. Have been stresstesting Zope for a few minutes and the queue is up to 300+ requests in the backlog queue. Not sure how to force a 503 return from within ZRendezvous.handle(), though; that's ZServer medusa magic. 300 requests at 1 request per 2 seconds yields a backlog of work of 10 minutes. This is before we've started optimizing. What kinds of requests are these? Do they all require a dynamic output? If not, then you should put better caching in front of Zope, or at a minimum tweak you caching headers so that some could be served as 304s for instance. If they are all dynamic, how dynamic? How different is the page for one session than another? If much of the page is the same then you might benefit from an ESI approach where you cache parts of pages and assemble them in the cache, serving only small pieces from Zope. I'm a bit surprised that you have not (from what I can see), used the most common Zope speedup (and often the cheapest overall): Buy more hardware and use ZEO. I wonder if Zope also processes requests that have been closed from the client end? I know Zope will continue processing a request even if it times out at least (so you can do long-running requests, like packing, through the web). Many (all?) of these 300 requests would have been closed by the time Zope got to process them, and so Zope shouldn't bother with them. Why would they be closed by the client? -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Adapters in Zope 2
On Mon, 09 Feb 2004 21:48:29 +0100 Santi Camps [EMAIL PROTECTED] wrote: Hi all, I know that adaptors are introduced in zope3 but, anybody knows if this technique can be used in zope2 ? Adapters are a general pattern. Zope 3 has infrastructure (component architecture and ZCML) that automates registering and using them, but the general pattern can certainly be applied to Zope 2 without it. Just create a class which defines the methods you want, and accepts a folder in its constructor. When you want to use the adapter, instantiate the class around the folder. I've been trying to add some extra functionallity to a Folder object without inheriting, but I'm not able to make it work. To maintain the adapted object publishable I've rewrited __getattr__, but then some extra problems appears. __getattr__ hooks are notoriously tricky to get right, especially for Zope due to acquisition and especially for folders. Anybody knows if there is a way to use adapters in zope2 ? Or, if not, there is some other way to add functionallity on-the-fly, without inheriting ? Zope2 folders are designed for this. They are really just blank objects where you can specify your own methods in instance space. Traditionally in Zope2, there are two ways to do this: by adding method objects (External Methods, DTML methods, python scripts, ZPT) directly to the folder. Or by adding these objects above the folders and aquiring them which is a type of environmental inheritance. In the CMF this is codified in the skins tool which contains global methods which can be applied to basically any object in the site. hth, -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Adapters in Zope 2
On Tue, 10 Feb 2004 15:26:00 +0100 Michael Haubenwallner [EMAIL PROTECTED] wrote: Casey Duncan wrote: Zope2 folders are designed for this. They are really just blank objects where you can specify your own methods in instance space. Traditionally in Zope2, there are two ways to do this: by adding method objects (External Methods, DTML methods, python scripts, ZPT) directly to the folder. Or by adding these objects above the folders and aquiring them which is a type of environmental inheritance. In the CMF this is codified in the skins tool which contains global methods which can be applied to basically any object in the site. Great explanation - would you give me a hint on the CMF part ? Which global methods do you speak of ? The CMF has a Tool infrastructure. Tools are persistent objects typically at the top of the CMF site. Tools provide methods and configuration for use by all objects in the site via acquisition. For example, the membership tool (portal_membership), provides methods to access member information and member folders. The portal_skins tool is special in that it actually contains framework and application defined method objects (scripts, templates, etc) organized into layers and configured into skins (which are lists of layers to use). The CMF Site object is a special Skinnable folder which allows methods available in the current skin (as described in the skins tool) to be acquired through it. This makes all of the method objects in the skin's layers globally available to all objects in the CMF site. This solves several problems, one of which is a tendancy of top-heavy hierarchies in zope where lots of objects are in the root because they need to be global. The skin and layer mechanisms allow different sets of methods to be available depending on the application, products installed, site policy and user preferences. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Adapters in Zope 2
On Tue, 10 Feb 2004 17:34:39 +0100 Santi Camps [EMAIL PROTECTED] wrote: [..] Very interesting. That's what I was looking for. I will try to extract this mechanism from CMF. See: http://www.plope.com/Members/chrism/standalone_skins 8^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: FW: [Zope-dev] strange behavior of VirtualHostMonster
On Wed, 4 Feb 2004 22:50:27 -0600 [EMAIL PROTECTED] wrote: Okay, I debugged a bit more: [u'loginUser', u'usermgrFolder', '/', 'VHM'] = this looks weird to me It seems it's pretty okay, however the last line in VirtualHostMonster.__bobo_traverse__ says: return parents.pop() # He'll get put back on Of course, the popped item is 'a', that's the one with the beforetraversal hook, so if it's really put back on later, than the hook will run again. I think this is the explanation, but the question remains: how can I avoid the second call to the beforetraverse hook? I also ran into this problem recently with an extension I wrote to CookieCrumber (which has a before traverse hook). It had the unfortunate affect of working on my local machine (where I was not virtual hosted) but not on the production box (which did). Luckily I had a test Zope instance on the production box. The obvious lessons: you can't test too much, when you're sure it works test it some more and always test in the *exact* environment as production (in other words the actual production boxen). The way CC handles this issue is to set a flag on the REQUEST on the first run and check for the flag on subsequent runs. Not elegant to be sure, but workable. It seems like at the very least this should be a documented feature of VHM, if not a subtle bug. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Call for testing (2.6.4 / 2.7.0)
On Wed, 28 Jan 2004 13:36:31 +0100 yuppie [EMAIL PROTECTED] wrote: Hi! Brian Lloyd wrote: In the meantime, it would be helpful for anyone who runs from the 2.6 or 2.7 branches in CVS to update and let us know if you have any unresolved problems. Right now I have no time to track this down myself, but the attached CMF test failures seem to be related to the last Zope changes. Don't know if these tests need to be updated or if they reveal a bug in Zope. These tests seem pretty naive. I don't thing user objects promise to compare to one another in any way. Looks to me like the tests should be changed to something like: self.failUnless(f.getOwner() is ownership) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] ZConfig: Keytype and section type extension
On Mon, 29 Dec 2003 15:48:03 -0500 Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: Phillip J. Eby writes: [snip] (The issue here is that Python requires keyword arguments to be strings rather than Unicode, even though attribute names can be Unicode. ZConfig sets attributes using unicode because ZConfig schemas are XML, and therefore Unicode.) Annoying, isn't it? Not sure it's worth fixing in Python. I guess this just furthers my theory that all sufficiently advanced bugs and mis-features are indiscernible from unicode. Or, more succinctly: Blame Unicode ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] bizarre slicing behaviour in Zope
On Wed, 17 Dec 2003 15:30:50 -0500
Gerry Kirk [EMAIL PROTECTED] wrote:
try this in a script in zope 2.7b3 (maybe others, too) if you want to go
crazy:
dd = ('dd', 'diocese', 'Parish.2003-12-16.8636751973', 'bob',
'Workspace.2003-12-17.8140751750','gerry.2003-12-17.8140751750')
return dd[4:]
you should get the last two items from the tuple, but I get the last
item returned as a string
if i loop through the slice, it's ok. it seems to be a publishing problem.
Gerry
Look at the title of the browser window to see the other item of the tuple.
Welcome to 2-tuple publication ;^)
-Casey
___
Zope-Dev maillist - [EMAIL PROTECTED]
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: On with the show....
On Mon, 15 Dec 2003 10:02:58 -0600
Evan Simpson [EMAIL PROTECTED] wrote:
Sidnei da Silva wrote:
If you look at FSPageTemplate, its obvious that it doesn't subclass
ZopePageTemplate, but the solution is not so obvious. Using:
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd
have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your
code works out to the same thing. I don't endorse this sort of
cross-tree method copying, but if we're going to do it on this scale, at
least we can make it tidier. Before the Globals.InitializeClass:
zpd = ZopePageTemplate.__dict__
for m in ('func_code', '_default_bindings', 'manage_FTPget',
'get_size', 'PrincipiaSearchSource', 'document_src',
'pt_getContext', 'ZScriptHTML_tryParams'):
setattr(FSPageTemplate, m, zpd[m])
A similar error also happened with FSImage.__str__ (which is assigned
Image.__str__, but FSImage just subclasses FSObject).
Any thought on those?
Yep -- it seems very silly to copy a one-line method like that.
Smells like a broken class hierarchy to me. I really think we need to consider
refactoring the code so this sort of sillyness isn't necessary.
-Casey
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] virtual hosting variables [was: Re: Zope 2.7.0 b3 regressions]
On Wed, 03 Dec 2003 20:43:23 +0100
Yuppie [EMAIL PROTECTED] wrote:
[snip]
So I think it would be great if VHM would add a variable like
'REQUESTED_URL' (should have a better name) that isn't further modified
on traversal.
'http://example.org/test/path/to/object'
+1
I actually had a case recently where using traverse_subpath in a python script screwed
up CookieCrumbler (which uses REQUEST.URL to determine where it should redirect).
Basically it ate the end of the URL value so the login form redirected to the wrong
place.
The evil hack fix was actually a REQUEST.set('URL', ...), in the python script before
any unauthorized errors could be raised. Perhaps it should be called ACTUAL_URL or
ORIGINAL_URL. This would be the thing that CookieCrumber would redirect to...
-Casey
___
Zope-Dev maillist - [EMAIL PROTECTED]
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: New-style ExtensionClasses (Zope 2.8) -- MRO issue
On Mon, 24 Nov 2003 14:06:07 -0500 Jeremy Hylton [EMAIL PROTECTED] wrote: [snip] Then programmers will be able to understand the code :-). Very interesting conclusion... I might argue that it would be a premature optimization however ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] __before_publishing_traverse__problem
On Fri, 21 Nov 2003 17:33:43 +0100 lukasz [EMAIL PROTECTED] wrote: I have a problem.When I import my plone site from one server to other I got : AttributeError: __before_publishing_traverse__ What should I do with that? Post it to the *Plone* mailing list? -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 2.7 b3 problem with reindexing catalog
On Wed, 19 Nov 2003 17:15:13 +0100 robert [EMAIL PROTECTED] wrote: If I try to reindex a (plone) portal_catalog I get the following error Traceback (innermost last): * Module ZPublisher.Publish, line 100, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Products.ZCatalog.ZCatalog, line 474, in manage_reindexIndex * Module Products.ZCatalog.ZCatalog, line 459, in reindexIndex TypeError: catalog_object() got an unexpected keyword argument 'update_metadata' Display traceback as text What version of Zope? I think you need to use 2.6.2+ which has this argument. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Structured text img html tag not working properly in Zope 2.61
On Wed, 12 Nov 2003 20:43:51 +0100 Max M [EMAIL PROTECTED] wrote: I have a site with lots of structured text. There are many img src='/some/image' tags in the texts. But after upgrading from Zope 2.51 to Zope 2.61, I get broken images all over the place. Example:: img src='images/kreativ.jpg' align='left' This tag is turned into:: img src=%3Ccodeimages/kreativ.jpg align='left'gt; While:: img src=images/kreativ.jpg align=left I think this is because single quotes are used to designate inline preformatted code sections. This causes unintended markup to occur inside image tags containing single quotes. Maybe you can just mass replace the single quotes with double quotes. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Structured text img html tag not working properly
On Wed, 12 Nov 2003 21:52:55 +0100 Max M [EMAIL PROTECTED] wrote: Ay, that sucks. Customers have been using it for 2-3 years now. And they have many many documents. I could write a converter, for converting it into the new image tag, but that would suck too. You could maybe try installing the old structured text package in the new Zope. It might be worth a shot. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 2.7 beta 3
On Mon, 10 Nov 2003 10:27:10 +0100 robert [EMAIL PROTECTED] wrote: Hi there, there was talk about a 2.7 b3. I would like to test it out. We are going do deploy a new server by end of this month and I would like to have it running 2.7 (reckless I know, but that is how I am) Obi-wan would say, So was I, if you remember. I personally prefer the term leading edge over reckless ;^). As for beta 3, Brian Lloyd, our fearless release meister became the father of a new child over the weekend. He had originally promised to do the beta 3 release this week, but I'm not sure whether that will go forward or not at this point. I'm sure he will respond in email when he becomes available (sometime in 2008 ;^). -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] KeywordIndex performance / multiunion
On Fri, 07 Nov 2003 12:02:07 + Seb Bacon [EMAIL PROTECTED] wrote: Casey Duncan wrote: On Thu, 06 Nov 2003 19:11:55 + Seb Bacon [EMAIL PROTECTED] wrote: A simple query for [A or B or C] against a KeywordIndex containing 27k objects is taking about 7 seconds on a Celeron 1.6Ghz, which seems an absurdly long time to me. guess This time may be caused by fetching from the database. If so, then the only way to speed it up is increase the ZODB cache or get faster disks. Try the former and see if it helps. /guess Yup, absolutely right. Upping the cache speeds it up to something sane. However, I don't understand why. The code does something like: set1 = self.index.get(1) set2 = self.index.get(2) sets = [set1, set2] ...so the sets will have come from the ZODB. But the bit which takes the time is the following line: These are TreeSets most likely. The actual members of the sets are stored in separate persistent objects. This is done so that large sets can be fetched in chunks rather than all at once. The ZODB tries to be lazy with fetching objects. If an object is very large it often makes sense to split it up between many persistent objects so that each part can be loaded and unloaded separately. This is what BTrees and TreeSets do. When you fetch a value from a BTree or test for an element in a set it only needs to load the part (in this case a Bucket) that contains the element, rather than the whole enchilada which could be huge (in reality its not quite that simple, but that's the general idea). This is why BTrees and TreeSets are used when you need to store and manipulate arbitarily large numbers of elements. result = multiunion(sets) This iterates the sets which loads all the buckets from the database if they are not in the cache. At which point the sets have already been fetched, no? looking forward to the day I understand ZODB caches...;-) Actually this is not so much a function of the cache but a function of the organization of the set objects themselves. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] CookieCrumbler and WebDAV
On Thu, 06 Nov 2003 14:38:03 +0100 Lennart Regebro [EMAIL PROTECTED] wrote: CookieCrumbler doesn't seem to allow cookie authenticifation over WebDAV. It stops authentication if the request is not PUT, GET or POST and also it stops anything over the webdav source port. Anybody knows WHY? CookieCrumbler is expressly designed for interactive login with a human through a web browser. It steps out of the way for WebDAV because it is not appropriate to subvert the normal HTTP authentication mechanism in that case. WebDAV clients cannot display the HTML login form that CookieCrumber returns. Actually in some cases (like MS Office) they can display the form and they mistakenly think that is the document the user requested 8^( I took this code for my Cookie Identification plugin for PLuggableUserFolder, so it does the same, but we now have a client whos WebDAV client seems to try to use cookies, adn that fails of course. It might be reasonable not to bail so early, however. Maybe it would be better to bail only if there wasn't a proper authentication cookie already. Instead it should try to use it to authenticate. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] KeywordIndex performance / multiunion
On Thu, 06 Nov 2003 19:11:55 + Seb Bacon [EMAIL PROTECTED] wrote: A simple query for [A or B or C] against a KeywordIndex containing 27k objects is taking about 7 seconds on a Celeron 1.6Ghz, which seems an absurdly long time to me. guess This time may be caused by fetching from the database. If so, then the only way to speed it up is increase the ZODB cache or get faster disks. Try the former and see if it helps. /guess The bit of the operation that is taking the time is the part of the index which does a union of the results of each of the 3 query parameters. Reproducing this BTree union operation outside Zope in a unit test takes milliseconds. Very occasionally it takes milliseconds inside the KeywordIndex too. Something to do with memory usage perhaps? I'll continue looking into it. Are you saying that sometimes it's faster? If so, that probably supports my guess above. In those times it's all or mostly in memory. But main the reason I'm posting is to wonder if there any reason not to use the multiunion operator instead of the union operator in UnIndex.py... it should be faster, right? It seems a touch faster in some informal tests. Yes, it probably should be used. I think it is much faster when unioning very small and very large sets as well. Tim would know better, tho. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] _p_deactivate() and _v_ variables?
Seb Bacon wrote: Chris Withers wrote: Casey Duncan wrote: I would argue that a better plan would be to only use _v_ vars for completely disposable data only. The application should expect that this values will be gone at any random time, not just at transaction boundaries. Agreed. Are there any situations, apart from the already discussed CMF skindata, where this currently isn't the case? I'm a bit puzzled - of what use is a variable which may disappear at any random time? It's not exactly random. It would happen when the object was deactivated (removed from cache). If the object is marked as changed (ala _p_changed=1) then its __getstate__ will be called before it is deactivated. If it hasn't changed though then it doesn't really get a chance to do anything about it. Deactivation only happens AFAIK at transaction or subtransaction boundaries. This gives at least some predictability, since subtransactions are rarely used. Perhaps this is why database adapters have been historically incompatible with subtransactions? It seems to me that DAs are a bit broken with regard to where they store their database connection objects. They should register an object with the transaction that holds the connection so that it can be properly committed or aborted regardless of what happens with _v_ variables in the interim. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] _p_deactivate() and _v_ variables?
Toby Dickenson wrote: On Wednesday 15 October 2003 14:53, Casey Duncan wrote: Agreed. Are there any situations, apart from the already discussed CMF skindata, where this currently isn't the case? I'm a bit puzzled - of what use is a variable which may disappear at any random time? It's not exactly random. It would happen when the object was deactivated (removed from cache). The proposal earlier in the thread was aiming towards allowing objects to get deactivated at any time if the cache was overfull, not just at transaction boundaries. This is desirable from a cache management point of view. Apart from the most trivial cases, it would allow _v_ attributes to disappear at random. Its a similar problem to the one that makes it hard to write an optimiser for python code, and I am unconvinced that this is sane. I agree. If objects disappeared from cache randomly, I think the system as a whole would not be stable or predictable. I also think it would tend to make a loaded server even more loaded by thrashing the cache unnecessarily. As it is, the hard cache implementation, although beneficial from a memory management perspective cause loaded servers to do alot more work because they are constantly pruning the cache and then reloading objects again immediately thereafter. It might be worth considering a more gradual cache mgmt policy which has a target size, a maximum size and a prune rate. Currently, we have only a maximum size. Then again, since Python never really returns memory to the OS, I'm not sure it matters much in the end. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] _p_deactivate() and _v_ variables?
Toby Dickenson wrote: On Thursday 09 October 2003 14:01, Florent Guillaume wrote: I agree with this. How do we go about find code that uses the assumption that _v_ stuff won't change unless it's at a transaction boundary? Note that we had a problem related to this with a client recently: In CMF, skin data is stored in portal._v_skindata, and is actually needed for the whole request, but in some ZEO setting this go cleared by a get_transaction().commit(1) which was unexpected and led to breakage because in that batch treatment we used some skin methods too... Something after the subtransaction commit must be tickling the cache garbage collector. Thats generally what subtransactions are used for. A while ago there was a discussion on zodb-dev about _v_-like attributes that would be automatically cleared at the end of a transaction. Do we need something similar that guarantees it will _not_ be cleared until the end of the transaction? IMO YAGNI. I think the application should tolerate the disappearance of _v_ vars. I would consider the problem with CMF skins a bug that needs to be fixed. AFAIK there is nothing stored in _v_skindata that cannot be reconstructed from data in the skins tool. Has an issue been filed in the CMF collector regarding this? -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: catalogObject changes (Zope-2_6-branch)
This is broken in 2.6.2 and I would consider it a bug in that release. I would support an improved api such as: catalog_object(obj, idxs=[], metadata=1) The way it is currently breaks at least one of my applications as well (ironically, this was an application the Chris was also working on). I am happy to make the change if we agree it is the right thing. -Casey On Tuesday 07 October 2003 07:13 am, Yuppie wrote: Hi! Chris McDonough wrote: Option 1: Add an update_metadata flag to the catalogObject method with a default of True on all branches. Option 2: Do nothing, but add the updateMetadata method to the ZCatalog interface. Option 1 would only take effect when 2.6.3 was released (if ever) and 2.7 final would have the new flag. Because since the behavior change has already been released in 2.6.2, it might be better to do option 2 and fix the places in CMF/SilvaMetadata that specify indexes, leaving it the way it is. I agree backwards compatibilty is broken anyway. Whatever the solution is, products using the idxs argument for metadata changes have to be changed to work with 2.6.2. Regarding migration, I agree option 2 would be better. Regarding the interface, I still prefer option 1 or even option 1 *and* 2. The fact that zcat.catalog_object(obj) does update metadata while zcat.catalog_object(obj, idxs=zcat.indexes()) doesn't, isn't intuitive at all. At least this difference has to be mentioned in the interface definition. Just my 2 cents. I can live with both options. Cheers, Yuppie ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 maillist - [EMAIL PROTECTED] 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: catalogObject changes (Zope-2_6-branch)
On Tuesday 07 October 2003 10:41 am, Yuppie wrote: Hi! Casey Duncan wrote: This is broken in 2.6.2 and I would consider it a bug in that release. I would support an improved api such as: catalog_object(obj, idxs=[], metadata=1) I'm sure you mean catalog_object(obj, uid, idxs=[], metadata=1) if we are talking about the ZCatalog interface. No I figured while we were at it, we'd break compatibilty for a completely different reason ;^) Seriously, I meant what you said... -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: catalogObject changes (Zope-2_6-branch)
On Tuesday 07 October 2003 12:08 pm, Chris McDonough wrote: On Tue, 2003-10-07 at 09:52, Casey Duncan wrote: This is broken in 2.6.2 and I would consider it a bug in that release. I would support an improved api such as: catalog_object(obj, idxs=[], metadata=1) The way it is currently breaks at least one of my applications as well (ironically, this was an application the Chris was also working on). FWIW, those changes have been in there for two months on the 2.6 branch. This includes 2.6.2b3, b4, b5, and b6. The breakage couldn't have been *that* bad. ;-) I guess that means I should start using releases ;^) Nah -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] _p_deactivate() and _v_ variables?
On Friday 26 September 2003 04:37 am, Toby Dickenson wrote: On Friday 26 September 2003 09:32, Chris Withers wrote: Toby Dickenson wrote: On Thursday 25 September 2003 11:51, Chris Withers wrote: Hmmm, does _p_deactivate() clear the contents of the object's _v_ variables? Yes Then given your earlier comment that _v_ variables are supposed to last at least teh length of the request, John's idea of using _p_deactivate() to reduce memory usage for large ZCatalog results sets could be seen as playing with fire, right? He had code that would only deactivate objects at the end of a loop if they were not active at the start of the loop. Its not entirely safe, but I think it mitigates the most serious risks here. ZCatalog (and others) have used this same technique for a while. It should be entirely safe so long as the application does not store non-redundant data in _v_ variables. If the application does do this, then it needs to register the object as changed in the transaction and override __getstate__ so that the value of the _v_ variables are stored. I would argue that a better plan would be to only use _v_ vars for completely disposable data only. The application should expect that this values will be gone at any random time, not just at transaction boundaries. _p_deactivate is only effective if the object is in the up-to-date state. So if by some chance the object was changed after being loaded from the catalog results set, _p_deactivate() would do no harm. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] PCGI-Problem
On Friday 19 September 2003 04:31 am, Andre Schubert wrote: On Thu, 18 Sep 2003 14:32:52 +0200 Andre Schubert [EMAIL PROTECTED] wrote: Hi all, i have a little problem. We have several Zope's running in our company. Versions are 2.5.1,2.6.1,2.6.2. All are running on Redhat Linux. All versions have the same problem, if i access them via pcgi and hit the Restart button in the Control Panel then the server goes down. If i do the same via ZServer port 8080 everything works fine. Hi all, i think i have found a solution. A patch is included for PCGIServer.py. Could anybody check this patch please. If there are no problems i could file a bug into the collector. I would recommend putting it into the collector so that it does not get lost. Please ignore the muted sound of laughter in the background... ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Functional testing of export/import?
You can usually commit a subtransaction to get a _p_jar and oid (I think) set.
You can still abort this at the end of the test to clean up.
hth,
-Casey
On Monday 28 July 2003 12:39 pm, Paul Winkler wrote:
I'm trying to write a functional test that verifies that an instance
of my Product works correctly after it's been exported and re-imported.
I'm stuck on how to give the test object a valid _p_oid which is needed
to do the export.
Background:
This Product is a dynamic content object for CMF. Its behavior depends on
another CMF type instances, which it keeps a path to. So I need to ensure
that things work even when one or both objects have moved. I've got
moving renaming handled well and now I want to test import/export.
So my test suite sets up a dummy CMF instance. I do this by swiping
stuff from the CMFCore and CMFDefault tests; I subclass SecurityRequestTest
and then do
manage_addCMFSite(self.root, 'cmf_test_site' )
self.site = self.root.cmf_test_site
I've also got a portal folder in the site which I keep a handy
reference to as self.fol1.
All tests are passing, now I move on to writing the export / import tests.
Let's say the object I want to export is self.cmf_test_site.fol1.cp1.
I have a shorthand reference to this stored as self.cp1.
So I think the first thing I need to do is get the export data
like this:
data self.fol1.manage_exportObject('cp1', download=1)
... and once that works, I'll use the same data to do an import.
But the export fails. Using pdb and browsing some source I've learned
that cp1 needs a _p_jar and _p_oid in order to be exported.
The _p_jar I've already dealt with in my move / rename tests, by swiping
a hack from CMFCore/tests/test_portalFolder.py:
id = self.cp1.getId()
# W! must get _p_jar set
old, self.cp1._p_jar = self.cp1._p_jar, self.root._p_jar
try:
data = self.fol1.manage_exportObject(id, download=1)
finally:
self.cp1._p_jar = old
That seems to work fine.
But now I'm stuck on _p_oid. How do I give the object a valid one?
I'm sure I can't just use the same trick and swipe the _p_oid of the app
root :-P
I must say that using pyunit to write functional tests for zope 2 / CMF
is a royal pain. It requires too much knowledge of implementation.
(why should i need to worry about _p_foo???)
Also I've found that if there's an error in your class' setUp(),
it can cause the test to hang and never show you a traceback.
--
Paul Winkler
http://www.slinkp.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 maillist - [EMAIL PROTECTED]
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] ZCatalog Indexes tab crawls...
On Friday 18 July 2003 01:29 pm, Dieter Maurer wrote: Anthony Baxter wrote at 2003-7-18 15:14 +1000: Andreas Jung wrote I agree but the current implementation sux. Switching to a counter based solution would solve the problem. The only problem I see is to keep the code fully backward compatible. if there's no counter present: create one, do a count of the docs, initialise the counter We can use the size of the _unindex. However, is it really worth it? #objects suggests that it is the number of objects indexed by this index. Who is interested in this information? Unless one has inhomogeous objects, almost all objects are indexed by every index. Thus, #objects is likely to be similar for many indexes. A much more interesting information would be the size of the index measured by the number of index terms. I agree. and as a plus, its a minor change to the software... -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] ZCatalog Indexes tab crawls...
Actually I regard the current behavior as a feature. Using a stopwatch and a slide-rule I can estimate to within 100 objects, how many values are indexed in a catalog by measuring the time it takes to draw the indexes page. Please do not remove this most valued feature! -Casey On Thursday 17 July 2003 04:35 pm, Dieter Maurer wrote: Chris Withers wrote at 2003-7-17 11:12 +0100: Has anyone noticed that the ZCatalog Indexes tab crawls if you have loads of objects indexed. My guess is that some types of index take way too long to figure out how many objects are indexed. Anyone know which index types those could be? The one that provide the correct number of indexed objects (rather than just the number of indexed terms). Because the same object can be indexed under several terms, determining the number of indexed objects requires to build the union of all the index values. This almost surely has quadratic (worst case) runtime characteristics. BTW, would anyone object if I removed that object count, since it's not often very useful... You probably should replace it with the size of the index (i.e. the number of index terms). Formerly, the index overview displayed this information but under a buggy # objects title. Someone fixed this for most indexes, they now show the number of objects but at a high price. I suggest to change the title to # index terms and revert for the indexes to the old behaviour. Others pointed out, that also the size determination for an index may be expensive. However, it is at most linear in the number (rather than quadratic) and all recently created indexes now use BTrees.Length to maintain their size (which gives constant time). Having a feeling how large an index is is valuable information. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 maillist - [EMAIL PROTECTED] 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] 2.6.2b3?
Post this to zodb-dev. -Casey On Monday 23 June 2003 05:12 am, seb bacon wrote: Just a quick repeat from last week in case it slipped from anyone's radar... Here is the important bit again: a) Any reason why I shouldn't merge BTree bugfixees into the 2.6 branch? b) If no, how about a 2.6.2b3? seb On Wed, 2003-06-18 at 17:25, seb bacon wrote: There lave been various BTree fixes lounging in the HEAD since Jan 2003 which I'd like to get into a release, basically because we have seen one of the bugs causing segfaults in production - this is the culprit: http://cvs.zope.org/Zope/lib/python/BTrees/BTreeItemsTemplate.c.diff?r1=1.17r2=1.18 a) Any reason why I shouldn't merge it into the 2.6 branch? b) Any chance of a 2.6.2b3? Seb ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] weak examples, weak exploits
I would be in favor of making the Examples opt-in like the Zope tutorial. It seems silly to have it in evey ZODB by default. Make people add it if they want it. -Casey On Monday 23 June 2003 05:12 am, Jamie Heilman wrote: seb bacon wrote: No. Just go ahead and make the changes. It would be instructive for others reading the examples to add a comment or two explaining the rationale behind the extra checking code. 'k I can do that The file upload vulnerability was fixed in version 1.3 of Examples.zexp, though. The reason it's still turning up in 2.6.x versions is probably due to upgrades. Therefore I suppose additionally there should be a patch which examines the ZODB on startup and prints a warning if an old Examples folder is present. You know, ironically, I don't think this advisory even covers that hole. There's obvious DoS potential in the guest book and such, but thats easily limited without degrading the value of the example. Anyway, I'll scrape over the examples and see what I can clean up. -- Jamie Heilman http://audible.transient.net/~jamie/ Most people wouldn't know music if it came up and bit them on the ass. -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 maillist - [EMAIL PROTECTED] 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] Memory Error
On Tuesday 17 June 2003 11:47 am, Andy McKay wrote: If you've visited ZopeZen you might have noticed this lovely error that seems to occur intermittently.. [snip rest of traceback] * Module Products.CMFCore.CatalogTool, line 214, in searchResults * Module Products.ZCatalog.ZCatalog, line 619, in searchResults * Module Products.ZCatalog.Catalog, line 732, in searchResults * Module Products.ZCatalog.Catalog, line 480, in search * Module Products.PluginIndexes.common.UnIndex, line 365, in _apply_index * Module ZODB.Connection, line 534, in setstate MemoryError: (Also, an error occurred while attempting to render the standard error message.) Its: Zope 2.6.1 (source release, python 2.1, linux2) python 2.1.3 openbsd3 I believe all the appropiate python stack patches are applied. In my experience, (at least on FreeBSD) it would simply fall over when it ran out of stack space, I don't remember ever seeing MemoryError. But I may not have been paying close enough attention ;^) Looks like its running out of memory when a BTree subobject is being loaded. Do you have any idea how much memory the process was using when you got the error? -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Zope-Coders] Bug day?
I assume you meant Tuesday the 17th. It is currently the 16th, but it is not yet Tuesday. However, if it is the management's decision that today shall be Tuesday, than I shall do my duty and respect that decision ;^) time-is-relatively y'rs, -Casey On Wednesday 11 June 2003 10:08 pm, Brian Lloyd wrote: Hi all - We had been planning to make a Zope 2.7a1 release on Friday, and another 2.6.2 beta soon as well. Someone noted (rightly!) that it would be ideal if we could have a bugday first. So I'll propose next Tuesday the 16th be bug day, and we'll plan to make both releases by the end of next week. Thoughts? Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Coders mailing list [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-coders ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] ZCTextIndex Improvements
For the past few days I have been working on database conflicts stemming from ZCTextIndex (no pun intended). The version currently released causes conflicts for *any* concurrent index/unindex operation. I have changed both the lexicon and index classes to fix this. Now conflicts coming from the BTrees are the only ones you will get, and they are internally resolved in most cases. Also, there was a bug in the query machinery that made it far more expensive for large indexes then it needs to be. This has also been fixed. These improvements have now landed on the Zope head and 2.6 branch (soon to be 2.6.2 beta 3 I think). Any of you running Zope in production with any amount of write concurrency should benefit. I ]encourage you to test the new ZCTextIndex code with your applications (in a test environment of course). You should be able to simply replace the ZCTextIndex product in your zope with the one in CVS (no reindex is necessary). I would certainly appreciate any feedback you might have on it. Please note, that the code does make some minor data structure changes to the index and lexicon the first time they are updated. Therefore you cannot simply remove the new product and go back to the old one by swapping the code. You will need to rebuild your Lexicons and ZCTextIndexes to go back. The hope though, is that you'll never want to ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
One man's opinion: - Version support (at the application level) should be optional in 2.7. You should be able to turn it off (maybe through ZConfig). The default should probably be off, since I think more people avoid them than use them. I would suggest these approaches: 1: File a bug in the collector and be prepared to wait an indefinite time for it to be acted upon. 2: develop a patch and submit it and/or check it in probably after vetting the change on a branch. I'm afraid the only way to get your favorite issue fixed quickly is to fix it yourself. The security implications do not seem dire enough to me to warrent trying to squeeze this into 2.6.x. If you do not use versions then none of the implications apply. Perhaps it might be possible to do additional security checks to make entering versions more protected. This might be an appropriate change for 2.6. -Casey On Friday 06 June 2003 05:46 am, Oliver Bleutgen wrote: Ok, I still have the impression that not enough people are aware of the full implications of the version functionality as it is implemented in zope. So let me summarize. versioning-as-implemented-in-zope consists of two parts: First, there's the database backend part (which I know nothing about) with a small glue layer (inside ZODB.ZApplication.ZApplicationWrapper). This resides where the db-connection is opened on the very start of every request. The second part is the Version product (capitalized to distinguish them) which is zope's mechanism to get a variable named 'Zope-Version' (==version_support) with the value of the path to the version object inside the REQUEST (by setting a cookie). Bad properties of this implementation: 1. The Join/Leave Versions permission doesn't secure entering versions 2. Zope doesn't care if a correspondending Version instance to the value of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for the value of that Zope-Version variable at all. 3. And (minor problem, but whatever), since zope relies completely on the browser to send cookies only the right time (i.e. that the path set for the cookie must match a prefix of the request-URI), this might also give unexpected results with acquisition. Security implications: Doh, anybody who can read/write to a zope server can get it to read/write from/to any version he likes, and the admin has no way of anticipating that short of patching zope. Combine that with sites like squishdot, collector.zope.org and you get chaos. Big plea: Really, this _is_ a security bug, and it should be handled that way and fixed in 2.6.2 by any meansm, so that all(!) bad properties I listed above are gone. Sorry for getting a bit worked up about that issue. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 maillist - [EMAIL PROTECTED] 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] Conflict reduced BTrees for cataloging
Although I'm not an expert on _p_independent, AFAIK, it can only be used for objects which are not in any way dependant on the state of other persistent objects. This is certainly not the case for BTrees, which is pretty much covers the data structures used for cataloguing and indexing. I would definitely recommend discussing this on zodb-dev before going forward with this. The current BTree intelligensia are over there. -Casey On Thursday 13 March 2003 04:39 pm, Dieter Maurer wrote: I am working on a CMS on top of ZODB for large amounts of large SGML/XML documents. To speed things up, a colleague started two import processes and we get incredible amounts of database read conflict errors from cataloguing (although we already use QueueCatalog for most indexes). I think, the data structures used for cataloguing and indexing could have a def _p_independent(self): return 1. Does anybody objects? If not, I will implement _p_independent BTrees and friends. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 maillist - [EMAIL PROTECTED] 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] Following the Zope Collector
Done. -Casey On Wednesday 26 February 2003 02:41 pm, Florent Guillaume wrote: On Wed, 2003-02-26 at 19:31, Steve Alexander wrote: So I'd like to propose to switch the Zope collector to dispatcher Off. This would mean more email traffic for the supporters, but it's easy enough to filter and I think the benefits are worth it. I get my notifications by subscribing to this list: http://mail.zope.org/mailman/listinfo/zope-collector-monitor Thanks Steve. Once again I failed to use the correct tools. sigh this kind of info really should be present on the http://collector.zope.org site besides being on http://dev.zope.org/CVS/CommitterGuidelines ... Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Python core dump zope 2.6.1+CMF1.3
On Wednesday 12 February 2003 09:20 am, R. David Murray wrote: [snip] I sup regularly, and rebuild regularly. That patch is already applied. Also, 2.2 appears to not need the patch, and it crashes, too. I can confirm that 2.2 does need to be configured with a larger stack size to work correctly with Zope/CMF on FreeBSD. Whether the port has this patch or not included I'm not sure. I don't use the port to run Zope apps, I only use it for others apps and testing. This also affects MacOSX, but I think the stack size *is* automatically bumped up during the Python compile (Go figure). As for Windows, no-one can honestly be surprised at software crashes there, it all part of the experience ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] ExternalEditor losing its lock?
Hmmm, I think this may be due to a typo in the helper app code. Try applying
the attached diff to zopeedit.py and see if it helps.
-Casey
On Tuesday 04 February 2003 03:58 am, Jean Jordaan wrote:
Hi all
A couple of times now, I've noticed this:
- I open a Python Script using ExternalEditor. A GET is issued,
My editor starts up, and a LOCK gets set.
- Now I view and execute the script (more GETs) while editing
and saving in my editor (PUTs get issued).
- That's fine. But then the lock goes away, and I successfully
edit the script in the ZMI: a POST goes thru. But there hasn't
been any UNLOCK yet. This shouldn't happen, right?
(Zope 2.5.1 (source release, python 2.1, linux2), python 2.1.3, linux2)
Excerpt from Z2.log:
192.168.1.5 - jean [03/Feb/2003:18:25:38 +0200] GET /externalEdit_/test
HTTP/1.1 200 1088 http://blommie:17081/manage_main; Mozilla/5.0 (X11;
U; Linux i686; en-US; rv:1.1) Gecko/20021212
192.168.1.5 - jean [03/Feb/2003:18:25:40 +0200] LOCK /test HTTP/1.1
200 789 Zope External Editor/0.6
192.168.1.5 - jean [03/Feb/2003:18:25:56 +0200] PUT /test HTTP/1.1 204
251 Zope External Editor/0.6
192.168.1.5 - jean [03/Feb/2003:18:25:58 +0200] GET
/test/manage_workspace HTTP/1.1 302 467
http://blommie:17081/manage_main; Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.1) Gecko/20021212
192.168.1.5 - jean [04/Feb/2003:10:32:25 +0200] PUT /test HTTP/1.1 204
251 Zope External Editor/0.6
192.168.1.5 - jean [04/Feb/2003:10:46:11 +0200] POST /test HTTP/1.1
200 12877 http://blommie:17081/test/ZPythonScriptHTML_editForm;
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20021212
192.168.1.5 - jean [04/Feb/2003:10:46:11 +0200] GET
/manage_page_style.css HTTP/1.1 200 3014 http://blommie:17081/test;
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20021212
192.168.1.5 - jean [04/Feb/2003:10:46:16 +0200] PUT /test HTTP/1.1 204
251 Zope External Editor/0.6
192.168.1.5 - jean [04/Feb/2003:10:46:18 +0200] GET
/test/manage_workspace HTTP/1.1 302 467 http://blommie:17081/test;
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20021212
--
Jean Jordaan
http://www.upfrontsystems.co.za
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
*** zopeedit.py.old Tue Feb 4 09:06:48 2003
--- zopeedit.py Tue Feb 4 09:07:14 2003
***
*** 415,421
return 0 # Already have a lock token
headers = {'Content-Type':'text/xml; charset=utf-8',
!'Timeout':'infinite',
'Depth':'infinity',
}
body = ('?xml version=1.0 encoding=utf-8?\n'
--- 415,421
return 0 # Already have a lock token
headers = {'Content-Type':'text/xml; charset=utf-8',
!'Timeout':'infinity',
'Depth':'infinity',
}
body = ('?xml version=1.0 encoding=utf-8?\n'
Re: [Zope-dev] [PATCH] Forking daemon in debug mode, and new start scripts
On Tuesday 21 January 2003 06:45 pm, Adrian van den Dries wrote: [Sorry about the broken thread] On January 20, Guido van Rossum wrote: You seem to forget that in debugging mode there are other things that happen (or not) besides logging. Ah, the infamous Zope side-effect, aka other cool stuff. :-) Thanks for the heads-up. And you can log to stderr (that's what I use 99% of the time). But this means I can't really write a start script that works (or makes sense) with debug mode both on and off. Redirecting stderr to EVENT_LOG_FILE doesn't really make sense if we're detaching, and is ugly, etc.. I could write some shell polava to figure it out, but: Maybe the debug flag is misnamed? All it really means is don't detach. Yes. I would much prefer an explicit flag for each, because I run a number of dev Zopes on a number of boxes to which I only have ssh access, and I don't want to have to remember to play games with my stdio, or restart Zope if I restart screen, etc. Speaking of the (side-)effects of debug mode, what exactly are they? Is it just the automatic re-loading of DTMLFiles and PageTemplates from disk? There's a lot of code that gets enabled when the debug (also known as development) mode gets turned on. Most of it involves auto-refreshing things from the file system, but there are many other things. Zope generally runs *much* slower in debug mode then in production mode also. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope and Python compatibility
On Monday 13 January 2003 09:56 am, Guido van Rossum wrote: What would the arguments be for sticking with Zope 2.1.3 for Zope 2.7? I feel most people want to use the latest and greatest versions, usually... Actually, most people don't care about the latest and greatest, and would prefer tried and trusted. Especially if the latest and greatest means they have to install more stuff. Or? Of course, if the requirement could be 2.1.3 *or* 2.2.2, that would be nice, but is that realistic? In practice, Zope 2.6(.x) already fulfills this requirement, it's only that ZC doesn't have the resources to guarantee it. I think 2.7 would be in the same boat. FYI, the current CVS head (to be 2.7) now requires 2.2.2 as per an earlier papal edict. So there will be at least some work involved in making it run under 2.1.3. I kindof feel like we already made a rather firm commitment to *requiring* 2.2.x. I did not fully agree with that decision at the time, but to renig on it now seems fairly counterproductive unless someone can provide a really good reason. I personally feel like Zope should run on 2.2.x whether required or not. Requiring 2.2.x does have the advantage of limiting the possible blessed configurations on which Zope will run, thereby making development, support and bug fixing that much easier. Otherwise I can see having to develop on Python 2.1.x and test on 2.1.x and 2.2.x. It would be nice not to have to do this when developing 2.7 only code. I realize that this would be necessary when backporting things to 2.6. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Custom Repository for Storing Objects
If you want a transparent connection between your XML RDBMS and Zope so that Zope need not be aware of the storage for these objects then you can use Shane's AdaptableStorage to create a bridge between Zope's ZODB and your RDBMS. This is probably not going to be a total walk in the park though ;^). Also I would caution that the XML factor is likely to introduce significant overhead to the storage, which when combined with the underlying RDBMS overhead could result in disappointing performance. Just straight RDBMS ZODB storage (such as OracleStorage) not using XML at all is significantly slower than the stock FileStorage for instance. A less transparent option would be to create your own bridge by writing a Zope product that can interact via this XML API and conjure up non-persistent objects to represent its state. Then use the standard ZODB FileStorage or ZEO for the Zope side of things. It would be even easier if your API was done over XML-RPC. Then the marshalling of the XML to python objects could be largely done for you. hth, Casey scold type=obligatoryPlease don't cross-post your messages in the future. Many of us are subscribed to multiple lists and don't appreciate reading the same message multiple times. Thanks/scold On Thursday 09 January 2003 09:11 pm, Sameer Maggon wrote: Hi, I am a newbie to Zope and have just gone through the tutorials and a little bit of ZopeBook. I have my own Custom Repository (RDBMS based) that has the features like storing flat files, folders etc. It also has provisions for user management. I have the XML APIs (lanuage is not a problem) for interacting with the repository. Can I store all the objects created in Zope in that repository? Further I also want that the authentication should also be done based on that repository (its like the roles and users defined in the custom system). Is it possible in Zope? I can comprehend that I would need to develop some kind of an interface that sits between the two for integration, but I wanted to know that whether it is possible in Zope or not? Its like when a user creates a folder or an object, the request is actually send to a module and then that module stores the object in my repository (may be the format is little bit changed) and vice-versa. Anticipating a positive response Sameer Maggon ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] XML-RPC External Method bug
You should file a collector issue re this and give a specific set of steps to exercise the bug. I corrected a seemingly similar bug recently. I assume you have tried this on the 2.6.1 beta? I don't think anything changed between 2.6.0 and 2.6.1 in this regard but you never know. I do know I changed things in there between 2.5.1 and 2.6.0. -Casey On Tuesday 07 January 2003 10:01 am, Nathan 'Nato' Uno wrote: Greetings! I've been working with some of my coworkers tracking a problem very similar to the one described in this thread: http://lists.zope.org/pipermail/zope-dev/2002-November/017922.html which is also outlined here: http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/B9323F6D666D3D5C and I've found out some things which may be helpful in finding a better long-term solution. There appears to be a problem with the way that External Methods are inspected when called via XML-RPC. Specifically, mapply() doesn't know what arguments the external method is expecting, apparently because the 'func_defaults' attribute of the object doesn't seem to be set properly. Interestingly enough, if apply() is called then the external method is fully inspected (presumably because it's actually invoked), after which the external method call works properly via XML-RPC. Practically this means that when I invoke an external method via XML-RPC and pass the correct arguments, mapply() doesn't know what arguments the method is expecting, assumes (in essence) that it expects 0, and returns 'too many arguments' (where 1 0). However, if I invoke the external method with *no* arguments, mapply() assumes that everything is good and invokes apply(), which throws a TypeError (function expects at least 1 argument, 0 given). If I then invoke the method *again* with the proper arguments (i.e. I use exactly the same call I made the first time), then the object inspected by mapply() has the 'func_defaults' attribute correctly set and the method works properly. I've spent the better part of two days sprinkling LOG() calls throughout ZPublisher, so I can give some more detailed information if anyone's really interested. In the meantime, I temporarily hacked my local copy of mapply() to invoke apply(object, '') for every call, forcing the method to be properly inspected/cached/whatever, then caught the TypeError and moved on to the rest of mapply. This worked for me, causing all of my XML-RPC calls to function properly, but concerned me because it opened the possibility of apply(object, '') being called successfully twice for an object that takes no arguments. So I backed that out and hacked by local copy of publish() instead, calling apply(object, '') for any object whose path matches my external methods. This should work for us without any unintended side effects, but I'd obviously like to be involved with a long-term solution that would benefit the whole community. Please let me know if there's any more information I can give or anything else I can contribute. I'd be glad to do more legwork, but I got bogged down last night trying to unravel the inspection/creation of external method objects, and can't really proceed effectively without some pointers on how that stuff works and where to poke around. Thanks very much, Nathan 'Nato' Uno Hostway Corporation [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Publishing
On Wednesday 08 January 2003 05:04 pm, Sameer Maggon wrote: Hi, In some CMS we have different environment for Development (Authoring), Staging and Production. The CMS Database that resides in the Development setup is usually more bulky than the database in the production and staging site. Can any body tell me how Zope fits into this situation, is there any component that takes care of this? My major concern is that, it might be that my repository contains huge number of images but actually the site uses only some of them. So when actually deploying a site, the system should resolve those images and put the required files. A combination of CMFStaging/ZopeVersionControl (available from cvs) and mounted storages would probably solve this nicely. The latter would be optional, but would allow you to have a separate ZEO storage server for production that contained only the published content objects and was only written to when content was published or retracted, not on every edit. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CRITICAL!!!! CVS: Zope/lib/python/OFS - Image.py:1.141.4.3
I will go ahead and roll-back this change. Doing it now. -Casey On Tuesday 17 December 2002 08:03 am, Guido van Rossum wrote: BIG PROBLEM WITH THIS CHECK-IN FROM YESTERDAY: I've updated my ZOPE and now all Images are broken!!! ZOPE lives behind a SQUID. I think that RESPONSE.setBase(None) is NOT a good idea at all!!! Commenting this out and all works as expected... Indeed -- the nightly unit tests also pointed this out. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Bug Day Followup
Just wanted to thank everyone for their participation on bug day and wanted to followup with a couple of reminders: 1. Make sure CHANGES.txt got updated on the 2.6 branch if you checked in a change. Its not too late to update it now. 2. Make sure bug fixes you made on the 2.6 branch get merged into the HEAD, otherwise they are likely to reappear in 2.7. Again thanks to everyone for a great bug day! -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] dupe column names not supported (Shared.DC.ZRDB) ?
The semantics of Zope's database functionality is such that duplicate column names are not (and probably never will be) possible in the same result set. This is because Zope expects to access columns by name rather than position. Therefore each one must have a distinct name. The only workaround I can see would be some sort of automatic renaming of columns, but that sounds like a bad idea since it introduces some serious bug potential if the columns are renamed differently then the application expects. Just for curiousity, what is the use case for returning multiple columns with the same name? Sounds dubious to me. -Casey On Tuesday 17 December 2002 02:11 pm, Ross J. Reedstrom wrote: Same problem has been reported with Oracle 8.1, since it too will return duplicate names. The SQL92 spec is a bit ambiguous about whether all returned column names must be unique. Ross On Tue, Dec 17, 2002 at 01:09:13PM -0500, Adam Manock wrote: specifically with: SELECT W1.city, W1.temp_lo AS low, W1.temp_hi AS high, W2.city, W2.temp_lo AS low, W2.temp_hi AS high FROM weather W1, weather W2 WHERE W1.temp_lo W2.temp_lo AND W1.temp_hi W2.temp_hi; Error, exceptions.ValueError: Duplicate column name, city Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Shared.DC.ZRDB.Connection, line 115, in manage_test Module Shared.DC.ZRDB.Results, line 52, in __init__ ValueError: Duplicate column name, city ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
