masarati@aero.polimi.it wrote:
I wonder, in the spirit of further improving pcache:
I think this should be a separate ITS.
- 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. 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. 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. 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. (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. 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.