search for "dynamic" calculated attribute's value (bdb_equality_candidates: not indexed)

[Daniel <deepee@gmx.net>]

Hi slapd-Gurus out there,

using the search filter "(test=TRUE)" results in: "candidates not 
indexed". The cause for the below slapd trace output seems clear to me: 
In fact there is no entry in my bdb backend existing with an attribute 
description "test" present...

=> bdb_filter_candidates
       EQUALITY
=> bdb_equality_candidates (test)
<= bdb_equality_candidates: (test) not indexed
<= bdb_filter_candidates: id=-1 first=1 last=430
<= bdb_list_candidates: id=-1 first=1 last=430
<= bdb_filter_candidates: id=-1 first=1 last=430
<= bdb_list_candidates: id=25 first=141 last=430
<= bdb_filter_candidates: id=25 first=141 last=430
bdb_search_candidates: id=25 first=141 last=430
=> test_filter
   EQUALITY
=> access_allowed: search access to "dc=foo,dc=bar" "test" requested
<= root access granted
=> access_allowed: search access granted by manage(=mwrscxd)
<= test_filter 5
bdb_search: 141 does not match filter


In regard to the above slapd-trace I've the following question:
Could someone please be so kind and tell me whether there exists a 
possibility to search (filter) for "dynamic" (calculated) attribute 
values, that do not get stored in a backend (in my case bdb)? Idea: An 
overlay should calculate a dynamic attribute's value based on already 
existing attribute values of an entry each time this dynamic attribute 
is searched for using a filter-statement, e.g. 
'(&(dynamic-attr-name=xyz)(|((...)(...))...)...)'.

First of all I had a quick look into slapo-collect's sources. The 
collective attributes seem to be added dynamically to an entry but the 
collected attributes are not "filterable". I think the reason is that 
slapo-collect operates on the response/slapreply and that's to late in 
the overlay's processing queue...

Then I thought of something similar to the operational attribute 
"hasSubordinates" - this attribute's value is filterable and seems (at 
least sounds) to be dynamically evaluated. On the other hand I'm not 
sure whether "hasSuborinates" is dynamically calculated each time an 
entry get's searched or accessed. Perhabs the value of "hasSubordinates" 
is only be calculated in case the entrys' childrens get modified and 
(thus seldomly) updated within the backend, which could be the reason to 
be search- and filterable?!

Last but not least I tried to implement a small test-overlay using a 
custom search-callback that updates the dynamic "test" attribute within 
the bdb-backend: Imagine an (very simple/stupid) overlay that for 
example set a custom attribute named "test" to "TRUE" in case an entry's 
attributes "givenName" and "sn" both contain at least one value. ;-) I 
know, that the filter "(&(givenName=*)(sn=*))" would do the trick but 
the example is just a simple scenario for me to step into 
overlay-processing details.

If I use attr_merge() within the search-callback to store the dynamic 
test attribute's value "TRUE" or "FALSE" within the entry the search 
succeeds without problems - I mean the filter (test=TRUE) get's 
processed ok.

So my questions still left is:
Do I always have to store/update the dynamic attribute's calculation 
result value within each entry (in the backend) or is there another 
posibility that allows filtering for the calculated attribute's value, 
while getting rid of the store and update overhead within the backend?

Hopefully this is no hen egg problem concerning the internal processing 
order of filters, candidates, entries, etc.

Many thanks for your advice!

Kind regards
Daniel