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

Re: Normalized DN (Was: Re: commit: ldap/servers/slapd acl.c slap.h value.c)

I've been thinking of extending the Attribute structure to
hold both "presented" and "normalized" values.  I've been
think it is likely less work to pre-compute all the normalized
values (as entries are read from disk/provided by user) then
to do caching on the fly.  Also avoid nasty locking issues
and makes it possible to do one per entry allocation instead
per attribute allocations.  Of course, we could store both
"presented" and "normalized" values on disk... but that would
effectively double the size of id2entry (which may not be
all that bad).

Before any change of this kind is actually committed, I would
prefer to see some analysis (e.g. benchmarking) that should
it "added value".


At 09:31 AM 2002-12-04, Pierangelo Masarati wrote:
>> Log Message:
>> Added SLAP_MR_VALUE_NORMALIZED_MATCH, avoid redundant normalize when
>> calling value_find with already-normalized DNs
>Good catch; however, I'd like to move around some DN structure
>that contains pretty, normalized, and decomposed DNs, which are
>computed as soon as they are required but not sooner, and used
>as are if already available.  I think this would really be a plus,
>although it would require to rewrite nearly every single piece
>of code :(
>Pierangelo Masarati