Message-ID: <701002.3605.1369394547831.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3604_624171971.1369394547831" ------=_Part_3604_624171971.1369394547831 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This little design documents talks about the software design of the vers= ioned datastore, hoping to ease the job of whoever tried to hack against th= e versioning postgis datastore, maybe to port it on top of another jdbc dat= astore (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 manta= inance of the original data store.
The postgis datastore could be version enabled in a few ways:
The first solution would have been too risky, the Postgis datastore is o=
ur 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 ty= pes that are not the ones available in the database.
So the implementation used the third solution, which has the following adva= ntages:
The following mappings are performed on the fly by the versioned datasto= re:
revision<= /code> as well);
Usual FidMappers do not work properly in the versioned environment becau= se 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 hand= le createId properly, that is, avoid creating a new id if the primary key c= olumns have already been populated (something that the VersionedFeatureWrit= er does).------=_Part_3604_624171971.1369394547831--