DataNucleus 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 datanucleus.autoCreateSchema provides a way of telling DataNucleus to do this. Thereafter, during calls to DataNucleus 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 datanucleus.autoCreateTables provides this, simply performing the tables part of the above.

If you want to create any missing columns that are required, the property datanucleus.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 datanucleus.autoCreateConstraints provides this, simply performing the constraints part of the above.

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

The property datanucleus.validateTables provides a way of telling DataNucleus 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 DataNucleus 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 datanucleus.validateColumns provides a way of telling DataNucleus 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 DataNucleus 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 datanucleus.validateConstraints provides a way of telling DataNucleus 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 DataNucleus requires (from the JDO Meta-Data definition) they would set this property to true .

DataNucleus 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 DataNucleus 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).