Message-ID: <1367684414.1405.1369220345112.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1404_428760357.1369220345111" ------=_Part_1404_428760357.1369220345111 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This RnD page is set up to explore the pandora's box opened by t= he postgis-versioned module; and see it it can be cleaned up as a more gene= ral purpose solution suitable for use by geogit, arcsde, oracle and postgis= -versioned.
Table of contents:
This work is being undertaken by LISAsoft to define a datastore used to = store and access revisions. We have not chosen a backend at this time - the= following are under consideration:
Also for consideration:
The use of the word "version" changes between different back-e= nds - as such I will try and use the following in a consistent manner:
The module would need work to migrate to JDBC-NG (and discussion with Ju= stin as JDBC-NG classes are all marked final.
The details on migration to JDBC-NG are slightly off topic (although int= eresting) - as such a couple of options are listed below:
Option: Extend JDBCDataStore
Option: Modify JDBCDataStore - boil the concept of versioning into the J= DBCDataStore; an ability that would not be leveraged by the default impleme= ntations. For this to work:
Option: "Pure" DataStoreWrapper
This datastore captures:
The GeoGIT project is GPL; in part to make use of Binary XMl from the gv= Sig project.
Option: Ignore the project as not compatible with GeoTools / LGPL
Option: Ask for the project to be LGPL; and rewrite the binary XML part.= Conversation with Gabriel indicates this is around two months to do
Option: Ask for GeoGIT to to be LGPL: and ask gvSIG to release the binar= y XML part under some license we can use
We understand this project is only taking shape now; and follows a model= where a dataset can be "unpacked" into a normal DataStore. Even = with this model we would still need the ability to query revision history a= s per the VersioningDataStore API defined by postgis-versioning.
Justin is implementing WFS 2.0; as such there is a couple things we need= to keep in mind.
Q: Supports the concept of Version; not sure if that is the ArcSDE model= (ie a branch of the dataset); or trying to indicate a revision of a featur= e.
Q: Not sure how to query revision history (ie single feature; get the hi= storical changes)
Oracle supports "long term transaction support"; a model simil= ar to the ArcSDE concept of "versions". Update: They renamed the = functionality as "workspace manager".
For "versioned enabled tables":
Prior work from postgis-versioned module: