[ZCM] [ZC] 608/ 9 Defer "VHM and ZCatalog absolute paths"

Collector: Zope Bugs, Features, and Patches ... zope-coders-admin at zope.org
Fri Dec 3 06:49:09 EST 2004


Issue #608 Update (Defer) "VHM and ZCatalog absolute paths"
 Status Deferred, Catalog/bug medium
To followup, visit:
  http://collector.zope.org/Zope/608

==============================================================
= Defer - Entry #9 by regebro on Dec 3, 2004 6:49 am

 Status: Accepted => Deferred

After discussion with Tino, we both think this is not an issue. I give it back to chrisw and defer it.
________________________________________
= Assign - Entry #8 by regebro on Dec 2, 2004 10:48 am

 Supporters removed: regebro

I'm removing my assignment, since I can't se an issue. :)

1. Yes, it should be the absolute physical path. AFAIK it is.

2. Path indexes should index the path you give them. If you give them the physical path, that's what it should index. If you give it a virtual path, thats' what it should index. AFAIK, this is also the case at the moment.

Most of the time you use a path index to be able to restrict a search on a folder. If you do that with relative paths you are gonna shoot yourself in the foot sooner or later, but shooting yourself in the foot should be allowed. Just optional. :) I can't think of a case where you want a path index to index a relative path, but I see no reason not to allow it.

So, I can't see an issue here, and recommend closing. 
________________________________________
= Comment - Entry #7 by tino on Nov 26, 2004 7:28 am

Well I see 2 different issues here:

1) id of object
   I think this should be really the object path (physical)
   otoh, if the structure is mounted elsewhere (shared resources)
   would a catalog relative path make sense?

2) path index
   This could depend on virtual hosting - especially if you add
   /catalog an object from different vhost.
   Users would expect a clean path on searches of this index
   
   No idea how to accomplish this.


________________________________________
= Assign - Entry #6 by chrisw on Nov 26, 2004 7:05 am

 Status: Deferred => Accepted

 Supporters added: tino

Tino did some good analysis on this, I'm assigning it to him so he can have a look.
________________________________________
= Defer - Entry #5 by regebro on Nov 15, 2004 5:39 am

 Status: Accepted => Deferred

No response -> Deferred. This is probably solved in 2.6, and will soon be closed unless the error can be replicated in 2.7 or 2.8.
________________________________________
= Comment - Entry #4 by regebro on Nov 9, 2004 12:17 pm

I've now tried to reproduce this problem, and I can't. Can you confirm that this is still a problem with 2.7?
________________________________________
= Accept - Entry #3 by regebro on Jan 17, 2003 8:47 am

 Status: Pending => Accepted

 Supporters added: regebro

Milos Prudek confirmed in a private letter that's it's the object id that is different depending on which method is used. I agree that this is a bug, and I think that the unique ID of the entry always should be the absolute physical path to the object, with or without virtual hosts.


________________________________________
= Comment - Entry #2 by regebro on Jan 17, 2003 6:23 am

This depends on what is ment with "object paths". Is it the UID path, or indexed absolute_path, or???
________________________________________
= Request - Entry #1 by Anonymous User on Oct 4, 2002 3:44 am

CatalogPathAware works very well for ZClasses under Virtual Host Monster. Object paths do not include the folder that VHM points to, if <dtml-call reindex_object> is used when creating the ZClass instance. Also when changing ZClass instance properties and running <dtml-call reindex_object>, object paths are ok.

But when ZMI is used to mass-catalog (Find Objects tab, Advanced/Update Catalog tab), the folder is always added. Objects in the catalog have ABSOLUTE paths, i.e. paths which include the container folder which should be hidden by VHM. This is IMHO incorrect.
==============================================================



More information about the Zope-Collector-Monitor mailing list