Bugs
Segment order in adapter multi-segment DN appears to be random
The strangest thing ever... For this adapter:
When I generate changes to update the DNs (used to be DN=@IdBID), I see DNs assigned with different segment orders like this:
The two digit CN is DepartmentID. The date CN is StartDate. The four digit CN is PositionID. The three letter CN is LocationID. The six digit CN is EmployeeID.
I tried clearing precalculated entities and re-running Generate Changes, but the same thing happens with the newly generated entities - the segments are always in the same (wrong) order for each entity.
This is happening in a non-Production environment, and the DN segment order for each entity appears to be persistent, so this is a very minor (but very strange) issue.
Answer
Hi Adrian,
The order should be consistent for the values provided. The order of the components only appears random for your implementation because you're using the same AttributeType identifier for your RDN sequence.
When the DN is built for an object, MultiPart components are first ordered by the AttributeType (CN, OU, UID etc) and then by the AttributeValue. In your case this means only the value is being taken into account because the type is the same for all parts of the Multi-part RDN.
In line with the LDAP RFC's (2253, 4514) a multi part RDN is not required to be in any particular order. While I'm not sure on the exact specifics of why we don't respect the order provided in the template, I suspect it relates to comparing DNs and allowing a consistent string representation.
If it's causing a problem I can investigate options for fixing or allowing a fixed order but would need to dig further into the implications.
Right, that makes sense. Since the order will always be consistent for any given set of attributes on a particular object I cannot think of any case where this would cause a problem, so I am happy for this ticket to be marked as 'Not A Bug' and closed off.
Customer support service by UserEcho
Hi Adrian,
The order should be consistent for the values provided. The order of the components only appears random for your implementation because you're using the same AttributeType identifier for your RDN sequence.
When the DN is built for an object, MultiPart components are first ordered by the AttributeType (CN, OU, UID etc) and then by the AttributeValue. In your case this means only the value is being taken into account because the type is the same for all parts of the Multi-part RDN.
In line with the LDAP RFC's (2253, 4514) a multi part RDN is not required to be in any particular order. While I'm not sure on the exact specifics of why we don't respect the order provided in the template, I suspect it relates to comparing DNs and allowing a consistent string representation.
If it's causing a problem I can investigate options for fixing or allowing a fixed order but would need to dig further into the implications.