|
Java Persistent Objects JDO (JPOX) defines a framework for persistence of data. This framework effectively defines 4 'modes' of working for a Java class. The developer selects their problem situation and this defines to a degree the way they use JDO in their system. This 'mode' of working applies on a table-by-table basis since they can have some tables existing (from a previous system for example) and have the JDO implementation generate some, and additionally have some tables identity column controlled by the JDO implementation and some defined by themself. The table below shows the 4 modes. All of these modes are supported by JPOX
These are described in more detail in the hyperlinked sections with reference to the Meta-Data required to select these modes. The first thing you need to decide before deploying your system with a JDO implementation is into which of these 'modes' each of your classes fit.
This is chosen when you have no legacy database, and so can allow the JDO implementation full control over the schema.
JPOX can be used to generate the schema before you run your application for the first time using
the SchemaTool utility, or you can set the property org.jpox.autoCreateSchema=true
(see the PMF Guide for details) so that the tables are created automatically when they are encountered.
Alternatively you can create the schema yourself manually - though this could be error prone because you would, in effect,
be second-guessing the types to be assigned by JPOX to columns.
This mode is chosen when you don't need/want to control the ids of your tables in your new schema. If you have a class
as follows
public class Person
{
protected String forename;
protected String surname;
}
you would define the Meta-Data for this as follows
<class name="Person" identity-type="datastore">
<field name="forename">
<column length="80" jdbc-type="VARCHAR"/>
</field>
<field name="surname">
<column length="100" jdbc-type="VARCHAR"/>
</field>
</class>
That is, you specify the identity-type as datastore. This is, strictly speaking not necessary
since this is the default identity-type.
This mode of operation is chosen when you want to control the ids of your tables (due to constraints on uniqueness
etc on the columns) within your new schema. If you have a class as follows
public class Person
{
protected int id;
protected String forename;
protected String surname;
}
you would define the Meta-Data for this as follows
<class name="Person" identity-type="application"
objectid-class="org.jpox.samples.PersonKey">
<field name="id" primary-key="true"/>
<field name="forename">
<column length="80" jdbc-type="VARCHAR"/>
</field>
<field name="surname">
<column length="100" jdbc-type="VARCHAR"/>
</field>
</class>
That is, you specify the identity-type as application and you specify your objectid-class
(the Primary Key class).
This is chosen when you have to support a legacy database schema and want to continue from the point you are at, and
with the data you already have. Your tables have their own primary keys already defined and so you must retain those.
This mode is chosen when you don't want to control the ids of your tables in your existing schema (other than that
they fit in with what is already inserted in the schema). To operate in this mode, you need to follow some rules
- Your table must have one and only one primary key column that can be mapped to a java.lang.Long. In general, the
database data types compatible are: INT, INTEGER, SMALLINT and other numeric data types.
- You must set the primary key column name (using the datastore-identity element at the class level in the
MetaData).
- Set the MetaData for your class to be datastore-identity
- Set the MetaData column names and table name and types to match exactly your existing table.
So to give an example, if you have a table with name "PEOPLE", with columns "CODE", "FIRSTNAME", "LASTNAME", (with
CODE being the primary key column of type INT), and a class as follows
public class Person
{
protected String forename;
protected String surname;
}
you would define the Meta-Data for this as follows
<class name="Person" identity-type="datastore" table="PEOPLE">
<datastore-identity>
<column name="CODE"/>
</datastore-identity>
<field name="forename">
<column name="FIRSTNAME" length="80" jdbc-type="VARCHAR"/>
</field>
<field name="surname">
<column name="LASTNAME" length="100" jdbc-type="VARCHAR"/>
</field>
</class>
This mode is chosen when you want to control the ids of your tables in your existing schema (as well as to fit in with
the data that is already there). To give an example, if you have a table with name "PEOPLE", with columns "CODE",
"FIRSTNAME", "LASTNAME", with code as the primary key column and a class as follows
public class Person
{
protected int id;
protected String forename;
protected String surname;
}
you would define the Meta-Data for this as follows
<class name="Person" identity-type="application" table="PEOPLE">
<field name="id" primary-key="true">
<column name="CODE"/>
</field>
<field name="forename">
<column name="FIRSTNAME" length="80" jdbc-type="VARCHAR"/>
</field>
<field name="surname">
<column name="LASTNAME" length="100" jdbc-type="VARCHAR"/>
</field>
</class>
In addition to the above general rules, if you have any columns in your existing table that are of non-standard types,
you may need to make use of the length and scale attributes of the column element.
Please refer to the Meta-Data Reference for details of these tags.
|
