glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of David Horat said:
I am trying finalizing the initial draft of the LDAP implementation and have a few questions that need to be resolved before I can finish.
These were mostly addressed in other mails, but for completeness:
So in the Entity class, should Extension.LocalId be specified instead of Extension.Key?
The relations in the association end list are always specified with
Yes. the attribute they have to link with. (E.g. Service.ID). There are several reasons why this may not be a good idea. In GLUE the key for every object (except Extension) is *defined* to be the EntityID, so this is correct.
From the theoretical definition of inheritance, just by pointing to a class we cannot be sure to have access to its subclasses, only to its superclasses.
That isn't directly relevant in that LDAP queries are not object oriented and you do have access to everything. I.e. you can happily do a query like ldapsearch <blah> objectclass=Entity EntityID EndpointURL ComputingEndpointRunningJobs although I doubt that that particular query is very useful! Also many attributes are optional so code anyway can't assume their presence, whether they come from the main class or a derived class. However, this is related to why I think it would be a good idea to use real objectclass inheritance: it means you can do a query like ldapsearch <blah> objectclass=Endpoint EndpointURL to get the endpoint for every service, as opposed to ldapsearch <blah> (&(objectclass=Endpoint)(objectclass=ComputingEndpoint)(objectclass=Stor ageEndpoint)) EndpointURL or even ldapsearch <blah> (&(objectclass=Endpoint)(objectclass=ComputingEndpoint)(objectclass=Stor ageEndpoint)) EndpointURL ComputingEndpointURL StorageEndpointURL (and in the last case, consider the possible mess if I want to query with restrictions on HealthState, ServingState, QualityLevel, ...). If we do use inheritance it will also affect the way the keys work, i.e. if Endpoint has a key pointing to Service then it will automatically be inherited by ComputingEndpoint and StorageEndpoint. And I believe that Sergio said that we should not have "mixed" relations, i.e. that a ComputingService will only have relations to ComputingEndpoints and not to Endpoints, so there is then no need for any other kind of key.
In addition to the questions above, I have three proposals on how to implement the relationships and would appreciate some feedback on each of them and which one is prefered.
As above, it depends on the decision about inheritance, attribute naming and uniqueness of IDs.
Also should we use 'FK' or 'ForeignKey'?.
Out of those two it should be ForeignKey. However, an alternative would be to call them e.g. LocationServiceID which is more explicit. Stephen -- Scanned by iCritical.