[
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.
