This little design documents talks about the software design of the versioned datastore, hoping to ease the job of whoever tried to hack against the versioning postgis datastore, maybe to port it on top of another jdbc datastore (db2, hsql, and even Oracle, if you don't want to use the workspace managed facilities directly).

The database structure and approach are already described in a separate document, so the same information won't be repeated here.

Version enabling a JDBC datastore requires the following:

All the above must be obtained without adding too much complexity to the datastore that's getting version enabled, in order to allow seamless mantainance of the original data store.

The solution

General design

The postgis datastore could be version enabled in a few ways:

  1. by modifying it directly
  2. by subclassing it
  3. by wrapping it

The first solution would have been too risky, the Postgis datastore is our top notch datastore, so big changes are not welcomed.
The second one has been tried, but it has soon become evident that the JDBC datastore design does not allow for a split between internal and external vision, too many methods inherited from the base classes call other public methods, which is a problem because we do adversite user visible feature types that are not the ones available in the database.
So the implementation used the third solution, which has the following advantages:

The mappings

The following mappings are performed on the fly by the versioned datastore:

Handling identity

Usual FidMappers do not work properly in the versioned environment because we do have two identity concepts:

A new interface, VersionedFidMapper, has been created with extra methods that do map between external and internal ids, plus implementors must handle createId properly, that is, avoid creating a new id if the primary key columns have already been populated (something that the VersionedFeatureWriter does).