...is bad :(
Because Catalog stores objects not by reference but by the path to where
they are, if you move those objects, you'll start getting lots of
'Uncatalog of absent id' errors and your search results will point to
objects that don't exist.
And ideas/comments?
cheers,
Chris
Terry Kerr wrote:
how are you moving them?
catalogAware objects unindex themselves when deleted then reindex
themselves if pasted somewhere.
The objects aren't catalogAware..
Chris
___
Zope maillist - [EMAIL PROTECTED]
then as far as i know there is no way around the problem? anyone else
have comment?
i think that is the whole point of making objects catalogAware.
Chris Withers wrote:
Terry Kerr wrote:
how are you moving them?
catalogAware objects unindex themselves when deleted then reindex
Whilst in agreement with Chris I would like to throw another situation in
here that CatalogAware doesn't cater for.
If you change a folder name, somewhere higher in the tree, then all the
cataloged objects references are incorrect.
I think this is the same problem that Chris mentioned but a
Terry Kerr wrote:
i think that is the whole point of making objects catalogAware.
But catalogAware doesn't support subtransactions. It also doesn't handle
indirect deleting and several other conditions IIRC..
Also, in this particular case, the ZCatalog is a Squishdot Site and the
obejcts are
Andy Dawkins wrote:
Whilst in agreement with Chris I would like to throw another situation in
here that CatalogAware doesn't cater for.
If you change a folder name, somewhere higher in the tree, then all the
cataloged objects references are incorrect.
I think this is the same problem
