In the managed association approach, the parent destination is not responsible for processing updates for changes made to properties of the child objects. It is only responsible for processing the changes to the identity property values of children referenced by the parent. Suppose a Person object has an Address property. Using the hierarchical values approach, the Person destination would handle a change to the city of a person address. However, in the managed association approach, the Address destination would process a change to the city.

In the managed association approach, the Person destination would process a change if someone assigned an Address with a different identity property to the Address property of the Person object. You can also configure whether the relationship supports lazy loading of object graphs from the server to the client.

The destination relationships you configure can be unidirectional or bidirectional. Unidirectional relationships use the many-to-one, one-to-one, and one-to-many elements, and bidirectional relationships use the many-to-many element. These managed association elements are subelements of the metadata element, which is a supplement of the properties element.

Some managed associations rely on database tables. To establish a many-to-many relationship between these tables, create a join table rather than using a foreign key.

You set the read-only attribute of an association property to true for the inverse side of a two-way relationship. This setting indicates that the assembler does not depend on the state of this property being populated, which ensures that dependent items are created before independent items. Setting the read-only attribute to true does not mean that you cannot edit the association value. Rather, it means that the association is read only with respect to the assembler, which does not use that value to update the database. Instead, the assembler uses the other side of the relationship.

Managed association example

The Sales Builder sample application provides an example of a many-to-one relationship. On the Flex client side of the application, a DataService component named account manages a collection of Account objects that works with a destination named account on the server. The Account objects have a set of properties, including a salesRep property of type SalesRep, which works with a destination named sales-rep on the server. The account destination defines a many-to-one relationship to the sales-rep destination, so SalesRep changes, additions, or deletions are propagated up to the corresponding Account object or objects to which the particular SalesRep objects belong.

The following example shows the source code for the Account class:

package com.salesbuilder.model
{
    [Managed]
    [RemoteClass(alias="com.salesbuilder.model.Account")]
    public class Account
    {
        public var accountId:int;
        public var name:String;
        public var phone:String;
        public var fax:String;
        public var ticker:String;
        public var ownership:String;
        public var numberEmployees:int;
        public var annualRevenue:Number = 0;
        public var priority:int;
        public var address1:String;
        public var address2:String;
        public var city:String;
        public var zip:String;
        public var notes:String;
        public var url:String;
        public var rating:int;
        public var currentYearResults:Number = 0;
        public var lastYearResults:Number = 0;
        public var industry:Industry;
        public var salesRep:SalesRep;
        public var category:AccountCategory;
        public var state:State;
    }
}

The following example shows the source code for the SalesRep class:

package com.salesbuilder.model
{
    [Managed]
    [RemoteClass(alias="com.salesbuilder.model.SalesRep")]
    public class SalesRep
    {
        public var salesRepId:int;
        public var firstName:String;
        public var lastName:String;
        
        public function get fullName():String
        {
            return firstName + " " + lastName;
        }
    }
}

On the server side, Java-based Account and SalesRep objects represent accounts and sales representatives. These classes are mapped to the corresponding client-side Account and SalesRep objects.

Destination configuration

The following example shows relevant sections of the account and sales-rep destinations, including the many-to-one element in the account destination that defines the relationship between the destinations. The boldface text highlights the configuration for the many-to-one relationship.

...
<!-- account destination has a many-to-one relationship to the sales-rep destination -->
<destination id="account">
    <properties>
        <source>com.salesbuilder.assembler.AccountAssembler</source>
        <scope>application</scope>
        <metadata>
            <identity property="accountId" undefined-value="0"/>
            <many-to-one property="salesRep" destination="sales-rep" lazy="true"/>
            <many-to-one property="industry" destination="industry" lazy="true"/>
            <many-to-one property="category" destination="account-category" lazy="true"/>
            <many-to-one property="state" destination="state" lazy="true"/>
        </metadata>
        <network>
            <paging enabled="false" pageSize="10" />
        </network>
    </properties>
</destination>

<!-- sales-rep destination -->
<destination id="sales-rep">
        <properties>
            <source>com.salesbuilder.assembler.SalesRepAssembler</source>
            <scope>application</scope>
            <metadata>
                <identity property="salesRepId" undefined-value="0"/>
            </metadata>
            <network>
                <paging enabled="false" pageSize="10" />
            </network>
        </properties>
    </destination>