[389-devel] plugin PRE_ENTRY_FN scope
Deas, Jim
James.Deas at warnerbros.com
Fri Jan 17 19:02:33 UTC 2014
Rich,
Thanks so much!
Are you suggesting I do an internal search in PRE_SARCH_FN then use the return to modify the original search request to include additional items before allowing the original client search to begin?
-----Original Message-----
From: 389-devel-bounces at lists.fedoraproject.org [mailto:389-devel-bounces at lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Friday, January 17, 2014 10:32 AM
To: 389 Directory server developer discussion.
Subject: Re: [389-devel] plugin PRE_ENTRY_FN scope
On 01/17/2014 11:20 AM, Deas, Jim wrote:
> Should I be able to use SLAPI_SEARCH_ATTR to view attributes about to be returned to the client in PRE_ENTRY_FN?
Yes, looks like it, but you have to be prepared for the case where a client does not specify a search attribute list - in this case, the client is asking for all non-operational attributes in the entry.
> Can I start a new search inside PRE_ENTRY_FN to find values needed to augment the existing attributes being returned?
Yes, that should work. However, doing this parsing and internal search for every single entry returned might be a big performance hit. You might want to examine the SLAPI_SEARCH_ATTRS and do the internal search in a SLAPI_PLUGIN_PRE_SEARCH_FN, then store the results in the operation (in an operation extension), then just use those results in your PRE_ENTRY_FN. This is what the deref plugin does.
>
> --
> 389-devel mailing list
> 389-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
More information about the 389-devel
mailing list