OK try this (well don't unless you want undeletable objects) create something that is CatalogAware, than have it index itself "index_object" (when being created, inside a factory I think?), now clear your catalog and use "Find Items to ZCatalog" to index the same object. Lastly try to delete the object, Zope complains can't uncatalog the object and it won't delete it. The uid or rid or data_record_id_ (can somebody make up their "minds"?) is first indexed WITHOUT the leading '/' and than with it if we "Find Items ..." Would: url='%s/%s' % (self.DestinationURL(), self.id) not return a leading '/'? If so, would url='/%s/%s' % (self.DestinationURL(), self.id) fix it? Else could somebody add a test to see if 'uri' has a '/' in the front and ignore the problem... relevant CatalogAwareness.py: def url(self, ftype=urllib.splittype, fhost=urllib.splithost): """Return a SCRIPT_NAME-based url for an object.""" if hasattr(self, 'DestinationURL') and \ callable(self.DestinationURL): url='%s/%s' % (self.DestinationURL(), self.id) else: url=self.absolute_url() type, uri=ftype(url) host, uri=fhost(uri) script_name=self.REQUEST['SCRIPT_NAME'] __traceback_info__=(`uri`, `script_name`) if script_name: uri=filter(None, string.split(uri, script_name))[0] uri=uri or '/' if uri[0]=='/': uri=uri[1:] return uri def index_object(self): """A common method to allow Findables to index themselves.""" if hasattr(self, self.default_catalog): getattr(self, self.default_catalog).catalog_object(self, self.url()) Maybe relevant FactoryDispatcher.py class FactoryDispatcher(Acquisition.Implicit): " " def __init__(self, product, dest, REQUEST=None): if hasattr(product,'aq_base'): product=product.aq_base self._product=product self._d=dest if REQUEST is not None: v=REQUEST['URL'] v=v[:rfind(v,'/')] self._u=v[:rfind(v,'/')] def DestinationURL(self): "Return the URL for the destination for factory output" return self._u
David Kankiewicz wrote:
create something that is CatalogAware, than have it index itself "index_object" (when being created, inside a factory I think?), now clear your catalog and use "Find Items to ZCatalog" to index the same object. Lastly try to delete the object, Zope complains can't uncatalog the object and it won't delete it.
This is in part because of unindex's EXTREMELY annoying behavior when you call it on uncataloged objects. Unindex should simply *return* an error message if its called when the the object is already uncataloged - raising an error is very annoying in a lot of cases. It makes a lot more sense, too - at the end of the unidex I want the object to be removed form the catalog. Since it alreasy isn't in the catalog, unindex should just do nothing, not raise an exception! This sould solve lots of problems I've had (I always change manage_beforeDelete in CatalogAware to do "try: self.unindex" to work around this), and for a lot of other people too. -- Itamar S.T. itamars@ibm.net
Itamar Shtull-Trauring wrote:
David Kankiewicz wrote:
create something that is CatalogAware, than have it index itself "index_object" (when being created, inside a factory I think?), now clear your catalog and use "Find Items to ZCatalog" to index the same object. Lastly try to delete the object, Zope complains can't uncatalog the object and it won't delete it.
This is in part because of unindex's EXTREMELY annoying behavior when you call it on uncataloged objects.
Unindex should simply *return* an error message if its called when the the object is already uncataloged - raising an error is very annoying in a lot of cases. It makes a lot more sense, too - at the end of the unidex I want the object to be removed form the catalog. Since it alreasy isn't in the catalog, unindex should just do nothing, not raise an exception!
This sould solve lots of problems I've had (I always change manage_beforeDelete in CatalogAware to do "try: self.unindex" to work around this), and for a lot of other people too.
FWIW, I have a short how-to on deleting uncatalogued objects that refuse to be deleted normally: http://www.zope.org/Members/Bill/Documentation/CatalogBadness Bill -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
Bill Anderson wrote:
Itamar Shtull-Trauring wrote:
......
This is in part because of unindex's EXTREMELY annoying behavior when you call it on uncataloged objects.
Unindex should simply *return* an error message if its called when the the object is already uncataloged - raising an error is very annoying in a lot of cases. It makes a lot more sense, too - at the end of the unidex I want the object to be removed form the catalog. Since it alreasy isn't in the catalog, unindex should just do nothing, not raise an exception!
This sould solve lots of problems I've had (I always change manage_beforeDelete in CatalogAware to do "try: self.unindex" to work around this), and for a lot of other people too.
FWIW, I have a short how-to on deleting uncatalogued objects that refuse to be deleted normally: http://www.zope.org/Members/Bill/Documentation/CatalogBadness
I just undid everything.. Thanks everybody, David
Bill
participants (3)
-
Bill Anderson -
David Kankiewicz -
Itamar Shtull-Trauring