 |  |
 |
| JPOX Version 1.0 |  |  |
| Configuration | Tutorials | Worked Examples | Developer |
 |
Many JDO implementations add various types of information to the tables for persisted classes, such as special columns, or meta information. JPOX is very unobtrusive as far as the datastore schema is concerned. It minimises the addition of any JDO artifacts to the datastore, and adds nothing (other than any datastore identities) to any schema tables. The only thing that JPOX does add to the schema is a single table that stores information about the classes being persisted. As discussed in the JDO Mode Guide, JPOX can persist to a datastore that already contains a schema, or alternatively can create the datastore schema for you. It can exist alongside existing tables leaving them untouched. It is not necessary to have a database specifically for JPOX.
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 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.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 property org.jpox.identifier.defaultSchemaName={the_schema_name}This will mean that all RDBMS DDL and SQL statements will prefix table names with this schema name.
When JPOX runs it really needs to know about the classes that it was responsible for persisting the previous time it ran. Without this knowledge it would have to 'discover' these classes again. To achieve this it uses an Auto Start Mechanism. This is set with the property org.jpox.autoStartMechanism. This can be set to None or SchemaTable. With None, JPOX doesn't attempt to store any information about what it was handling, hence the next time it runs it learns about the persisted classes from scratch. With SchemaTable, JPOX stores the list of classes (and their tables, types and version of JPOX) in a datastore table JPOX_TABLES. This table is read at startup of JPOX, and provides JPOX with the necessary knowledge it needs to continue persisting these classes. This table is continuously updated during a session of a JPOX-enabled application. If the user changes their persistence definition a problem can occur when starting up JPOX. JPOX loads up its existing data from JPOX_TABLES and finds that a table/class required by the JPOX_TABLES data no longer exists. There are 3 options for what JPOX will do in this situation. The property org.jpox.autoStartMechanismMode defines the behaviour of JPOX for this situation.
|
|