In an 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 where 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 is not set for that employee. If the spending limit is not set for the department it should be derived from the spending limit for the division.

This derived property relationship is represented in a repository definition file as follows:

<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 the spending limit example might derive the employee’s spending limit as follows:

<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 derivation methods firstWithAttribute and firstWithLocale 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...