[Zope3-dev] Sprintathon: searching?

[kapil thangavelu]

On Tuesday 05 November 2002 08:51 am, Guido van Rossum wrote:
> [kapil]
>
> > i've had deal to with with the issues janko's raised as relates to
> > the cmf and compound documents and content versioning, though i
> > admit i didn't attempt to use separate indexes for a solution, still
> > its probably good material for the use cases.  ie a composite
> > document composed of individually managed pieces with separate
> > workflow which are only visible within the container document
> > (including non-visibility in catalog searches), so the search
> > results for the same document vary according to user roles. with
> > content versioning (using zope version control), a document would go
> > from a published state to an editable state (taking a snapshot of
> > the content before it leaves the published state), while still
> > leaving only the published version searchable and viewable to non
> > authorized users.
> >
> > on a general level its fairly common in the cmf, ie varying search
> > results by user based on roles as content often changes visibility
> > via security manipulation. the cmf does it via constructing an
> > object wrapper that indexes security info as well, and doing an
> > implicit addition of the query terms for the current user's
> > security, which works well when you look at a content object as a
> > discrete entity.
>
> Is it really necessary to vary the search results by role and by ZODB
> version?

the version system i was referencing are *not* zodb versions, which i consider 
in short, evil. the versioning system i'm referring to 

 http://cvs.zope.org/Products/ZopeVersionControl

is more of a bookeeping system for object pickles with semantics similiar to 
cvs. it works at the application level. 

in that context, i think the answer to security and version question is that 
its likely a workflow/business logic decision and ideally the logic for such 
can be pushed down to the workflow level. i really just wanted to highlight a 
class of use cases that arise when the object is no longer the unit of 
indexing, but is instead a reference to different objects (possibly including 
itself)

i think an adapter approach can definitely solve this issue for indexing, but 
i think storage and searching might be more problematic without some 
infrastructure support. to restate one of the use cases above, which i think 
is a good example. 

a document with workflow defining draft, published, and revision states. with 
a linear transition through those states, and a transition from revision to 
published. when content is in the revision state, the published state should 
still be visible and searchable to all users, while in the revision state the 
last published version should be visible and searchable to non-privileged 
users, while the editable version should be searchable and visible to 
privliged users (editors for examples).

>  For varying by role, perhaps separate indexes should be
> used; but I'm not sure I understand the use case: I'd expect if there
> are non-public documents, there'd be a small enough number of them
> that you don't really need a full-text search to find them. But maybe
> I don't understand the use case well enough. 

imo, thats an unreasonable assumption about the application domain. for 
example think of a subscription based site where subscribers have access to 
additional content which non-subscribers should not see. additionally a 
common z2 pattern is to use the catalog as a mechanism for implementing 
additonal application logic, such as workflow or relationships, so editing an 
object and not updating the index is not always a viable option. otoh, in z3 
its likely some of these catalog responsiblities will get split out to things 
like the relationship manager, and other hub subscribers. 

> ZODB versions are
> generally not recommended

(quoting myself from http://www.zope.org/Members/k_vertigo/Stories/TeamZope),

They are a database level feature masquerading as an application tool.

and they've got some fine print ;-)

> (in fact I'd recommend to take them out of
> ZODB4; this would make for a significant reduction in instability and
> code size I expect).

i'd be happy to see them go the way of the dodo

cheers,

kapil