[jira] Commented: (DIRSERVER-1050) We need to store a LdapDN into the backend instead of a String

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRSERVER-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529569 ] 

Emmanuel Lecharny commented on DIRSERVER-1050:
----------------------------------------------

I would add that we should store this DN withing the entry itself. 

A quick comparison of the pros/cons of this solution can be find here :

pros :
 - no more LdapDN parsing/normalizing when searching : this simple operation costs around 13.5% of the global time)
 - no need to get the DN from a separate table, as we will have it in the entry. We may just store the String in the DN table
 - we may remove the UpDN table, which is useless, speeding up the add or modify operations

cons :
 - serialization/deserialization of an entry will cost more
 - if we store the DN in the entry, a modifyDN operation will cost more, as we will have to modify all the entries
 - we will have bigger entries on the disk, as we will store the internal structure of a DN.

> We need to store a LdapDN into the backend instead of a String
> --------------------------------------------------------------
>
>                 Key: DIRSERVER-1050
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1050
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>          Components: ldap
>    Affects Versions: 1.5.1
>            Reporter: Emmanuel Lecharny
>             Fix For: 1.5.2
>
>
> When we have obtained an entry from the backend, we are building a ServerSearchResult entry. As this object contains the DN of the returned entry, we have a member which is a LdapDN. This is obviously costly and useless to parse a String back to a DN just before reverting it to a String in order to send it to the client.
> We can avoid such a String -> LdapDN -> String roundtrip by simply storing the DN as a String in the ServerSearchResult object.
> Now, we have another problem : this info is needed as a LdapDN in order to check that the entry can be read by the client (isSearchable() method in the authz interceptor). We also need to inject collective attributes, and to check that the entry is not a referral. Incidently, in the isSearchable() method and collectiveAttributeService interceptor, we are normalizing the DN, which is already normalized... Costly...
> So we need the LdapDN form _and_ the String form. What about simply storing the LdapDN instead of the String into the backend ?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.