directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre-Arnaud Marcelot (JIRA)" <>
Subject [jira] Updated: (DIRSERVER-1050) [PERF]We need to store a LdapDN into the backend instead of a String
Date Tue, 01 Jun 2010 14:56:46 GMT


Pierre-Arnaud Marcelot updated DIRSERVER-1050:

    Fix Version/s: 2.0.0-RC1
                       (was: 2.0.0)

Moving issue to 2.0.0-RC1.

> [PERF]We need to store a LdapDN into the backend instead of a String
> --------------------------------------------------------------------
>                 Key: DIRSERVER-1050
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>          Components: ldap
>    Affects Versions: 1.5.1
>            Reporter: Emmanuel Lecharny
>            Assignee: Emmanuel Lecharny
>             Fix For: 2.0.0-RC1
> 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.

View raw message