JPOX can generate the schema for the developer as it encounters classes in the persistence process. Alternatively you can use the SchemaTool application before starting your application.

If you want to create the schema during the persistence process, the property org.jpox.autoCreateSchema provides a way of telling JPOX to do this. Thereafter, during calls to JPOX to persist classes or perform queries of persisted data, whenever it encounters a new class to persist that it has no information about, it will use the MetaData to check the datastore for presence of the table, and if it doesn't exist, will create it. In addition it will validate the correctness of the table (compared to the JDO Meta-Data for the class), and any foreign key constraints that it requires (to manage any relationships). If any foreign key constraints are missing it will create them.

If you wanted to only create the tables required, and none of the constraints the property org.jpox.autoCreateTables provides this, simply performing the tables part of the above.

If you want to create any missing columns that are required, the property org.jpox.autoCreateColumns provides this, validating and adding any missing columns.

If you wanted to only create the constraints required, and none of the tables the property org.jpox.autoCreateConstraints provides this, simply performing the constraints part of the above.

JPOX can check any existing schema against what is implied by the JDO Meta-Data.

The property org.jpox.validateTables provides a way of telling JPOX to validate any tables that it needs against their current definition in the datastore. If the user already has a schema, and want to make sure that their tables match what JPOX requires (from the JDO Meta-Data definition) they would set this property to true. This can be useful for example where you are trying to map to an existing schema and want to verify that you've got the correct JDO Meta-Data definition.

The property org.jpox.validateColumns provides a way of telling JPOX to validate any columns of the tables that it needs against their current definition in the datastore. If the user already has a schema, and want to make sure that their tables match what JPOX requires (from the JDO Meta-Data definition) they would set this property to true. This will validate the precise column types and widths etc, including defaultability/nullability settings. Please be aware that many JDBC drivers contain bugs that return incorrect column detail information and so having this turned off is sometimes the only option (dependent on the JDBC driver quality).

The property org.jpox.validateConstraints provides a way of telling JPOX to validate any constraints (primary keys, foreign keys, indexes) that it needs against their current definition in the datastore. If the user already has a schema, and want to make sure that their table constraints match what JPOX requires (from the JDO Meta-Data definition) they would set this property to true.

JPOX will, by default, use the default database schema for the Connection URL and user supplied. This may cause issues where the user has been set up and in some databases (e.g Oracle) you want to write to a different schema (which that user has access to). To achieve this in JPOX you would set the runtime properties

javax.jdo.mapping.Catalog={the_catalog_name}
javax.jdo.mapping.Schema={the_schema_name}

This will mean that all RDBMS DDL and SQL statements will prefix table names with the necessary catalog and schema names (specify which ones your datastore supports).

There are occasions where the user has data in a datastore and they don't have write permission to that area. In this situation they do not want their persistence framework to try writing to the datastore since it will undoubtedly end in failure. JPOX caters for all of the 3 common situations.

• User can update schema and can write to the tables - this is the default situation that JPOX handles and the user doesn't have to specify anything here.
• User cannot create tables, but can write to the tables - this situation can be realised by specifying the PMF property org.jpox.fixedDatastore as true. This will prevent all attempts to create/drop tables in the schema.
• User cannot create tables, and cannot write to the tables - this situation can be realised by specifying the PMF property org.jpox.readOnlyDatastore as true. This will prevent all attempts to create/drop the tables and will throw a JDOFatalUserException when the user calls makePersistent/deletePersistent. That is, only queries can be performed.

JPOX provides an additional control over behaviour when using a read-only datastore. The default behaviour when the datastore is read-only and an object is attempted to be persisted is to throw an exception. You can change this using the PMF property org.jpox.readOnlyDatastoreAction with values of "EXCEPTION" (default), and "IGNORE". "IGNORE" has the effect of simply ignoring all attempted updates to readonly objects. This is available from JPOX 1.1.8.