Slave object management

Work with slave objects

• What is a slave object
  • Slave object examples
  • False slave objects
• Mishmash slave object example – address
• Slave object implementation
• Slave object support in views
  • Example:
  • Correct view definition

What is a slave object

Slave object is an object that exists only as a part of another object – master object

Slave object examples

• An object that encapsulates language translation of the master object. The translation makes no sense without the translated object.
• Description of the requirement analysis.

False slave objects

The literature often uses wrong examples:

• Car wheels: A car wheel is a part of a car. That's right and physically makes no sense without a car (What to do with car wheels without a car?) However, wheels really makes sense without a car – you might sell them, they are in the stock etc. So that a car wheel is not a slave object
• Work report: Work report is always linked with some task. Although work makes no sense without task, timesheet is standalone important information about somebody activity. Timesheet could not be deleted when task becomes obsolete (simply because work is completed or canceled). When a timesheet is linked with a task it preserve the task to be deleted. Pure slave object would never block deleting of a master object.

Slave object implementation

Technically there are two different types of slave objects:

• Objects linked only with one master object linked by (strong relationship). These are linked with the master object ID. They can be deleted automatically by database using the referential integrity
• Objects linked possibly with several objects types (weak relationship). These are linked with object name and object id. The relation could be managed by database only using the triggers that could delete the relation automatically. (Module authors are encouraged to use the triggers or make control on higher level of the program.)

Slave object support in views

AyMINE support weak slave objects that could be linked with pair of attributes objectName – objectID. The link pair of attributes could use different name as long as they adhere standards:

• name of the object is in the <pair_name>Name attribute
• if is in the <pair_name>ID attribute
• <pair_name>ID has type objectPrincipal

Example:

"objectName":{
   "type":"string","length":32, 
   "readonly":true, "required":true, 
   "default":"=obj.myObjName"
},
"objectID":{
   "type":"objectPrincipal", 
   "readonly":true, "required":true, 
   "default":"=obj.ID" 
},

For all weak-linked slave object server loads all fields:

• objectID – should be in the view attributes
• objectName – added by server
• objectIDDesc – master object description that could be used by detail to show it.

Let's note that objectName / objectID field names are recommended but not required. Field could have different names. However, client application support pairs of field names Name / ID and simplifies their management in pair.

Correct view definition

Don't put objectName attribute to the list of view attributes. It breaks internal logic.
For both detail and list view, only the objectID field could be placed to the list of attributes. ObjectName is loaded automatically

Detail view does not have objectName attribute but the objectName value is loaded to the data object – it is available for all operations but not placed on the page (there is only single attribute with link to other object).