|  |  |  | 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
| Copyright © 1999-2005 ExoLab Group, Intalio Inc., and Contributors. All rights reserved. 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. |