directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [DN] Serilaizing DN in the backend
Date Tue, 19 Feb 2008 18:24:25 GMT
Alex Karasulu wrote:
> On Feb 19, 2008 6:14 AM, Emmanuel Lecharny <elecharny@gmail.com 
> <mailto:elecharny@gmail.com>> wrote:
>
>     I don't think that upDn is usefull.
>
>
> You mean in the context of [de]serializing?
In the server as a whole.
>  
>
>
>     Note : why is upDn index useless ? Because if we store a serialized
>     LdapDN, then we have access to the UP form, and more than that, w will
>     always work with normalized forms of DN, 
>
>
> Not always true.  Sometimes we have use the user-provided (UP) form of 
> a DN but very rarely. 
You always have access to this form, if needed, as this is the DN basic 
form (remember that DN are passed by incoming requests). So no need to 
have an index on it.
> Also the LdapDN is an atrocity when it comes to manageability.
Can you elaborate ?
> We may break it up in the future and break it apart so it does not 
> contain both UP and normalized forms. 
You may want to have a stripped form of the current LdapDN ( a 'client' 
form), but in fact, you already have it : simply use LdapDN as is, and 
you are done (you won't see any kind of normalized form unless you 
explicitely ask for a normalization to be done). Maybe having a better 
separation, like in ServerEntry and ClientEntry could be a good idea. 
Also keep in mind that in the server, the DN is the most important 
structure with the ServerEntry. It is also the most costly object to 
manipulate, and it can kill the performances if not handled correctly.
> This is causing issues for us as an API when users don't know what 
> kind of DN they're dealing with.
This is simply not true. What you call 'user' here is simply always 
managing the UP form, nothing else. To get a normalized form, you must 
be into the server, or at least, have access to the OID registry, and 
explicitely call the normalize( OIDs ) method.
>
> You are right though that some things about UP DN in the server 
> definitely need to change.  I just don't want anyone (including me) to 
> touch anything associated with it until we have a clear idea of the 
> end state of DN normalization.
>
> I don't want to be in constant flux refactoring this server.
We have to be consistent. The current situation is not good. We have 
open issues because we don't know which form we have to use (normalized 
or UP). For instance, the Principal.

So far, 99% of the DN are used normalized - as it should - inside the 
server, and I'm not even sure we use the UP form in any case (so the 1% 
may be patholological cases).
>
>     returning the UP form only when
>     building the respons, which is easy, as we store the UP form into the
>     seralized DN. This will also benefit to the Add request, as we won't
>     have to uodate 2 index instead of one...
>
>     wdyt ?
>
>
> I worry that now we're going to store both the UP and normalized DN.  
> Perhaps this is better since disk is cheap and the normalization 
> computation is costing us.  However we talked about making this 
> configurable at some point: can we still do that?
The cost should be compensated by the normalizing gain. Here, there are 
some key factors : size on disk and memory. If we have enough cache, 
size is irrelevant. If we don't have enough cache, reading DN from disk 
might be costly.  Hopefully, we can decide to store the UP form and 
compute back the normalized form when restoring the DN. This operation 
(normalization) is less costly than the parsing. This is something we 
can trigger if needed, but I don't think this is urgent, unless we 
really want to manage millions of DNs right now :)

I have also tried to improve the serialization so that we don't save a 
UP and normalized value if they are equals. That come at a cost, and 
it's not perfect.

I still have to go deeper, regarding the UP index.

-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message