In a SQL repository, you can use derived properties. This feature enables one repository item to derive property values from another repository item or from another property in the same repository item. To illustrate: some data models are organized in a tree structure in which certain property values are passed down from other properties. For example, an organization might have divisions, departments, and employees, organized in a tree structure. A repository represents this tree structure with division, department, and employee item descriptors. Each of these item descriptors might define a property called spendingLimit. A business rule might specify that an employee’s spending limit comes from their department if it isn’t set for that employee. If the spending limit is not set for the department then it should be derived from the spending limit for the division.

This derived property relationship would be represented in a repository definition file like this:

<item-descriptor name="employee">
   <property name="department" item-type="department"/>
   <property name="empSpendingLimit" data-type="int"/>
   <property name="spendingLimit" writable="false">
     <derivation>
       <expression>empSpendingLimit</expression>
       <expression>department.spendingLimit</expression>
     </derivation>
   </property>
 </item-descriptor>

<item-descriptor name="department">
   <property name="division" item-type="division"/>
   <property name="deptSpendingLimit" data-type="int"/>
   <property name="spendingLimit" writable="false">
     <derivation>
       <expression>deptSpendingLimit</expression>
       <expression>division.divSpendingLimit</expression>
     </derivation>
   </property>
 </item-descriptor>

<item-descriptor name="division">
   <property name="division" item-type="division"/>
   <property name="divSpendingLimit" data-type="int"/>
</item-descriptor>

Derived properties can use multiple levels of subproperties. So in our spending limit example, we might derive the employee’s spending limit this way:

<item-descriptor name="employee">
  <property name="department" item-type="department"/>
  <property name="spendingLimit" data-type="int" writable="false">
    <derivation>
      <expression>department.employeeDefaultInfo.spendingLimit</expression>
    </derivation>
  </property>
</item-descriptor>

<item-descriptor name="department">
   <property name="employeeDefaultInfo" item-type="employeeInfo"/>
   <property name="deptSpendingLimit" data-type="int"/>
 </item-descriptor>

<item-descriptor name="employeeInfo">
  <property name="spendingLimit" data-type="int" writable="false"/>
  <property name="officeLocation" data-type="string"/>
</item-descriptor>

Bear in mind that using derived properties can affect performance, and that the more complex the derivation, the greater the impact is likely to be.

The FirstNonNull derivation method must be non-writable, unless you set a writable override property for the derived property. You can set a property to be not writable like this:

<property name="spendingLimit" data-type="int" writable="false"/>

The FirstWithAttribute and FirstWithLocale derivation methods can be writable, even if the property does not define a writable override property. See Override Properties in this section for more information.

 
loading table of contents...