Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.6.0-beta3
-
Fix Version/s: None
-
Component/s: Versioning
-
Labels:None
-
Number of attachments :
Description
The latest of sample request returns a SUCCESS code. In fact it does not update the date, which is what is intended, but at the same time it should throw an exception if the VersionedUpdate element featureVersion does not match the latest revision (meaning the client needs first to update, eventually handle conflicts locally, and then submit the change again).
Checked the code, it's not possible to actually implement the required behaviour without changes to the versioning interfaces themselves.
VersionedPostgisDataStore has a getLastRevision(): long method, but that exposes two implementation details of the versioning:
In fact, the very idea of a global number (at least per feature type) is required for an VersionedUpdate to make any sense... but if the versioning was based on CSV, each would have a different one.
So this is problematic. Stopping to work on this one until we get a clear picture of what versioning scheme can be used in practice, and how to deal with it in general.