Univention Bugzilla – Bug 54119
Add a "reverse" cache option
Last modified: 2021-11-24 16:41:16 CET
The offline cache supports creating key/value pairs with a unique key as key and an arbitrary value. Sometimes you need to ask for the value: Who has set this value? In order to do this efficiently, you want to reverse the database: Store the value and point to a list of keys. Example: add-cache db1 entryUUID univentionMailHomeServer => 1. xxxx-... -> example.de 2. yyyy-... -> example.de add-cache db2 entryUUID univentionMailHomeServer --reverse => 1. example.de -> [xxxx-..., yyyy-...]
Package: univention-group-membership-cache Version: 1.0.0-9A~4.4.0.202111230209 Branch: ucs_4.4-0 Scope: errata4.4-8 univention-group-membership-cache.yaml bb83aeddcc88 | Bug #54119: YAML univention-group-membership-cache (1.0.0-9) a769c8b07581 | Bug #54119: Typo in list output univention-group-membership-cache (1.0.0-8) f5ca3ead3de3 | Bug #54119: Add reverse caches ucs-test (9.0.7-79) 79227bc4e8c8 | Bug #54119: Test reverse cache Added a new option: /usr/share/univention-group-membership-cache/univention-ldap-cache add-cache ... --reverse GDBM does not free disk space automatically, so we added a "reorganize()" call in several places. The reverse cache deletes and overwrites a lot of keys. If the value (which is the key in the reverse cache) is used very often (say 100.000 times in an environment with > 100.000 objects), the cache is very inefficient when writing. This is because of the serialization that has to be made in GDBM. We may want to reconsider switching to LMDB at some point.
What I tested: Adding removing,functionality of reverse cache: OK reorganizing cache: OK (every 1000 operations seems a little often to me?) test: OK (some issues with on samba4 machines I adjusted them accordingly) permissions after cleanup: OK works in office365 app: OK yaml: OK Verified
<https://errata.software-univention.de/#/?erratum=4.4x1102>