Subject: Re: Another Persistent Search question

From: Gordon Good <[email-masked]>
Date: Fri, 02 Feb 2001 11:50:40 -0800

In the Netscape implementation, I'm fairly sure that an entry is only returned to the client if it matched the query after mods were applied.

So, for example, if the psearch used a filter of "foo=bar" and the modification changes the "foo" attribute from "bar" to "baz" then no entry would be returned.

However, for the delete operation, the entry that was deleted is returned.

To summarize:
If optype is ADD, a result is returned to the client iff the new entry matches the psearch criteria
If optype is MODIFY, a result is returned to the client iff the entry matches the psearch criteria after modifications have been applied
If optype is DELETE, a result is returned to the client iff the entry matches the psearch criteria prior to removal
If optype is MODRDN, a result is returned to the client iff the entry matches the psearch criteria after being renamed

That's from memory, but I'm pretty certain it reflects reality.

There's an inconsistency there: you can detect when an entry leaves the result set for delete operations, but not for modify or modrdn operations. I'm not sure it's worth fixing that in the psearch document, but it should definitely be addressed by the LCUP work (and I'll bet LCUP addresses this already).

-Gordon

Jim Sermersheim wrote:

> It's not clear whether or not entries are returned that do not match the search criteria. Most confusing is 4.c. It says that:
> As changes are made to the server, the effected entries MUST be
> returned to the client if they match the standard search cri-
> teria and if the operation that caused the change is included in
> the changeTypes field.  The changeTypes field is the logical OR
> of one or more of these values: add (1), delete (2), modify (4),
> modDN (8)."
>
> If an entry was deleted, it no longer matches the search criteria. I believe the intent of the authors here is to have that entry returned.
>
> If an entry is modified or renamed, it may cause it to leave the original result set of the search criteria. I don't know whether or not the authors intended these entries to be returned. If they are returned, there are cases that would be difficult for the client to determine if the entry still belongs in the result set.
>
> Can someone clear this up?
>
> Thanks. Jim

---

From: Mark Smith <[email-masked]>
Date: Fri, 02 Feb 2001 15:44:04 -0500

Gordon Good wrote:
> 
> In the Netscape implementation, I'm fairly sure that an entry is only returned
> to the client if it matched the query after mods were applied.
> 
> So, for example, if the psearch used a filter of "foo=bar" and the modification
> changes the "foo" attribute from "bar" to "baz" then no entry would be returned.
> 

Yes, I agree.  This should be documented in the psearch document so
people who choose to use it or implement it do so the same way.  I will
add this to the psearch draft soon.

> 
> There's an inconsistency there: you can detect when an entry leaves the result
> set for delete operations, but not for modify or modrdn operations. I'm not sure
> it's worth fixing that in the psearch document, but it should definitely be
> addressed by the LCUP work (and I'll bet LCUP addresses this already).

It is being looked at.  See section 5.1 of
http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcup-02.txt

-- 
Mark Smith
Directory Product Development / Netscape