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