hi, i am using BTreeFolder to store around 10000 objects. the problem is when an object is deleted, its id still remains in the ZMI listing of the ids, and when that id is tried to be accessed, i get a Resource Not Found error. I am able to add another object with the same id, and in this case both ids exist. is this a known issue ? or can anyone suggest some way to deal with this ? this is a production server and for obvious reasons, we are not able to replicate the error regards vineeth __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
On Wednesday 14 May 2003 13:39, vineeth wrote:
hi,
i am using BTreeFolder to store around 10000 objects.
the problem is when an object is deleted, its id still remains in the ZMI listing of the ids, and when that id is tried to be accessed, i get a Resource Not Found error. I am able to add another object with the same id, and in this case both ids exist. is this a known issue ?
or can anyone suggest some way to deal with this ? this is a production server and for obvious reasons, we are not able to replicate the error
I actually use BTreeFolder2, which seems to be less "memory consuming" while storing a lot of objects. I didn't notice any problem with it... Thierry
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Linux every day, keeps Dr Watson away... http://gpc.sourceforge.net -- http://www.ulthar.net
vineeth wrote at 2003-5-14 04:39 -0700:
the problem is when an object is deleted, its id still remains in the ZMI listing of the ids, and when that id is tried to be accessed, i get a Resource Not Found error. I am able to add another object with the same id, and in this case both ids exist. is this a known issue ?
This looks like a (HTTP) cache issue. Cache issues can be detected by forcing the browser to reload the page (usually be pressing both "SHIFT" and calling for "reload"). When the problem disappears, it has been a (HTTP) cache issue. Dieter
Hello Dieter, we have the same problem on our production server. This problem only appears (in our case) with object ids starting with a space. We have such a ghost object in our system since last spring. It can't be accessed, deleted, moved, exported or overwritten. Also the the BTreeFolder containing this object can't be exported. But I can loop over the subjects of this folder with an in-tag. In this case the ghost object doesn't appear in the loop... I think the problem is that the Object has allready been deleted but the id can't be removed from the list. Greetings Sven
the problem is when an object is deleted, its id still remains in the ZMI listing of the ids, [...]
This looks like a (HTTP) cache issue. [...]
--
Sven Rudolph wrote:
we have the same problem on our production server. This problem only appears (in our case) with object ids starting with a space. We have such a ghost object in our system since last spring. It can't be accessed, deleted, moved, exported or overwritten. Also the the BTreeFolder containing this object can't be exported. But I can loop over the subjects of this folder with an in-tag. In this case the ghost object doesn't appear in the loop... I think the problem is that the Object has allready been deleted but the id can't be removed from the list.
Sven, Are you using BTreeFolder or BTreeFolder2? Shane
Sven Rudolph wrote at 2003-5-14 23:00 +0200:
we have the same problem on our production server. This problem only appears (in our case) with object ids starting with a space.
I tried to reproduce this problem and, to my great surprise, I succeeded. However, it turned out to be a bug in my browser ("Konqueror"). It drops leading spaces in submitted option values. Maybe, your case is similar.
We have such a ghost object in our system since last spring. It can't be accessed, deleted, moved, exported or overwritten.
As the id is always wrong (missing leading whitespace), this can be explained.
Also the the BTreeFolder containing this object can't be exported.
I can export my "BTreeFolder" without problem.
But I can loop over the subjects of this folder with an in-tag. In this case the ghost object doesn't appear in the loop...
I did not try but I am sure, the object will be there.
I think the problem is that the Object has allready been deleted but the id can't be removed from the list.
That might be the case, but I do not see why this might be possible. When I worked around the browser bug, the object with leading space was deleted without problem. No ghost object were created. I use, however, an optimized "BTreeFolder" variant which make no use of "_objects". BTW: The URL spec forbids white space in URLs (to improve readability). Dieter
participants (5)
-
Dieter Maurer -
Shane Hathaway -
Sven Rudolph -
Thierry FLORAC -
vineeth