feature request #7932
Updated by Andreas Müller over 2 years ago
Finding the best matching preference for preferences with same predicates but differing subjects is currently not yet implemented or only limited for subjects with taxonomic subtree preferences. As handling preferences in application has shown that there is a need for caching preferences it is preferred to implement a best matching subject resolver that is DB independent. This creates difficulties for tree filters like the taxonomic subtree filter where the subject may include the subtree uuid or the tree index. Using the subtree uuid is easier to maintain but requires on the fly creation of the tree index because only with the tree index one may be able to decide if a taxon is included or not. Using the tree index as part of the subject avoids this problem but is more difficult to maintain if a taxon node is moved or if it's higher taxonomy changes. There are multiple possibilities to implement resolving 1. easiest: all matching subjects must completely be included in the query subject, the longest subject winns 2. middle: all parts of a matching subject must be in the query subject in the same order, but the query subject may include additional parts, not only at the end but also in the middle; for finding the best matching we start from the back, if the last part exists it is the best matching otherwise call recusively with the query subject shortened by the last part 3. general: to match the query subject all parts of the subject must also be parts in the query subject **no no matter which order**; order; finding the best matching works like in 2), the query subject is read from behind and whenever a subject includes the last part read it winns, otherwise start recursively