Might be a good idea to add this operational attribute as a virtual attribute to an entry when it is going out the door ONLY. We should do it like this because then we don't have to load up the entry from the backend when doing modDn operations. At this point we're totally hosed on modDN because of the decision to include the DN in the entry.
Incidentally I will have to veto any release that does not fix this problem: it's high priority IMO. I warned about the performance issue it brings about. Howard Chu confirmed this and still it's the case. To see just load up a server with 1M user entries then try a modDN on ou=Users. Do it on the server before this change and after it was introduced. Seeing the difference will convince anyone.
RFC 5020 is trying to fix this, adding a virtual entryDN attribute :
That's not a bad idea. However, I don't know whay using a DN in the
requetsed attributes should automatically lead to an error. Is there a
major problem forbiding a server to return a DN as if it were an
attribute, if specifically requested ?
On Mon, Feb 23, 2009 at 11:23 AM, ayyagarikiran <email@example.com> wrote:
> I believe the jabber server's LDAP setting is treating the 'dn' as a
> attribute name (e.x the attribute used for fetching the uid or group value