[glue-wg] Foreign Key implementation on GLUE 2.0 LDAP implementation

[Burke, S (Stephen)]

glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On Behalf Of
David Horat said:
> Having an object ObjectA related to object ObjectB and being the
relationship ObjectA 0..* - 0..* ObjectB,
> - ObjectA will contain the attribute ObjectAObjectBFK pointing to
ObjectB's DN
> - ObjectB will contain the attribute ObjectBObjectAFK pointing to
ObjectA's DN

I have another general point about foreign keys (aside from the fact
that they should point to an ID and not a DN). Even though the
relationship has two ends there is no particular reason to have the keys
in both the objects. In your example above, even if the second attribute
is missing I can navigate in both directions: either I query A for the B
ID in its FK attribute and then query for B by its ID, or I query B for
its ID and then query for the A which has an FK which references it.
There might be marginal performance differences but I don't think it's
significant in practice.

  That might not matter, except that there can also be practical impacts
because the multiplicities can in some cases be enormous. For example,
consider the ComputingShare/ComputingActivity relation. There could be a
huge number of jobs, so if you put all the references into the Share it
will inflate the size of the object substantially. 

  There are also practical implications for the way the info providers
are written. The info provider has to be able to know the IDs of all the
objects it references explicitly. The natural way to to it is to
generate the objects in a hierarchical way, so in the same case you'd
generate the Share with its ID and then loop over all the jobs passing
the share ID in. If you want to have the Activity keys in the Share
you'd have to duplicate the loop over the jobs so you could put their
IDs into the Share, and also cache the information because otherwise the
list might change in between.

Stephen
-- 
Scanned by iCritical.