|  |  |  | License Codehaus OpenEJB OpenJMS OpenORB Tyrex

Old releases
General
Release 1.3
Release 1.3rc1
Release 1.2

Main
Home
About
Features
Download
Dependencies
Reference guide
Publications
JavaDoc
Maven 2 support
Maven 2 archetypes
DTD & Schemas
Recent HTML changes
News Archive
RSS news feed
Project Wiki

Development/Support
Mailing Lists
SVN/JIRA
Contributing
Support
Continuous builds
Prof. services

Related projects
Spring ORM support
Spring XML factories
WS frameworks

XML
XML

XML Code Generator
XML Code Generator

JDO
Introduction
First steps
Using JDO
JDO Config
Types
JDO Mapping
JDO FAQ
JDO Examples
JDO HOW-TOs
Tips & Tricks
Other Features
JDO sample JAR

Tools
Schema generator

Advanced JDO
Caching
OQL
Trans. & Locks
Design
KeyGen
Long Trans.
Nested Attrs.
Pooling Examples
LOBs
Best practice

DDL Generator
Using DDL Generator
Properties
Ant task
Type Mapping

More
The Examples
3rd Party Tools
JDO Tests
XML Tests
Configuration

About
License
User stories
Contributors
Marketplace
Status, Todo
Changelog
Library
Contact
Project Name

## How to cascade object creation

Overview
Enabling cascading creation
Scenarios
db.create()
db.commit()
Cascading create and collections
See also

## Overview

Cascading creation allows you to transfer some of the responsibilities of creating objects to Castor JDO. To be more precise: if you enable cascading creation on a relation between two classes, all objects on one end of that relation that have not yet been created will be created when the other end gets persisted. This saves you from manually creating every single object, which is especially useful when dealing with large object graphs that have 1:M (one to many) relations or many objects in a single relationship.

## Enabling cascading creation

To enable cascading creation on a relation, you simply set the cascading attribute of the <sql> field describing the relation to "create" (or "all"):

In other words, the field mapping for the Java property book ...

    <field name="book" type="myapp.Book" >
      <sql name="book_id" />
    </field>

becomes

    <field name="book" type="myapp.Book" >
      <sql name="book_id" cascading="create" />
    </field>

In case of bidirectional relations, it does matters on which end you enable cascading creation. It is also possible to enable it on both ends.

## Scenarios

### db.create()

The most intuitive case is when you explicitly call `db.create()` on an object that has cascading creation enabled on one or more of his relations. If the objects in those relationships have not yet been created, they will be as part of the `create()` execution.

Here is a simple example, where the objects Author and Book are in a one-to-one relation (i.e. every Book has exactly one Author):

    db.begin();

    Author author = new Author();
    author.setId(1);
    author.setName("John Jackson");

    Book book = new Book();
    book.setId(1);
    book.setTitle("My Life");
    book.setAuthor(author);

    db.create(book);

    db.commit();

Once the commit operation has successfully completed, both the `Author` and the `Book` instance will have been persisted to your data store. To highlight this, lets's have a look at the corresponding database tables before and after the execution of above code fragment.

Before

Author

id | name
--- | ---
(empty table)

Book

id | title | author_id
--- | --- | ---
(empty table)

After

Author

id | name
--- | ---
1 | "John Jackson"

Book

id | title | author_id
--- | --- | ---
1 | "My Life" | 1

### db.commit()

Cascading creation also works implicitly: any objects that are on the receiving end of a cascaded relation will be created upon transaction commit, provided they do not exist yet and that the object on the primary end of that relation does. In other words: if you modify a relation property of a loaded object, any new objects that now need to be created will be created.

To demonstrate, let's continue the example from the previous section. We, again, have a `Book` and an `Author`, in a one-to-one relation, both already persisted. If we now change the book's author to someone new, any object that is not yet in the database will be persisted automatically. Just call db.commit() after setting the new author, and the new author will be persisted as well.

    db.begin();

    Author author = new Author();
    author.setId(2);
    author.setName("Bruce Willis");

    Book book = db.load(Book.class, 1);
    book.setAuthor(author);

    db.commit();

In terms of unit test assertions, the current state of the author and book instances can be expressed as follows:

    db.begin();

    Book book = db.load(Book.class, 1);
    assertNotNull(book);
    assertEquals(1, book.getId());

    Author author = book.getAuthor();
    assertNotNull(author);
    assertEquals(2, book.getId());

    db.commit();

As above, let's have a look at the corresponding database tables for the entities `Author` and `Book`:

Before

Author

id | name
--- | ---
1 | "John Jackson"

Book

id | title | author_id
--- | --- | ---
1 | "My Life" | 1

After

Author

id | name
--- | ---
1 | "John Jackson"
2 | "Bruce Willis"

Book

id | title | author_id
--- | --- | ---
1 | "My Life" | 2

Please note that we now have two authors stored, and that the book with an id value of '1' now has a foreign key relationship to the author with the id value '2'.

### Cascading create and collections

The real benefit of using cascading for object creation shows when dealing with 1:M relations, usually expressed through Java collections in your entity classes.

For the remainder of this secction, we will use the Java classes `Department` and `Employee`, which have a 1:M relationship (in other words, every department has one or more employees). On the Java side, this is expressed as the `Department` having a collection of `Employee` objects in form of a Java collection. In the database, this will obviously be the other way around, with the `emp` table referencing the `dept` table. Every example in this section will use the same database state as a starting point, as shown here:

dept

id | name
--- | ---
23 | "Accounting"

emp

id | name | dept_id
--- | --- | ---
1 | "John" | 23
2 | "Paul" | 23
3 | "Ringo" | 23

Example 1: Adding objects

    db.begin();

    Employee employee = new Employee();
    employee.setId(4);
    employee.setName("George");

    Department department = db.load(Department.class, 23);
    department.getEmployees().add(employee);

    db.commit();

After

dept

id | name
--- | ---
23 | "Accounting"

emp

id | name | dept_id
--- | --- | ---
1 | "John" | 23
2 | "Paul" | 23
3 | "Ringo" | 23
4 | "George" | 23

Example 2: Removing objects

    db.begin();

    Department department = db.load(Department.class, 23);
    department.getEmployees().remove(2);

    db.commit();

After

dept

id | name
--- | ---
23 | "Accounting"

emp

id | name | dept_id
--- | --- | ---
1 | "John" | 23
2 | "Paul" | 23
3 | "Ringo" | NULL

Note: this of course only works if you allow the employee's foreign key `dept_id` to be NULL or, alternatively, also delete the Employee when you remove the relationship (either by manually calling db.remove() or TODO)

Example 3: Adding & removing objects

    db.begin();

    Employee e4 = new Employee();
    e4.setId(4);
    e4.setName("George");

    Employee e5 = new Employee();
    e5.setId(5);
    e5.setName("Joe");

    Employee e6 = new Employee();
    e6.setId(6);
    e6.setName("Jack");

    Department dep = db.load(Department.class, 23);
    dep.setEmployees(Arrays.asList(e4, e5, e6));

    db.commit();

Database after:

dept

id | name
--- | ---
23 | "Accounting"

emp

id | name | dept_id
--- | --- | ---
1 | "John" | NULL
2 | "Paul" | NULL
3 | "Ringo" | NULL
4 | "George" | 23
5 | "Joe" | 23
6 | "Jack" | 23

The note to example 2 also applies here.

## See also

- | How to use cascading operations - overview

<notice> Copyright © 1999-2005 ExoLab Group, Intalio Inc., and Contributors. All rights reserved. </notice>
<notice> Java, EJB, JDBC, JNDI, JTA, Sun, Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. XML, XML Schema, XSLT and related standards are trademarks or registered trademarks of MIT, INRIA, Keio or others, and a product of the World Wide Web Consortium. All other product names mentioned herein are trademarks of their respective owners. </notice>