Difference between revisions of "Ecosystem Approach Community of Practice: VME iMarine"
(→Id management) |
(→Id management) |
||
| Line 53: | Line 53: | ||
=Id management= | =Id management= | ||
| − | When creating a new object on the side of iMarine, a reference or id for this object is needed. The responsibility of Id generation is primarily on the target side(VME-DB). What can be done is to generate an ID on iMarine side, according this convention ID = LOCAL_{localID}. Example of such an id would be: VmeId = LOCAL_452. A delta can define a number of new objects. Within the delta, the | + | When creating a new object on the side of iMarine, a reference or id for this object is needed. The responsibility of Id generation is primarily on the target side(VME-DB). What can be done is to generate an ID on iMarine side, according this convention '''ID = LOCAL_{localID}'''. Example of such an id would be: VmeId = LOCAL_452. |
| + | |||
| + | A delta can define a number of new objects with all ''localIds'' . Within the delta, the ''localIds'' have a meaning. When the ingestion webservice will create the new object in the target, a new object will be created and the ''localId'' will be replaced with the new ID. | ||
=Open Issues= | =Open Issues= | ||
Revision as of 08:20, 21 August 2013
Introduction
The VME project has started to investigate how the iMarine infrastructure could work in combination with the VME-DB on FAO side. This page tries to make all assumptions explicit and therefore will probably be heavily used for discussion!
You can find the object graph for the VME-DB here, in order to have an idea of the VME domain model (ask Erik or Anton for the name/password).
The big picture
Stateful or Stateless?
The above picture assumes that the iMarine infrastructure will not hold state regarding the VME-DB. Content will flow from the VME-DB into iMarine, will be subject to manipulation and a stream of deltas will flow from iMarine into the VME-DB trough the webservice.
UML
TemplateEditor
The VME-DB is an object graph. Every object in the VME-DB is represented in iMarine through a KeyType. Of course an object has attributes, therefore also a KeyType has attributes.
- Template: Holds a collection of KeyTypes. A Template defines the form in order to manipulate the objects in the VME-DB.
- KeyType: This is the name of the object in the VME-DB
- Attribute: is the name of the attribute of a certain object
- TODO: Engineer and explain better the concept of Parent and Child.
Report, Delta and KeyValue
This diagram describes conceptually the model of a Report and the the format of a Delta message.
A Report is a collection of KeyValue(s). The Delta is a collection of KeyValue(s), representing a change of content.
KeyValue has the following attributes:
- KeyType: see above TemplateEditor
- id: is the id of the object in the in the VME-DB of a certain type(keyType).
- attribute: see above TemplateEditor
- value: the value for that attribute
Target
The target (VME-DB) is from a iMarine point of view a collection of KeyValue(s)
Webservice
Id management
When creating a new object on the side of iMarine, a reference or id for this object is needed. The responsibility of Id generation is primarily on the target side(VME-DB). What can be done is to generate an ID on iMarine side, according this convention ID = LOCAL_{localID}. Example of such an id would be: VmeId = LOCAL_452.
A delta can define a number of new objects with all localIds . Within the delta, the localIds have a meaning. When the ingestion webservice will create the new object in the target, a new object will be created and the localId will be replaced with the new ID.
Open Issues
- How to handle reference data, lookup tables
- How to handle validation rules
- The names of this iMarine function is confusing: Reports. This function is all about editing content, to be send to another entity. Better names could be UniversalEditor, InfiniteEditor, ContentCreator, etc.
