First, make sure that you are in the reversetutorial directory and that you've made the appropriate modifications to your kodo.properties file, as described in the previous chapter.

Now that we've got our environment set up correctly, we're going to dump our existing schema to an XML document. This step is not strictly necessary for Hypersonic SQL, which provides good database metadata. Some databases, however, have faulty JDBC drivers, and Kodo JDO is unable to gather enough information about the existing schema to create a good object model from it. In these cases, it is useful to dump the schema to XML, then modify the XML by hand to correct any errors introduced by the JDBC driver. If your schema doesn't use foreign key constraints, you may also want to add logical foreign keys to the XML file so that Kodo JDO can create the corresponding relations between the persistent classes it generates.

To perform the schema-to-XML conversion, we're going to use the schema generator, which can be invoked via the included rd-schemagen shell script, or through its Java class, com.solarmetric.rd.kodo.impl.jdbc.schema.SchemaGenerator . The -file flag tells the generator what to name the XML file it creates:

rd-schemagen -file schema.xml

Examine the schema.xml XML file created by the schema generator. As you can see, it contains a complete representation of the schema for your magazine database. For the curious, this XML format is documented here.

Run the reverse mapping tool on the schema file. (If you do not supply the schema file to reverse map, the tool will run directly against the schema in the database). The tool can be run via the included rd-reversemappingtool script, or through its Java class, com.solarmetric.rd.kodo.impl.jdbc.meta.ReverseMappingTool . Use the -package flag to control the package of the generated classes.

rd-reversemappingtool -package reversetutorial schema.xml

Running the tool will generate .java files for each generated class, .java files for corresponding JDO application identity classes, a reversemapping.jdo JDO metadata file, and a reversetutorial.mapping file.

The .mapping file generated by the reverse mapping tool is in an XML format used in Kodo's R&D codebase. In order to use the mapping information in current Kodo versions, we have to import it. To import mapping data, we use the aptly-named import tool. The tool can be invoked via the included rd-importtool script or through its Java class, com.solarmetric.rd.kodo.impl.jdbc.meta.compat.ImportTool . Make sure to compile the generated classes before the import:

javac *.java
rd-importtool reversetutorial.mapping

You can now delete the mapping file if desired.

Examine the generated persistent classes. Notice that the reverse mapping tool has used column and foreign key data to create the appropriate persistent fields and relations between classes. Notice, too, that due to the transparency of JDO, the generated code is vanilla Java, with no trace of JDO-specific functionality.

Also examine the generated application identity classes. Note that they satisfy all of the requirements for application identity classes mandated by the JDO specification, including the equals and hashCode contracts.

Finally, examine the reversetutorial.jdo metadata file. It contains the necessary standard JDO metadata, plus, thanks to our use of the import tool, the necessary Kodo JDO extensions to map the classes and their fields to the existing schema.