masarati@aero.polimi.it wrote:
I wonder, in the spirit of further improving pcache:
I think this should be a separate ITS.
Well, based on your response, it seems not to deserve an ITS at all :)
- support compare, in case a cached query has the entry to be compared,
and the asserted attr is in the corresponding attrset?
Right now we have no convenient way to map a DN to a cached query.
We have: a cached entry contains the pcacheQueryID, which solves the problem.
I guess we could answer if the entry was already retrieved by some other query, but we can't tell what the queryID is without first retrieving the entry.
Correct.
If the entry doesn't exist locally, we have no way to map the request to a query template, so we can't cache that result at all.
I was not concerned with *caching* the result of compare, but with exploiting cached entries to answer compares without contacting the remote server.
It seems to me that apps that do Compares on a set of entries do that to avoid Searching and retrieving the entire entry, so in practice the intersection of (entries cached by searching) and (entries we want to compare on) will be empty.
:)
- exploit modifications to invalidate queries whose results are altered?
It'd be easy for deletes (check if present, and eventually remove the entry). An easy shortcut for modify/rename would be to just invalidate queries affecting the modified entry (I'd prefer this to mimic modifications to local data, which would also guarantee that remote server ACLs have been applied). Adds would be a little bit tricky (try all cached queries on the new entry (base, scope, filter; in case of match, invalidate them, so that the remote server can apply ACLs).
This may be a moot point, as usually cached proxies are essentially read-only, but in case...
So far no one has asked for this functionality, thankfully.
We can retrieve an entry and read its queryID but we don't currently have an easy way to look up the ID to get the CachedQuery info.
This is all already in place as the PCACHE_EXOP_QUERY_DELETE.
(I guess we can put them all into an AVL tree for the purpose.) That would make Deletes easy enough I guess. For Modify/Rename, if you invalidate a query do you then delete all of the cached entries for that query? That could result in a lot of write traffic for a single change.
pcache is probably based on the assumption that clients only perform search (and now, bind) operations, so it's a moot point anyway.
Or do you just leave the cached entries alone, and destroy the CachedQuery structures? Then the entries will simply have queryIDs that reference nonexistent queries.
Yeah, Adds could result in a lot of invalidations too, with the same question about dangling queryIDs.
Codewise, it's a matter of just calling pcache_remove_entry_queries_from_cache() for the request DN, if the modification succeeds. Performance and load-wise, it might not be worth, I concur.
p.