Ahhh, I didn't though about other renderings and that this information may be in other technologies. I understand now tha the unique ID will be the only key that will be common in all implementations. :)
Thanks Stephen.
Any other comments on the rest of the Foreign Key implementation?
David Horat [mailto:david.horat@cern.ch] said:Glue is a generic schema with multiple renderings. A DN won't mean much
> 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?
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.
That's irrelevant, the uniqueness has to be established by the info
> 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.
providers.
It depends how you do the query - in practice we normally just query
> Moreover, when searching, as you said, it uses the DN,
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.