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