David Horat [mailto:david.horat@cern.ch] said:
What is the difference between having a DN or an ID in objects? Are objects going to be moved around so their DN will change but you want to preserve that relationship?
Glue is a generic schema with multiple renderings. A DN won't mean much if you try to connect it to an xml rendering, but an ID will. Also indeed I think it's quite possible that we may want to restructure the tree, especially at higher levels - we already do that for glue 1, objects have different DNs if you read them in different places. Also from a practical point of view there seems to be no real performance hit from querying objects by ID, and I think most/all clients do it that way at the moment.
When implementing relationships you need to know exactly where to look. Although our IDs are specified as "A global Unique ID", LDAP has no way to assure this as it uses the DN as its key.
That's irrelevant, the uniqueness has to be established by the info providers.
Moreover, when searching, as you said, it uses the DN,
It depends how you do the query - in practice we normally just query against the root DN and do everything else with objectclasses or attributes in the query filter. So in the simplest case you'd just query for (EntityID=xxx) and you'd get that object. Stephen -- Scanned by iCritical.