JPOX
JPOX
 Project  |  Ver 1.1  |  Ver 1.2  |  JDO  |  JPA  |  Guides  |  Tools
1.1 | Preparation | O/R Mapping | Runtime | Extensions | Developer
O/R Mapping
Relationships
JDO Containers

JDO supports the main types of Java containers :- Collections, Set, List, Map. In addition, JPOX also supports many of the java.util implementations of these collections :- HashSet, ArrayList, LinkedList, Stack, Vector, HashMap, Hashtable, and others. The choice of which to be used should always be based on what works more efficiently for your system, depending on how you want to use them.

This document defines how these are modelled by JPOX in the datastore. Where the Collection to be persisted is null at the point of persistence, JPOX will allow this and will create the necessary tables, just with no elements. In the diagrams below, the + symbol signifies that the column is part of the primary key of that table.

Container Lazy Loading

When you retrieve an object that contains a collection or map and that field is to be loaded, by default a wrapper for the collection or map will be created, but the elements/keys/values will not be loaded. They will be loaded when required. For example when you access the collection/map field and it requires the elements to perform the operation. This is referred to as lazy loading and is used because it provides the best performance for the majority of situations. You can change this behaviour by using PMF properties, or by specifying MetaData tags for the collection/map field.

Set

There are 2 ways of modelling Sets in JPOX. The first is referred to as Join Table, and the second as Foreign-Key. These relate to whether the mapping in the datastore is performed via a Join table or via a Foreign-key - obvious really!. These are described below.

In a Join Table Set model, JPOX creates a join table linking the owner class (which contains the Set) and the element class (which is contained in the Set). The join table contains the primary keys for the owner and element tables. Where either of these tables have composite primary keys, all parts of the composite key are added to the join table. This implementation does not support duplicate elements - due to the primary key uniqueness constraint on the join table





In a Join Table Set model and where the elements are primitive wrappers and so are embedded, an additional column ADPT_PK_IDX is added to the join table and is used in the primary key since the embedded (BLOB) field cannot be used for that. Where the owner table has composite primary keys, all parts of the composite key are added to the join table. This implementation does not support duplicate elements - due to the primary key uniqueness constraint on the join table





In an Foreign-Key Set model, JPOX adds the index(es) to the owner table in the element table. So each entry in the element table links to an element in the owner table. If the owner table has a composite primary key, all parts of the composite key are added to the element table. This implementation does not support duplicate elements - due to the fact that you are tagging an element against an owner.



Please refer to the 1-to-N relationships guide for Sets for details.



List

There are 2 ways of modelling Lists in JPOX. The first is referred to as Join Table, and the second as Foreign-Key. These relate to whether the mapping in the datastore is performed via a Join table or via a Foreign-key. These are described below.

In a Join Table List model, JPOX creates a join table linking the owner class (which contains the Set) and the element class (which is contained in the List). The join table contains the primary keys for the owner and element tables, as well as an index to identify the order in the List. This implementation will allow duplicates, by the fact that the IDX column is part of the primary key, and this will have different values for duplicate links between owner and element.





In a Join Table List model where the elements are embedded (primitive wrapper types), the join table contains the embedded field instead of a foreign key to the element table. This implementation will allow duplicates.





In an Foreign-Key List model, JPOX adds indices to the element table, so that it relates to the owner table, and also stores the index position in the List. Please note that this implementation will NOT, by default, allow duplicates. This is because it stores the element position in the element table. If you need a List with duplicates we recommend that you use the Join Table List implementation above. If you have an application identity element class then you could in principle add the element position to the primary key to allow duplicates, but this would imply changing your element class identity.



Please refer to the 1-to-N relationships guide for Lists for details.



Map

There are 2 ways of modelling Maps in JPOX. The first is referred to as Join Table, and the second as Foreign-Key. These relate to whether the mapping in the datastore is performed via a Join table or via a Foreign-key. These are described below.

In a Join Table Map model, JPOX creates a join table linking the owner class (which contains the Map) and the key and value classes (which are contained in the Map). The join table contains the primary keys for the owner, key and value tables. If the key is a field in the value class, then clearly a key table will not exist. If the key is embedded in the join table, then an additional column ADPT_PK_IDX will be added to the join table and used in the primary key since the embedded (BLOB) field cannot be used for that.





In an Foreign-Key Map model, JPOX adds an index to the key and values table, so that they relate to the owner table. If the key is a field in the value class, then clearly a key table will not exist.



Please refer to the 1-to-N relationships guide for Maps for details.