Set the com.solarmetric.kodo.impl.jdbc.Schemas configuration property to a comma-separated list of the names of the target database schemas. If you do not use use explicit database schemas, you can skip this step (in this case Kodo JDO will attempt to filter out system tables on its own; for example under Oracle it filters all tables with a schema of MDSYS, SYS, or SYSTEM).

Note that some databases require schema names to be in a certain case. If you are using Oracle, for example, your schema names must be in all upper case, regardless of what case you used when creating the schema.

Use the R&D schema generator to export your current schema to an XML schema file. The R&D schema generator can be run via the included rd-schemagen script or through its Java class, com.solarmetric.rd.kodo.impl.jdbc.schema.SchemaGenerator. For example:

rd-schemagen -properties myprops.properties -file schema.xml
				

Examine the generated schema file. JDBC drivers often provide incomplete or faulty metadata, in which case the file will not exactly match the actual schema. Alter the XML file to match the true schema. The DTD for the schema file is given here.

After fixing any errors in the schema file, modify the XML to include foreign keys between all related tables. The schema generator will have automatically detected existing foreign key constraints; many schemas, however, do not employ database foreign keys for every table relation. By manually adding any missing foreign keys, you will give the reverse mapping tool the information it needs to create the proper relations between the persistent classes it creates.

Run the reverse mapping tool on the finished schema file, supplying the package name for the generated classes. (If you do not supply the schema file to reverse map, the tool will run directly against the schema in the database; if you do not supply a package, the tool will generate classes without package declarations.) The tool can be run via the included rd-reversemappingtool script, or through its Java class, com.solarmetric.rd.kodo.impl.jdbc.meta.ReverseMappingTool. For example:

rd-reversemappingtool -properties myprops.properties -package com.xyz.jdo schema.xml
				

Running the tool will generate .java files for each generated class, a single <package-name>.jdo metadata file for the package, a <package-name>.schema file, and a <package-name>.mapping file. The schema file is there to show you what portion of the schema was mapped; it serves no other purpose and can be deleted if desired. The mapping file contains the O/R mapping information for the generated classes. Mapping files like these will be offered as an optional alternative to O/R metadata extensions in a future version of Kodo JDO. For now, you must import the mapping information into Kodo JDO metadata extensions.

To import the generated O/R mapping information into metadata extensions, run the R&D import tool on the mapping file. 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 -properties myprops.properties jdo.mapping
				

You can now delete the mapping file if desired.

Examine the generated classes and metadata, and modify them as necessary. Remember to register them with the schematool or list them in your persistent types property before use, as described here.