[Zope-dev] Re: Zope 2.7 b3 problem with reindexing catalog
Dieter Maurer wrote: robert wrote at 2003-11-24 05:32 +0100: 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' update_metadata is a new keyword argument introduced recently (to fix a bug in Zope 2.6.2). Apparently, you have hit a bug in ZCatalog: While reindexIndex already uses the new argument, catalog_object does not yet support it. Yes. CMF's CatalogTool inherits from ZCatalog and overrides catalog_object. Robert, please report this to the Zope and the CMF Collector: - Zope's ZCatalog should have a capability check in reindexIndex. (Zope-2_6-branch, Zope-2_7-branch and HEAD) - CMF's CatalogTool should implement the new Interface. 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 )
Re: [Zope-dev] Re: Zope 2.7 b3 problem with reindexing catalog
I will report a bug Robert Am Dienstag, 25. November 2003 08:25 schrieb Yuppie: Dieter Maurer wrote: robert wrote at 2003-11-24 05:32 +0100: 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' update_metadata is a new keyword argument introduced recently (to fix a bug in Zope 2.6.2). Apparently, you have hit a bug in ZCatalog: While reindexIndex already uses the new argument, catalog_object does not yet support it. Yes. CMF's CatalogTool inherits from ZCatalog and overrides catalog_object. Robert, please report this to the Zope and the CMF Collector: - Zope's ZCatalog should have a capability check in reindexIndex. (Zope-2_6-branch, Zope-2_7-branch and HEAD) - CMF's CatalogTool should implement the new Interface. 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 ) -- mit freundlichen Grüssen Robert Rottermann www.redCOR.ch ___ 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 2.7 b3 problem with reindexing catalog
I opened an issue in the Zope collector but I am to dumb to find the CMF collector. If somebody please points me to it. Robert Am Dienstag, 25. November 2003 08:25 schrieb Yuppie: Dieter Maurer wrote: robert wrote at 2003-11-24 05:32 +0100: 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' update_metadata is a new keyword argument introduced recently (to fix a bug in Zope 2.6.2). Apparently, you have hit a bug in ZCatalog: While reindexIndex already uses the new argument, catalog_object does not yet support it. Yes. CMF's CatalogTool inherits from ZCatalog and overrides catalog_object. Robert, please report this to the Zope and the CMF Collector: - Zope's ZCatalog should have a capability check in reindexIndex. (Zope-2_6-branch, Zope-2_7-branch and HEAD) - CMF's CatalogTool should implement the new Interface. 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 ) -- mit freundlichen Grüssen Robert Rottermann www.redCOR.ch ___ 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 b3 problem with reindexing catalog
robert wrote: I opened an issue in the Zope collector but I am to dumb to find the CMF collector. If somebody please points me to it. http://collector.zope.org/CMF or http://zope.org/Collectors/CMF 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 )
Re: [Zope-dev] Re: New-style ExtensionClasses (Zope 2.8) -- MRO issue
On Mon, 2003-11-24 at 12:03, Christian Heimes wrote: Sidnei da Silva wrote: I'm going to fix those (after my english class) and then try something harder ;) Here is more stuff: import mrohell base = mrohell.step1() mrohell.step2(base, mroonly=True) Couldn't get mro for Products.Archetypes.BaseBTreeFolder.BaseBTreeFolder Couldn't get mro for Products.Archetypes.BaseFolder.BaseFolder Couldn't get mro for Products.Archetypes.OrderedBaseFolder.OrderedBaseFolder Couldn't get mro for Products.GroupUserFolder.GroupUserFolder.GroupUserFolder Couldn't get mro for Products.CMFPlone.PloneFolder.BasePloneFolder Couldn't get mro for Products.CMFPlone.LargePloneFolder.LargePloneFolder Couldn't get mro for Products.Archetypes.BaseFolder.BaseFolderMixin Couldn't get mro for Products.CMFDefault.SkinnedFolder.SkinnedFolder Couldn't get mro for Products.CMFPlone.PloneFolder.PloneFolder Couldn't get mro for Products.Archetypes.ArchetypeTool.ArchetypeTool Couldn't get mro for Products.CMFFormController.Script.FSPythonScript Couldn't get mro for Products.CMFFormController.FSControllerValidator.FSControllerValidator Couldn't get mro for Products.CMFCore.FSPythonScript.FSPythonScript Couldn't get mro for Products.CMFFormController.FSControllerPythonScript.FSControllerPythonScript Couldn't get mro for Products.CMFCore.FSPageTemplate.FSPageTemplate Couldn't get mro for Products.CMFFormController.FSControllerPageTemplate.FSControllerPageTemplate Couldn't get mro for Products.CMFPlone.PropertiesTool.PropertiesTool Couldn't get mro for Products.CMFCore.FSZSQLMethod.FSZSQLMethod Couldn't get mro for Products.CMFPlone.FactoryTool.TempFolder Couldn't get mro for Products.Archetypes.OrderedBaseFolder.OrderedFolder Couldn't get mro for Products.Archetypes.examples.SimpleFolder.SimpleFolder 526 21 210 It seems that there are only several classes that cause problems: Products.CMFDefault.SkinnedFolder.SkinnedFolder Products.Archetypes.BaseFolder.BaseFolder Products.CMFCore.FS* Products.Archetypes.BaseFolder.BaseFolderMixin AFAIK most of the other classes with mro problems are just subclasses of these classes above. Jim made checkins to deal with the CMF-related MRO problems, on his 'mro-advanture-branch':: === CMF/CMFDefault/SkinnedFolder.py 1.15 = 1.15.6.1 === --- CMF/CMFDefault/SkinnedFolder.py:1.15Sat Jun 28 12:31:21 2003 +++ CMF/CMFDefault/SkinnedFolder.py Fri Oct 31 14:24:19 2003 @@ -61,8 +61,7 @@ , ) - -class SkinnedFolder(CMFCatalogAware, PortalFolder): +class SkinnedFolder(PortalFolder): meta_type = 'Skinned Folder' @@ -70,6 +69,10 @@ security = ClassSecurityInfo() manage_options = PortalFolder.manage_options + +indexObject = CMFCatalogAware.indexObject +unindexObject = CMFCatalogAware.unindexObject +reindexObject = CMFCatalogAware.reindexObject def __call__(self): ''' === CMF/CMFCore/FSObject.py 1.15 = 1.15.2.1 === --- CMF/CMFCore/FSObject.py:1.15Fri Sep 12 20:46:40 2003 +++ CMF/CMFCore/FSObject.py Fri Oct 31 14:24:18 2003 @@ -18,7 +18,7 @@ from string import split from os import path, stat -import Acquisition, Globals +import Acquisition, Globals, ExtensionClass from AccessControl import ClassSecurityInfo from OFS.SimpleItem import Item from DateTime import DateTime @@ -31,7 +31,7 @@ from OFS.Cache import Cacheable -class FSObject(Acquisition.Implicit, Item, Cacheable): +class FSObject(Item, Cacheable, Acquisition.Implicit, ExtensionClass.Base): FSObject is a base class for all filesystem based look-alikes. Subclasses of this class mimic ZODB based objects like Image and I imagine making similar small changes to Archetypes won't be hard. Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.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 )
Re: [Zope-dev] Re: New-style ExtensionClasses (Zope 2.8) -- MRO issue
Note that this is moot, as I've decided to use a backward-compatible mro. That is, new-style extension classes will use an mro that is backward compatible with old-style extension classes. They do *not* use the same mro algorithm as new-style classes. Jim Tres Seaver wrote: On Mon, 2003-11-24 at 12:03, Christian Heimes wrote: Sidnei da Silva wrote: I'm going to fix those (after my english class) and then try something harder ;) Here is more stuff: import mrohell base = mrohell.step1() mrohell.step2(base, mroonly=True) Couldn't get mro for Products.Archetypes.BaseBTreeFolder.BaseBTreeFolder Couldn't get mro for Products.Archetypes.BaseFolder.BaseFolder Couldn't get mro for Products.Archetypes.OrderedBaseFolder.OrderedBaseFolder Couldn't get mro for Products.GroupUserFolder.GroupUserFolder.GroupUserFolder Couldn't get mro for Products.CMFPlone.PloneFolder.BasePloneFolder Couldn't get mro for Products.CMFPlone.LargePloneFolder.LargePloneFolder Couldn't get mro for Products.Archetypes.BaseFolder.BaseFolderMixin Couldn't get mro for Products.CMFDefault.SkinnedFolder.SkinnedFolder Couldn't get mro for Products.CMFPlone.PloneFolder.PloneFolder Couldn't get mro for Products.Archetypes.ArchetypeTool.ArchetypeTool Couldn't get mro for Products.CMFFormController.Script.FSPythonScript Couldn't get mro for Products.CMFFormController.FSControllerValidator.FSControllerValidator Couldn't get mro for Products.CMFCore.FSPythonScript.FSPythonScript Couldn't get mro for Products.CMFFormController.FSControllerPythonScript.FSControllerPythonScript Couldn't get mro for Products.CMFCore.FSPageTemplate.FSPageTemplate Couldn't get mro for Products.CMFFormController.FSControllerPageTemplate.FSControllerPageTemplate Couldn't get mro for Products.CMFPlone.PropertiesTool.PropertiesTool Couldn't get mro for Products.CMFCore.FSZSQLMethod.FSZSQLMethod Couldn't get mro for Products.CMFPlone.FactoryTool.TempFolder Couldn't get mro for Products.Archetypes.OrderedBaseFolder.OrderedFolder Couldn't get mro for Products.Archetypes.examples.SimpleFolder.SimpleFolder 526 21 210 It seems that there are only several classes that cause problems: Products.CMFDefault.SkinnedFolder.SkinnedFolder Products.Archetypes.BaseFolder.BaseFolder Products.CMFCore.FS* Products.Archetypes.BaseFolder.BaseFolderMixin AFAIK most of the other classes with mro problems are just subclasses of these classes above. Jim made checkins to deal with the CMF-related MRO problems, on his 'mro-advanture-branch':: === CMF/CMFDefault/SkinnedFolder.py 1.15 = 1.15.6.1 === --- CMF/CMFDefault/SkinnedFolder.py:1.15Sat Jun 28 12:31:21 2003 +++ CMF/CMFDefault/SkinnedFolder.py Fri Oct 31 14:24:19 2003 @@ -61,8 +61,7 @@ , ) - -class SkinnedFolder(CMFCatalogAware, PortalFolder): +class SkinnedFolder(PortalFolder): meta_type = 'Skinned Folder' @@ -70,6 +69,10 @@ security = ClassSecurityInfo() manage_options = PortalFolder.manage_options + +indexObject = CMFCatalogAware.indexObject +unindexObject = CMFCatalogAware.unindexObject +reindexObject = CMFCatalogAware.reindexObject def __call__(self): ''' === CMF/CMFCore/FSObject.py 1.15 = 1.15.2.1 === --- CMF/CMFCore/FSObject.py:1.15Fri Sep 12 20:46:40 2003 +++ CMF/CMFCore/FSObject.py Fri Oct 31 14:24:18 2003 @@ -18,7 +18,7 @@ from string import split from os import path, stat -import Acquisition, Globals +import Acquisition, Globals, ExtensionClass from AccessControl import ClassSecurityInfo from OFS.SimpleItem import Item from DateTime import DateTime @@ -31,7 +31,7 @@ from OFS.Cache import Cacheable -class FSObject(Acquisition.Implicit, Item, Cacheable): +class FSObject(Item, Cacheable, Acquisition.Implicit, ExtensionClass.Base): FSObject is a base class for all filesystem based look-alikes. Subclasses of this class mimic ZODB based objects like Image and I imagine making similar small changes to Archetypes won't be hard. Tres. -- 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] Can we forsake database backward compatability on the head for a while?
Zope 2.8 will not include the old BTree or intSet objects. I plan to arrange for this not to be a problem for old databases. Somehow, Zope 2.8 will convert these automatically. I haven't done this yet though. I'd like to merge the new-style ExtensionClass and ZODB 3.3 work soon. I'd like not to wait for the old-style BTree and intSet compatability work. This would mean that old databases would not be useable with the CVS head in the near term. Would this cause anyone any problems? 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] session concurrency
Hi Santi, I've a product, http://zetadb.sourceforge.net, that uses SESSION extensively. I've just discover, unhappiness, that there are some problems when SESSION object is changed at the same time in two diferent python scripts (using frames). The two frames are changing diferent keys of the SESSION object, but at the end the whole SESSION object is saved, I think, so one of the two objects losses its SESSION data Anybody knows any workarround about this? I guess this happens because the SESSION is stored with a low conflict resolution in the TempFolder. You should be able to switch the conflict resolution in the temp folder to something more strict, which may increase the number conflict errors a lot. There have been a thread which may tell You how to do this on this list in March(?) of this year; seaching the mailing list archive for LowConflictConnection or something similar may help. Cheers, Clemens ___ 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] session concurrency
Santi Camps wrote at 2003-11-24 23:14 +0100: I've a product, http://zetadb.sourceforge.net, that uses SESSION extensively. I've just discover, unhappiness, that there are some problems when SESSION object is changed at the same time in two diferent python scripts (using frames). The two frames are changing diferent keys of the SESSION object, but at the end the whole SESSION object is saved, I think, so one of the two objects losses its SESSION data It should *NOT* loose its session data but get a ConflictError and automatically retry the request. That's normal ZODB behaviour. Search for Application specific conflict resolution for a (complex, in your case) way to work around this. A partial workaround may be to put your various keys into persistent subobjects. -- 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 )
