Re: DN serialization issues

2011-02-18 Thread Alex Karasulu
On Fri, Feb 18, 2011 at 8:17 PM, Emmanuel Lecharny wrote:

> Hi guys,
>
> once upon a time, in order to improve the server permformance, the DN was
> serialized with its normalized value. This was to avoid a costly
> normalization when we pull back the DN from the backend. But now that we
> don't store anymore the DN into the entry, it does not make any sense to
> store the normalized DN.
>
> We should get rid of that.
>
>
+1



> Another problem is that the LogManager also serialize entries with a full
> DN on the disk, and when it reads them back, it should be able to inject the
> schemaManager into the DN, which is not done.
>
> All in all, the DnSerializer has nothing to do in the Ldap-API. It's a
> Server thingy, as is the EntrySerializer. Moreover, the DefaultEntry
> implements the Externalizable interface, but does also provides
> serialize()/deserialize() methods, which export the RDN, not the DN, simply
> because it's used only by the server.
>
> This is a mess...


Separating out the implementations might help decouple these server side
ONLY concerns. But I don't know how I feel about having to have a ServerDn
verses a regular Dn.

WDYT?

Alex


Re: DN serialization issues

2011-02-18 Thread Emmanuel Lécharny

On 2/19/11 12:24 AM, Alex Karasulu wrote:

On Fri, Feb 18, 2011 at 8:17 PM, Emmanuel Lecharnywrote:


Hi guys,

once upon a time, in order to improve the server permformance, the DN was
serialized with its normalized value. This was to avoid a costly
normalization when we pull back the DN from the backend. But now that we
don't store anymore the DN into the entry, it does not make any sense to
store the normalized DN.

We should get rid of that.



+1




Another problem is that the LogManager also serialize entries with a full
DN on the disk, and when it reads them back, it should be able to inject the
schemaManager into the DN, which is not done.

All in all, the DnSerializer has nothing to do in the Ldap-API. It's a
Server thingy, as is the EntrySerializer. Moreover, the DefaultEntry
implements the Externalizable interface, but does also provides
serialize()/deserialize() methods, which export the RDN, not the DN, simply
because it's used only by the server.

This is a mess...


Separating out the implementations might help decouple these server side
ONLY concerns. But I don't know how I feel about having to have a ServerDn
verses a regular Dn.


This is what we had once upon a time, and it was, well, awful.
What I'm trying to do right now is to make all the components schema 
aware (ie, DN RDN, AVA) and just store the minimum information when 
serializing them (ie, just serialize the UP types and values), assuming 
that the normalized values can be deduced using the SM, if it's injected.


That should help on the server side, because the SM will always be 
available on the server. Also the burden (and cost) of normalizing a 
serialized value on the server (something we have to deal with in three 
places only : the backend, the session and the ChangeLog) will not be 
that high, assuming that we will have an entry cache later, that  the 
changeLog can be desactivated and that we anyway have to do the job on 
the session side.


This should work, but it's quite painful as it implies a *lot* of 
modifications in the AVA and Rdn classes.


We also have to deal with the different serializer we have, the static 
ones we use in the server, which must take a SM as a parameter.



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com