This is mostly a question for AJ, but any input would be great. This bug bit
me today and is documented here:

I dont understand the brief argument against this one, it would make sense
to me to able to pull an object out of the catalog based on its path. For
example if I want /foo/bar/blammo, currently this means there is only one
way of pulling the an object of the catalog given this path. Thats to send
(path='/foo/bar', id='blammo'), rather than (path='/foo/bar/blammo'). Why
wouldnt we want it this way?

One thing I have done is store a whole bunch of references to objects as
selected by the user. These are essentially random objects and the quickest
way is to pull them back out of the catalog. Of course I cant do more than
one object per query (unless Im missing some other way) Id love to do
(path=['/foo/bar/blammo', '/foo/bar/blammoz']) and get these 2 objects... I
think that would be neat.

It would seem data_record_id_ is not guaranteed to permanent after a
reindex_object (which CatalogAwareness uses), since this uncatalog and then
recatalogs the object. If this did work it would be cool and I could undo
all the changes to my app back again.

- The patch is already there, so Im curious why do we have what seems to be
a more limited design?
- Would a halfway option such as path_match='final' be a choice that wont
break any code but would confuse everyone and not make into the
- Is it just a matter of fixing reindex_object as was suggested on #zope so
that data_record_id_ is more permanent?

  Andy McKay
  Agmweb Consulting

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to