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
Book |
id |
title |
author_id |
(empty table) |
|
After
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
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:
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
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
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:
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
|