[
https://issues.apache.org/jira/browse/DIRSERVER-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Karasulu closed DIRSERVER-1050.
------------------------------------
Resolution: Fixed
This was already done with latest work with server entry.
> [PERF]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
> Assignee: Emmanuel Lecharny
> Fix For: 2.0.0
>
>
> 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.
