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?

On Thu, Mar 26, 2009 at 10:57 AM, Burke, S (Stephen) <stephen.burke@stfc.ac.uk> wrote:
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.



--
David Horat
Software Engineer specialized in Grid and Web technologies
IT Department – Grid Deployment Group
CERN – European Organization for Nuclear Research » Where the web was born
Phone +41 22 76 77996

http://davidhorat.com/
http://cern.ch/horat
http://www.linkedin.com/in/davidhorat