Hi,
There are many people knowing the ZCatalog better than I do, but at least we can try to get the ball rolling ;).
That's great. And thanks.
** Every entry in the built-in ZCatalog should be unique. No duplicates!**
The question here is unique with respect to what?
Being unique in every aspect...site-wde uniqueness, etc. I didn't think that'd be ambigous ;-)
In short, can I catalog objects using acquisition-safe unique keys, say their oid's or auto-generated md5 hash or something?
I can't follow you here, because above you said that that you want to implement that "Accessing it via "/dir2/obj1" or "/dir2/dir1/obj1" duplicates the catalog entry with with a different uid."
This isn't acquisition safe.
I must have been really ambiguous in making myself understood. This is exactly what I **don't** need, and it's why objects being catalogged are **not** acquisition-safe. I just tried to demonstrate **what shouldn't be happening**. <snip snip>
Here is where there seems to be a misunderstanding, at least as far *I* understand the ZCatalog:
I do think so ;-)
It's up to the object to pass an uid to the Catalog if he/she wants, and the decision what to use for the uid is up to the programmer who implements that (i.e. it's not a (Z)Catalog implementation problem). All cases that I have seen in stock zope/CMF are using getPhysicalPath() for that, and this is also the default if no uid is passed. Therefore I can't see how your example with the news item could happen. CMFCatalogAware shouldn't do this, and I couldn't reproduce this with a custom type of mine, which uses CMFCatalogAware like NewsItems do AFAIK. Additionally getPhysicalPath() is also the answer to your acquisition-safe unique key, because it accomplishs exactly that, acquisition safe and zope-wide uniqueness. It also doesn't take vhms or the hostname into account, so I really can't see what happens there.
That's weird. ( Just take a step back and see things as if they were when your were also a newbie to Zope and stuff ;-) I tried a unique key myself, but didn't work with the getPath() or getURL() methods of the brain objects a search operations returns. And that very getPhysicalPath() call returns a different url when you access an object via acquisition in my case: CMF 1.3.1. That's why I came under the impression that the getPhyicalPath() doesn't return a unique path with VHM or when an object is accessed via acquisition. As per VHM, I have the following setup, for example: /root/Zoper - translates into www.zoper.net When you create an object in http://www.zoper.net, you get a catalog entry, say "a_news_item" with a uid "/Zoper/a_news_item". If you edit this item via http://www.zoper.net/Zoper, you get a duplicate with the uid "/Zoper/Zoper/a_news_item". Here goes even funnier situation: when you visit this item and edit it via "http://www.zoper.net/Zoper/Zoper/Zoper", you'd get a catalog entry, "/Zoper/Zoper/Zoper/Zoper/a_news_item". This is what's happening with my CMF site's portal catalog: CMF 1.3.1 with Plone 1.0.1 ( Zope 2.6.1 ) I haven't done anything myself to this catalog.
Another question, when you say you do _index_ your read count, do you mean storing it as meta_data in the catalog?
No. There's a method called getNeoPortalContentReadCount() common to all the objects my applications create that does the job when indexing an object, not a metadata entry.
cheers, oliver
I appreciate your feedback^^ It's so hard to get any replires to my dumb questions these days...sigh :) Best regards, Wankuyu Choi --------------------------------------------------------------- Wankyu Choi CEO/President NeoQuest Communications, Inc. http://www.zoper.net http://www.neoboard.net ---------------------------------------------------------------