Page History

• for Node attributes (Fragments) in our DB we will use a 'glorified' Map to store these and pass them on through the layers as a single object
• For API methods that require 2-4 parameters there is no need to create separate objects

TBC

API uses (generated) ID's or customer provided names? If names are used should we return IDs at all?

03/11/12 Team meeting notes - Niamh, Toine, Rishi, Aditya, Bruno, Phillipe
Pros:

1. Using IDs would have some performance advantage
2. Using the ID seems natural in some cases
3. Using IDs would allow for 'renaming' where possible

Cons:

1. Using ID would mean client has to get/cache ID's all the time.
2. Supporting both names and ID will lead to 'duplicate' methods in Java API and REST API
3. Using a meaningless ID for Module instead for namespace & revision could lead to issues when debugging (only logs with IDs available)

Other considerations:

1. The Java API follow the REST API. If the rest API is using names then the java API should also use names.
2. Create methods should return the (id of the) objects created. If the module already exists, an exception should be thrown.
3. All ID's generated should be in the response. If we return the ID we also need methods to use the ID. If we update the java API to use ID, we should also update the REST API. (to return  
4. OSS RC does NOT use IDs for models
5. OSS RC Does DB Generated ID for objects (fragments)
6. Need separate decision for
   1. Dataspace
   2. Module Set
   3. Module
   4. Anchor
   5. Fragment  

Maybe only allow if no associated data exist e.g. all fragments using a module should be deleted before a module can be deleted

1. Business logic to check on create if it already exists. If it exists we do not create it.
2. If the module already exists, an exception should be thrown.