airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raminder Singh <>
Subject Re: Some improvements to OrchestratorDataResource
Date Thu, 16 Jan 2014 16:26:43 GMT
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.


On Jan 16, 2014, at 11:08 AM, Chathuri Wimalasena <> 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]

View raw message