Hi All, Not sure if this is quite the correct list to post to, but I'm having trouble with Hotfix20040714. We're running zope 2.7, plone 2.0.3, and zwiki 0.32.0. The specific error appears to be the same one that cropped up with the previous hotfix (20040713): METALError: macro "python:here.wikipage_macros().macros['quickaccesskeys']" has incompatible version '1.4', at line 11, column 5 (Also, an error occurred while attempting to render the standard error message.) Thanks for the help! Cliff The complete traceback follows: Site Error An error was encountered while publishing this resource. METALError Sorry, a site error occurred. Traceback (innermost last): * Module ZPublisher.Publish, line 163, in publish_module_standard * Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish * Module ZPublisher.Publish, line 127, in publish * Module Zope.App.startup, line 203, in zpublisher_exception_hook * Module ZPublisher.Publish, line 100, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Products.ZWiki.ZWikiPage, line 220, in __call__ * Module Products.ZWiki.ZWikiPage, line 233, in render * Module Products.ZWiki.pagetypes.stx, line 94, in render * Module Products.ZWiki.UI, line 209, in addSkinTo * Module Shared.DC.Scripts.Bindings, line 306, in __call__ * Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec * Module Products.CMFCore.FSPageTemplate, line 191, in _exec * Module Products.CMFCore.FSPageTemplate, line 124, in pt_render * Module Products.PageTemplates.PageTemplate, line 96, in pt_render <FSPageTemplate at /lab/wikipage used for /lab/wiki/FrontPage> * Module TAL.TALInterpreter, line 189, in __call__ * Module TAL.TALInterpreter, line 233, in interpret * Module TAL.TALInterpreter, line 663, in do_useMacro * Module TAL.TALInterpreter, line 233, in interpret * Module TAL.TALInterpreter, line 408, in do_optTag_tal * Module TAL.TALInterpreter, line 393, in do_optTag * Module TAL.TALInterpreter, line 388, in no_tag * Module TAL.TALInterpreter, line 233, in interpret * Module TAL.TALInterpreter, line 694, in do_defineSlot * Module TAL.TALInterpreter, line 233, in interpret * Module TAL.TALInterpreter, line 408, in do_optTag_tal * Module TAL.TALInterpreter, line 393, in do_optTag * Module TAL.TALInterpreter, line 388, in no_tag * Module TAL.TALInterpreter, line 233, in interpret * Module TAL.TALInterpreter, line 642, in do_defineMacro * Module TAL.TALInterpreter, line 233, in interpret * Module TAL.TALInterpreter, line 686, in do_defineSlot * Module TAL.TALInterpreter, line 233, in interpret * Module TAL.TALInterpreter, line 656, in do_useMacro METALError: macro "python:here.wikipage_macros().macros['quickaccesskeys']" has incompatible version '1.4', at line 11, column 5 (Also, an error occurred while attempting to render the standard error message.) Troubleshooting Suggestions * The URL may be incorrect. * The parameters passed to this resource may be incorrect. * A resource that this resource relies on may be encountering an error. For more detailed information about the error, please refer to error log. If the error persists please contact the site maintainer. Thank you for your patience. On Mon, 19 Jul 2004, Florent Guillaume wrote:
thanks to all the responses. I will test with BTreeFolder2, and subfoldering with first character of id as another subfolder2, so that working with ZMI will also be possible without further scripting or customized views. i will report the results back to the list.
just an additional info: I run into this problem recently...
I've got something around 40k objects to insert into ZODB.
I started doing some tests with normal Folders, but I discarded it completely in favor of BTreeFolders. I got information that BTreeFolder was already tested with more than 400k objects... and that made me happy! :-)
But (there's always a 'but'!)...
Even using BTreeFolder to store all objects I was getting >300s delay to show a single object (ok, it's an archetypes-based one, containing >50 fields, splitted into 7 schematas, with lots of fancy stuff...). So I made a directory hash structure based on UID from each object (an AT UID is md5, so we have a hex base).
Using this hash structure, with 16 divisions, I got a better performance (but still far from acceptable): 'only' ~100s to show a single object... :-(
So I decided to create another level for the hash structure: now each folder has another 16 folder inside it. This time I was getting a delay of ~20s...
As you're already thinking... it's time for another hash level. Now, with 16^3 additional BTreeFolders to split all my objects I got an acceptable performance: ~3s...
The path is uggly as hell, f/f0/f0a/f0a5aac38aeff101b3168f2592dd879b, but at least the system is usable...
Resuming what I've learned: don't abuse of BTreeFolder, hash your content and live happy forever... ;-)
I very much doubt you solved the problem you think you solved. Access time to a single object in the hundred of seconds is not a BTreeFolder problem. BTreeFolder is designed to not be a bottleneck for concurrent access and large number of objects.
You should have benched (using ZopeProfiler for instance) to find out where time really is spent. Maybe some of your/AT's code does a stupid loop on folder.objectIds() or something.
Florent
-- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )