Some improvements to OrchestratorDataResource

[Chathuri Wimalasena <ka...@gmail.com>]

Hi Raman,

I was looking in to OrchestratorDataResource object and I would like to
suggest some improvements to it.

As described in [1], registry was designed according to a hierarchy. When
implementing the registry resource layer, we tried to keep the same
hierarchy. If you look into Resource interface, you will see there are
several methods such as create, remove, get, save etc. All these methods
(except for save) should be implemented to the child resources of a
specific resource. For example, if you are trying to implement
ExperimentDataResource class, create method will create all the children
that can be created after experiment data resource. In the similar manner,
if you implement get method for ExperimentDataResource, it will retrieve
all the child resources that can be retrieved with the availability of
ExperimentDataResource. Save method will save the resource object into the
database.

So when you implement the OrchestratorDataResource, all the create, get,
remove methods need to be implemented for the child objects that can be
generated with the availability of OrchestratorDataResource object. If you
want to retrieve OrchestratorDataResource object itself, you have to
implement that on it's parent object (in this case, it may be the
GatewayResource). I see that you implemented all the methods needed
for Orchestrator inside the same resource class. I will move those methods
to GatewayResource class.

We will need to update the wiki documentation to have a comprehensive
description of the implementation later in order to avoid the confusion.

BTW, just curious, why do we need an auto increment field for
orchestrator_ID while setting experiment_id as the primary key ?

Thanks and Regards,
Chathuri

[1]
https://cwiki.apache.org/confluence/display/AIRAVATA/Registry+Data+Structure+Guide

Re: Some improvements to OrchestratorDataResource

[Raminder Singh <ra...@gmail.com>]

Thanks Chathuri for your input. I started with OrchestratorData as system table and followed the hierarchy of ConfigurationResource table.  After discussing use cases in detail in last one week hangout, I think we need relationship to work with ExperimentData. It will be a good idea to use the experiment hierarchy to maintain consistency of data. It will use existing API methods to provide access to user experiment data objects.  I will update the wiki.

I thought of using orchestrator_ID to maintain uniqueness but experimentid is unique in the system so i just let this for future use. I am thinking of dropping this as it adds some confusion.  

Thanks
Raminder

On Jan 16, 2014, at 11:08 AM, Chathuri Wimalasena <ka...@gmail.com> wrote:

> Hi Raman, 
> 
> I was looking in to OrchestratorDataResource object and I would like to suggest some improvements to it. 
> 
> As described in [1], registry was designed according to a hierarchy. When implementing the registry resource layer, we tried to keep the same hierarchy. If you look into Resource interface, you will see there are several methods such as create, remove, get, save etc. All these methods (except for save) should be implemented to the child resources of a specific resource. For example, if you are trying to implement ExperimentDataResource class, create method will create all the children that can be created after experiment data resource. In the similar manner, if you implement get method for ExperimentDataResource, it will retrieve all the child resources that can be retrieved with the availability of ExperimentDataResource. Save method will save the resource object into the database.
> 
> So when you implement the OrchestratorDataResource, all the create, get, remove methods need to be implemented for the child objects that can be generated with the availability of OrchestratorDataResource object. If you want to retrieve OrchestratorDataResource object itself, you have to implement that on it's parent object (in this case, it may be the GatewayResource). I see that you implemented all the methods needed for Orchestrator inside the same resource class. I will move those methods to GatewayResource class. 
> 
> We will need to update the wiki documentation to have a comprehensive description of the implementation later in order to avoid the confusion. 
> 
> BTW, just curious, why do we need an auto increment field for orchestrator_ID while setting experiment_id as the primary key ? 
> 
> Thanks and Regards,
> Chathuri
> 
> [1] https://cwiki.apache.org/confluence/display/AIRAVATA/Registry+Data+Structure+Guide