In Indirect Associations, links between objects are not stored on either object but rather in a table external to both which stores the keys to both objects. The JDBC connector expects this scheme as it matches the way relational databases model associations, and is expressed in the following metadata, where the table and column names would vary according to each target database.
account.member:
<property name="eTDYNMember"> <value> <!-- Automatically triggers DN validators and converters, meaning that DNs are checked to ensure that they reference existing objects etc --> <setValue><baseType><flexiStrValue type="DN"/></baseType></setValue> </value> <metadata name="displayName"> <value><strValue>Accounts</strValue></value> </metadata> <!-- still need a connector-speak name for the field --> <metadata name="connectorMapTo"> <value><strValue>member</strValue></value> </metadata> <metadata name="refObjectType"> <value><strValue>eTDYNAccount</strValue></value> </metadata> <metadata name="assocTable"> <value><strValue>acc_grp_assoc</strValue></value> </metadata> <metadata name="assocTableObjNamingAttr"> <value><strValue>grp_name</strValue></value> </metadata> <metadata name="assocTableRefNamingAttr"> <value><strValue>acc_name</strValue></value> </metadata> <metadata name="DNLdapObjectClass"> <value><strValue>eTDYNAccount</strValue></value> </metadata> <!-- Let the framework take care of verifying that contained DNs reference existing objects, rather than having to do this explicitly in connector code. --> <metadata name="DNTestExists"> <value><boolValue>true</boolValue></value> </metadata> <!-- Connector wants only names of accounts by the time the data gets to it. --> <metadata name="DNNameOnly"> <value><boolValue>true</boolValue></value> </metadata> </property>
group.memberOf:
<property name="eTDYNMemberOf"> <value> <!-- Automatically triggers DN validators and converters, meaning that DNs are checked to ensure that they reference existing objects etc --> <setValue><baseType><flexiStrValue type="DN"/></baseType></setValue> </value> <metadata name="displayName"> <value><strValue>Groups</strValue></value> </metadata> <!-- still need a connector-speak name for the field --> <metadata name="connectorMapTo"> <value><strValue>memberof</strValue></value> </metadata> <!-- Is "logically inserted" in Java CS processing <metadata name="isMultiValued"> <value><boolValue>true</boolValue></value> </metadata> --> <metadata name="refObjectType"> <value><strValue>eTDYNGroup</strValue></value> </metadata> <metadata name="assocTable"> <value><strValue>acc_grp_assoc</strValue></value> </metadata> <metadata name="assocTableObjNamingAttr"> <value><strValue>acc_name</strValue></value> </metadata> <metadata name="assocTableRefNamingAttr"> <value><strValue>grp_name</strValue></value> </metadata> <metadata name="DNLdapObjectClass"> <value><strValue>eTDYNGroup</strValue></value> </metadata> <!-- Let the framework take care of verifying that contained DNs reference existing objects, rather than having to do this explicitly in connector code. --> <metadata name="DNTestExists"> <value><boolValue>true</boolValue></value> </metadata> <!-- Connector wants only names of groups by the time the data gets to it. --> <metadata name="DNNameOnly"> <value><boolValue>true</boolValue></value> </metadata> </property>
With indirect associations, the runtime cost for looking up the association attribute is the same in either direction (for example, group.member or account.memberOf) unlike the direct case where an expensive virtual attribute has to be used in one direction.
Typically a connector has one style of associations or the other, however it is possible to have both. For example, a JDBC connector uses indirect associations but supports direct associations to represent compound values.
Copyright © 2013 CA.
All rights reserved.
|
|