----- "Daniel" deepee@gmx.net wrote:
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.
Using dynamically computed attrs in a search filter and pretending it to ber indexed is an oxymoron. If you intend to allow it, you need to be prepared to intercepting the search operation and doing the candidate collection yourself. I don't recall any overlay or so that does it and that could be used as an example, simply because it makes little sense. In any case, the problem can be solved, but the solution may not be trivial and require a fair amount of coding.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati wrote:
----- "Daniel" <gmx.net> wrote:
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)(|((...)(...))...)...)'.
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 and egg problem concerning the internal processing order of filters, candidates, entries, etc.
Using dynamically computed attrs in a search filter and pretending it to ber indexed is an oxymoron. If you intend to allow it, you need to be prepared to intercepting the search operation and doing the candidate collection yourself. I don't recall any overlay or so that does it and that could be used as an example, simply because it makes little sense. In any case, the problem can be solved, but the solution may not be trivial and require a fair amount of coding.
Thank you Pierangelo for your answer.
Just for the clarification: Sorry for my confusing first posting but I don't want to index dynamic attributes' values - at least not at the moment - hehe. ;-)
The "...candidates: not indexed..." was just some kind of symptom I've noticed first during search queries using "non in-backend-stored attributes" in an filter expression. This has led me to my personal (might be wrong?) assumption that dynamic attribute values at least have to be stored within an entry in the backend (whether indexed or not) to be used and recognized by search filters. Is this assumption [ ] correct [ ] total b...s... [ ] in-between, e.g. it is (or should be) possible to search for dynamic attr values regardless whether they are kept in the backend or not <please fill in some more details here if you like>
Could you or someone else on the list please explain to me how "hasSubordinates" work (not in detail just in principle)? Is its boolean value calculated each time this operational attribute is accessed (+) and/or searched (filter expression)? Or is the attribute's value stored in the backend and only gets updated on changes to an entry's children?
Thanks a lot for your answers and your patience!
Best regards Daniel
Could you or someone else on the list please explain to me how "hasSubordinates" work (not in detail just in principle)? Is its boolean value calculated each time this operational attribute is accessed (+) and/or searched (filter expression)? Or is the attribute's value stored in the backend and only gets updated on changes to an entry's children?
It's dealt with specially, and only honored by those backends that have a structural knowledge of its value. In fact, back-bdb and others do have primitives to search for immediate subordinate entries of an entry, because they need to know about them. In this case, both searching for values of that attr, and filling its value, is straightforward. I wouldn't take it as an example of a dynamically generated attr, though.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
openldap-technical@openldap.org