Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Module:

Versioning Postgis datastore

Module Maintainer:

Andrea Aime

Email Help:

Geotools-gt2-users@lists.sourceforge.net

Volunteer:

geotools-devel@lists.sourceforge.net

Status:

IP: (star), Releasable: (star), QA: (star), Stability: (red star), Supported: (star)

Model 

Versioning datastore design

User guide 

Versioning datastore user guide

Gold Star Quality Assurance Check:

(star) IP Check: need to ensure all headers are in place
(star) Releasable: no blocking issues, but feedback from potential users is appreciated
(star) Quality Assurance: 81.2% test coverage reported by clover
(red star) Stability: first release, API may still change in incompatible ways
(star) Supported: Documents available. Module maintainer does watches user list, answers email.

Target

Versioning Postgis datastore allows to version enabled one or more feature types stored in Postgis, extract features at a specific revision, log changes, rollback them, and extract differences.

Motivation

Geoserver is leading this effort in order to pursue the versioning WFS, a building block in the larger GeoCollaboration vision.

Target Audience

By being part of the GeoTools library, this datastore allows anyone to enjoy version control at the spatial data level.
In particular, this is compelling for the following use cases:

  • multiple editor scenarios, where editing cannot be strictly controlled;
  • map development, where a stable map needs to be published whilst a new version is being edited;
  • high performance or disconnected WFS editing, since versioning allows for checkouts, diffs and delayed changes commit (though not checkout format has been devised).

Quality Assurance

The module has high level of unit testing code coverage, 81.2% at the time of writing.
The datastore is supposed to handle both versioning and non versioning use cases, and has been designed to make versioning transparent to users, so the unit tests perform:

  • the same tests as the postgis data store, against a VersionedPostgisDataStore with no versioned feature types;
  • the same tests as the postgis data store, against a VersionedPostgisDataStore with all feature types versioned;
  • extra test to assess the versioning capabilities (specific version extraction, logs, diffing, rollbacks and the like).

Status

The module is in good health. No self or transient issues preventing it from compiling and passing tests.
Yet, this is the first release, so API may be subject to changes as we get feeback about what works for users.

  • No labels