Skip Headers

# Register New Objects and Instantiate Relationships

Previous

Next

If a new object is only related to an existing object, and not explicitly registered, queries for this object are not able to conform it. If you remove, but do not explicitly delete a privately owned object, this object cannot be conformed.

If a query traverses relationships (uses joins) and the related objects are changed, the query can only conform these objects if both of the following conditions are met:

- The source objects have been registered in the unit of work.

- The source objects' relationship has been instantiated.

TopLink provides a conforming option that forces an instantiation of indirection. However, you use this option with caution as it can cause an increased database access.

Consider the example shown in Example: Conforming Example. In this example, you have `Employee` objects with an `address` attribute configured for indirection (see "Indirection") mapped by a one-to-one mapping to an `Address` object.

Conforming Example

Description of "Conforming Example"

You want to read all employees who live in Ottawa, but first, you need to modify some of the `Address` objects to change city from Toronto to Ottawa. Jane Doe is one such employee.

First, using the `UnitOfWork`, you read all `Address` objects and change some `city` attributes (including Jane's) from Toronto to Ottawa. Then you run a conforming query to get all employees who live in Ottawa. However, for the following reasons Jane is not included in the results, even though she now lives in Ottawa:

- Jane is not returned from the database because the transaction has not yet been committed and in the database, her address still says Toronto.

- Jane cannot be added to the conformed result in memory because she is not registered in the `UnitOfWork` cache.

Conforming only recognizes explicit changes. In this example, Jane Doe's `Employee` object was only implicitly changed. In order to be considered explicitly changed, an `Employee` must meet the following criteria:

- be registered in the `UnitOfWork`

- have its `address` attribute changed (in this example, indirection must be triggered for the `address` attribute)

The correct way to handle this example would be as follows:

1. Using the `UnitOfWork`, read in all employees.

   All these `Employee` objects are now registered with the `UnitOfWork`

2. Using the same `UnitOfWork`, access the employees' addresses, instantiating the indirect relationships.

3. Modify the employees' addresses, changing some of the addresses to be in Ottawa.

4. Run the conforming query on employees with addresses inside Ottawa.

   All employees with addresses in Ottawa are returned, including both employees that were in Ottawa originally and employees whose addresses were changed in this transaction.

5. Commit the transaction.

If you do not register all employees whose address may be changed, and instantiate their address relationship, the conforming query will not include Jane.

An alternate approach is to use short transactions: the safest conforming query is one made immediately after a commit. For example:

1. Using the `UnitOfWork`, read in all addresses outside of Ottawa.

2. Modify the addresses, changing some of the addresses to be in Ottawa

3. Commit the transaction.

4. Using the `UnitOfWork`, read in all employees inside Ottawa.