There are 2 ways of modelling Sets in JPOX. The first is referred to as Normal, and the second as Inverse. These relate to the Single-Ended and Double-Ended variants of relationships defined in the 1-N Relationships Guide for example. These are described below.

In a Normal 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 Normal 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 Inverse 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.

There are 2 ways of modelling Lists in JPOX. The first is referred to as Normal, and the second as Inverse. These relate to the Single-Ended and Double-Ended variants of relationships defined in the 1-N Relationships Guide for example. These are described below.

In a Normal 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 Normal 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 Inverse 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 Normal 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.

There are 2 ways of modelling Maps in JPOX. The first is referred to as Normal, and the second as Inverse. These relate to the Single-Ended and Double-Ended variants of relationships defined in the 1-N Relationships Guide for example. These are described below.

In a Normal 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 Inverse 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.