Agile Object to Relational Database Replication with db4o
Pages: 1, 2, 3, 4, 5, 6, 7, 8
dRS makes use of the capability that Hibernate, the popular open source object-relational mapping framework, provides to work directly with Java objects that are persisted by a relational database. Hibernate works in the background to generate and execute the SQL statements that the database understands, and to connect the results of executing the SQL with live Java objects. dRS builds on this to compare objects in a db4o database with those stored in the SQL database, and to update those that have changed since the last replication. Hibernate does the work of making persisted data available as live objects, while dRS does the work of comparing and deciding which objects need to be updated. Because Hibernate supports a wide range of RDBMSes (there is a list here), dRS supports them too.
The only extra bits of work that need to be done compared with db4o-to-db4o replication are to create a Hibernate configuration file (which specifies, among other things, what kind of database is to be used) and specify where to find it, and to create mapping files for each persistent class. It's worth noting here that by doing this you are to some extent compromising on the benefits offered by db4o itself. With a pure object database, you never have to create mappings, and you can easily work with object models that would be very difficult to map to relational tables.
So what's the motivation to use db4o at all? Why not use a relational database in the first place? There are a number of reasons why you might choose db4o. The fact that the application and database use exactly the same model means that you don't have to write a lot of code to build and execute SQL statements that the compiler can't check and that can be difficult to refactor. You also don't need to write more code to assemble objects from the results. You could use Hibernate directly in the application, which would let you work only with objects in your code. However, the footprint and performance of the resultant application would probably make it unsuitable for devices with limited resources. Finally, in my opinion, db4o is just really nice to use.
Let's look at dRS replication in action. The dRS distribution includes some samples based on an in-memory HSQLDB database. To test it out in a more "enterprise" scenario, let's replicate to a MySQL 5.0 database.
You can download the source code for this example in the Resources section. To compile and run this code you'll need to download dRS and add all of the included libraries to your project. The dRS distribution includes the required db4o and Hibernate libraries. You'll also need access to a MySQL server, on which you need to create a schema called drsexample, and you should add the MySQL Connector/J driver to your project--you can download it from the MySQL Connectors Downloads page.
drsexample
First we need some objects. These will be instances of the two classes listed below, Customer and Address. There is a one-to-one relationship here: each Customer object has a field that is an Address object. The ability to deal with objects with relationships is important, as objects stored in an object database will often have fields that are themselves objects. Replication should maintain those relationships. dRS supports fields that are either single objects like this, or instances of common collection types.
Customer
Address
public class Customer {
private Long id;
private String title;
private String firstName;
private String lastName;
private Address address;
private String email;
private String phoneNumber;
private String faxNumber;
private int creditLine;
private String contactCode;
// getters and setters omitted...
public String toString(){
return "[" + firstName + " " + lastName + "]";
}
}
public class Address {
private Long id;
private String street1;
private String street2;
private String city;
private String zip;
private String country;
// getters and setters omitted...
public String toString(){
return "[" + street1 + ", " +.