[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: dynamic groups

MichaÅ SzulczyÅski wrote: 
Hello,

My name is MichaÅ SzulczyÅski, and I'm a student at Warszawska WyÅsza
SzkoÅa Informatyki in Poland. I'm on a practice at the company where
Aleksander Adamowski works.
As he said, I will try to implement dynamic list member 'caching'. The
general idea is to "materialize" the member attribute of the dynamic
group using existing static attribute values infrastructure (including
indexes) and update them automatically when there is a
add/modify/modrdn/delete operation on an object that matches the dynlist
memberURL filter. 

The operation of dynlist overlay would be identical as it is now without
specifying an additional dynlist configuration option.

It is not clear from your description whether you plan to simply replace dynamic grouping (dynamically listing member DNs within a dynamic group entry) or dynamically listing any type of attribute. The dynlist overlay right now does both, but I think the feature you're considering only makes sense for the first case.

I suggest that for the duration of the development you branch your overlay into something other than dynlist (call it rdynlist, for really dynamic list?). When you get to something stable and performing better than dynlist (with "better" I don't barely mean performances, but also functionality, in your case including consistency), we could decide whether to move it back to dynlist or leave it alone and, in case, drop dynlist itself.

The plan is to, depending on the additional, optional dynlist-attrset
configuration parameter, grab the dynamic list entries for that dynlist
configuration from the database, and put them into a memory-resident
list (which would hold all the dynamic groups that we are interested in,
ie. the ones with the additional configuration option set). When there is a add/mod/modrdn/delete operation on any entry, we would
check this list for a matching dynlist filter, and add/modify/delete the
member attribute of the dynamic list for that entry. Much like a static
group, but with automated addition/deletion to/from it, effectively
making it a dynamic group. Manual updates to the member attribute would
be prevented and would raise an error. 

First, in addition to dynlist_info_t we would need to hold the pointer
to our memory-resident dynamic group list per dynlist overlay instance.
That's for speed optimization, since searching for all dynamic lists on
each update operation would have a huge performance impact.

Not sure what do you mean by "dynamic group list" here. In any case, the Operation->o_bd->bd_info->on_bi.bi_private is supposed to be read-only, as it is shared among threads. If you need to modify any data in there you need to protect it from concurrency.

As we can only hold only one backend-specific config data in
Operation->o_bd->bd_info->on_bi.bi_private, we wold need to hold both
pointers (dynlist_info_t and the pointer to our list) in an additional
struct, and store that. But this method would mean changing much of the
existing codebase, and I don't know if that would be good.
If there would be another place where we could store the pointer to the
dynamic group list, that would be better.

Second, I would like to know if there is a function to test whether one
DN is contained in another DN (i.e. one DN is a descendant to another
DN).


dnIsSuffix(), provided both DNs are normalized.

I need this to compare the base DN of the dynamic group, and the
added/modified/deleted/modrdn'ed entry (eg: if the entry DN
<uid=test,l=City,ou=People,o=MyOrg> is in the dynamic group's member
URL's base DN <ou=People,o=MyOrg>). I think that comparing the
normalized DN's stringwise backwards from the strings' end would work,
but I'm not sure.

Third:
* can we do an add-or-replace with BackendDB->be_modify

what is an "add-or-replace"? If you mean the ldap modify operation type, LDAP_MOD_ADD adds the value(s), unless it (any of them) already exist(s) (in this case the return code will be LDAP_TYPE_OR_VALUE_EXISTS). The LDAP_MOD_REPLACE replaces all existing values with the provided ones. If what you need to do is add a value unless it already exists, you can set the o_permissive_modify flag, so that LDAP_MOD_ADD on existing values are ignored.

* when doing a LDAP_MOD_DELETE on a single attribute's value can we
ignore a case where that attribute value does not exist in the entry (so
we can avoid checking for its presence and save an unnecessary read
operation)?

Yes: you perform an internal LDAP_MOD_DELETE, and ignore the return code LDAP_NO_SUCH_ATTRIBUTE.

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
Email:   pierangelo.masarati@sys-net.it
---------------------------------------