Ira Sher wrote at 2004-3-5 18:02 -0500:
This is the traceback I always get from adding this particular object and then going to view the site homepage: ... - __traceback_info__: data_record_id_ Module <string>, line 1, in <expression> Module Products.ZCatalog.ZCatalog, line 562, in getobject Module OFS.Traversable, line 106, in unrestrictedTraverse - __traceback_info__: (['105586758764', 'Neela Vaswani', 'Authors'], '') IndexError: string index out of range
Based on feedback I've been getting here, I'm definitely not concentrating on data corruption anymore...any ideas about where best to place my attentions?
One of your objects (the one your application currently tries to access) is catalogued with a bad "uid" (unique id). Usually, the "uid" is a path derived from "getPhysicalPath" (the path from the root to the object). In the case of this object, the uid is a path "...//Authors/Neela Vaswani/105586758764" but the path contains an empty segment. "unrestrictedTraverse" (called by "getObject") cannot handle this case. We can fix this manually when you have enough information to identify the object. For this, you must determine the path with the empty segment. For this, you would replace the "getObject" by a "getPath" and output the path somehow. Then, in a Python Script (or interactively, when you know how you do this) you call "...catalog.uncatalog_object(yourBadPath)". This removes the broken object from the catalog. After that, you recatalog the object again "...catalog.catalog_object(yourObject)". Of course, we then still do not know how the bad path happened to enter the catalog. Other objects might suffer from the same problem.... -- Dieter