[glue-wg] Next phone meeting and foreign keys discussion

[Burke, S (Stephen)]

glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On Behalf Of
David Horat said:
> Moreover, in order to decide where to put foreign keys, I have created
a table in the wiki so we can vote and discuss in the phone conference:
	
http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/LDA
PForeignKeysDiscussion

Did we decide how we want to do this?

  A few comments on my approach to this ... as I said in the meeting it
seems obvious to me that the natural relation for Extension is to have
the keys in Extension. Actually Extension is a special case - for one
thing you can in fact only do it that way since Extension only has a
LocalID! Also, I think the fact that we renamed EntityID also gets
reflected here, i.e. instead of having one attribute
GLUE2ExtensionEntityForeignKey we'll have several like
GLUE2ExtensionServiceForeignKey, GLUE2ExtensionDomainForeignKey, ...?

 Anyway, some general arguments are:

1) Multiplicity - better to have one key than many, or few than many,
especially if the many could be very many (dozens or more). Large
numbers of keys will be harder and probably more inefficient to process
when you extract them (see below).

2) Ease of writing info providers - in general it's easier to create a
higher-level object first and then pass its ID in to the code which
creates lower-level entities. In some cases it may be impossible to do
it the other way around because the code which generates the objects
(especially Domains) can't know about the lower-level objects. In some
cases, e.g. the computing-storage service relations, you'll be stuck
with hard-coding IDs somewhere; in that case I think the relation should
point "out", e.g. for ToStorageService you point from the CS to the SS.

3) Likely queries. Bear in mind that queries can work in two ways - if
you know an object ID you can query objects which reference it, or you
can query the object itself for its key(s). By and large the first one
is more efficient, potentially you can gather all the information you
want in one query. As a concrete example, suppose I want to get the Path
for all StorageShares with a given Tag in a given StorageService (i.e. I
know the ServiceID). One way (leaving out the GLUE2 prefix):

(&(objectclass=StorageShare)(ShareServiceForeignKey=sss)(StorageShareTag
=MCDISK)) StorageSharePath

Other way:

(&(objectclass=StorageService)(ServiceID=sss)) ServiceShareForeignKey

which returns numerous keys, so I either then do lots of queries like

(&(objectclass=StorageShare)(ShareID=key1)(StorageShareTag=MCDISK))
StorageSharePath

which in many cases will return nothing, or I construct one huge query
like

(&(objectclass=StorageShare)(|(ShareID=key1)(ShareID=key2)(ShareID=key3)
...)(StorageShareTag=MCDISK)) StorageSharePath

I think the first one is clearly preferable! Of course I could find a
query that goes the other way, e.g. given a ShareID find the
Capability(s) of the corresponding Service, but in this case that's a
much less likely thing to want to do, and anyway since a Share only
belongs to one Service you have less complexity in the second query.

Stephen

-- 
Scanned by iCritical.