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

[David Horat]

On Thu, May 28, 2009 at 1:05 PM, Burke, S (Stephen) <
stephen.burke at stfc.ac.uk> wrote:

> 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).


I agree.


>
>
> 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.


Yes. Here the idea could also be, having a DIT, to try to put the
ForeignKeys in the children, because usually you would create first the
parent. I was discussing this with Laurence right now.


>
>
> 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.


I agree and here is where your expertise comes from the use cases that you
know and I don't. Thus, please vote! :D
http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/LDAPForeignKeysDiscussion


>
>
> Stephen
>
> --
> Scanned by iCritical.
>



-- 
David Horat
Software Engineer – IT/GD – Grid Deployment Group
CERN – European Organization for Nuclear Research » Where the web was born
Address: 1211 Geneva - Switzerland, Office: 28/R-003
Phone +41 22 76 77996
Fax +41 22 76 68178 (fax to email service)
Web: http://cern.ch/horat
Web: http://davidhorat.com/
Profile: http://linkedin.com/in/davidhorat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/glue-wg/attachments/20090529/bf6caa24/attachment.html