-
Notifications
You must be signed in to change notification settings - Fork 4
Attribute bindings
Attributes can be bound to an object class as either a simple or inherited binding. A simple binding allows an attribute to be read and written to in that object class.
Inherited attributes allow an attribute value to be inherited from another object. Inherited attributes are read-only on the object class they are bound to. The value itself is not stored on the inheriting object, and therefore cannot be used in database queries. The values can be used in rules and value declarations, and will be imported into FIM.
A common example of the use of an inherited attribute is when you want to populate a department name on a person object, based on a referenced organizational unit object. The displayName of the object referenced by the organizationalUnit attribute on the person, can be inherited as departmentName on the person object.
If the inheritance source reference changes, or the inherited value itself, ACMA will automatically trigger an update to the inherited attribute.
Simple bindings provide direct attribute access for object classes.
Characteristics:
- Read/write access to the attribute
- Attribute values stored directly on the object
- Can be used in database queries and indexes
- Support all attribute operations and modifications
Inherited bindings enable dynamic attribute inheritance from referenced objects.
Characteristics:
- Read-only access (values computed from referenced objects)
- Values not stored on the inheriting object
- Cannot be used in database queries (computed at runtime)
- Automatically update when source object or reference changes
Object Class: person
Attribute: department
Binding Type: Simple
Access: Read/Write
Storage: Direct on person object
Object Class: person
Attribute: departmentName
Binding Type: Inherited
Source Reference: organizationalUnit (attribute on person)
Source Attribute: displayName (attribute on organizationalUnit)
Access: Read-only
person object:
- organizationalUnit (simple binding - reference to OU)
- departmentName (inherited from organizationalUnit->displayName)
- departmentCode (inherited from organizationalUnit->code)
person object:
- manager (simple binding - reference to manager person)
- managerName (inherited from manager->displayName)
- managerEmail (inherited from manager->mail)
person object:
- physicalLocation (simple binding - reference to location)
- buildingName (inherited from physicalLocation->buildingName)
- floorNumber (inherited from physicalLocation->floor)
Simple bindings offer optimal performance for direct attribute access since values are stored directly on the object and can be retrieved through standard database operations. Inherited bindings introduce computational overhead because values must be calculated at runtime by traversing object references and retrieving source attribute values.
Inherited attributes provide automatic data consistency by dynamically reflecting changes in source objects without requiring manual synchronization processes. This eliminates the risk of data inconsistency that can occur when related information is duplicated across multiple objects. The inheritance model also reduces storage requirements by avoiding data duplication, as attribute values are computed from authoritative sources rather than being stored redundantly.
Inherited attributes cannot be used in database queries or filters because their values are computed at runtime rather than being stored in the database. When designing schemas, use simple bindings for attributes that need to be queried or used in search operations. Consider your data access patterns carefully when choosing binding types, as this decision affects both query capabilities and system performance.