This page last changed on Mar 26, 2008 by sewilco.

Transaction modifications for versioning need to consider that a server will probably serve both versioned and non versioned feature types, possibly have multiple versioned datastores, and that clients using the plain WFS protocol should be allowed to participate and work against a versioned WFS too, so modifications need to be minor, and optional. In particular, there is a need for:

  • a place where commit message can be specified (optional).
  • returning the new revision information.
  • handling rollbacks and merges
  • handling conflicts, at least against clients that do know about versioning.

The commit message can be stored into the Transaction handle attribute. Whilst this bends a little its intended usage, it also provide a reference message for clients that are unaware of versioning, but that do set some handle message for the sake of error reporting.

New revision information in the response can be stored among the Action elements of a response, since they are designed to carry generic messages too. It would be something like:

<wfs:TransactionResponse ...>
    <wfs:Action code="revision" locator="The handle provided in the Transaction request">

Rollback and merges can be handled with new elements that leverage the vendor extension mechanisms for Transaction elements. The new RollbackElementType would be very similar to the DeleteElementType, with a typename and a filter, and would require just the specification of the rollbackTo revision as an extra attribute.

<xsd:element name="Rollback" type="wfsv:RollbackType" substitutionGroup="wfs:Native">
   <xsd:complexType name="RollbackType">
         <xsd:extension base="wfs:NativeType">
               <xsd:element ref="wfsv:DifferenceQuery" minOccurs="1" maxOccurs="1"/>
            <xsd:attribute name="handle" type="xsd:string" use="optional"/>
            <xsd:attribute name="user" type="xsd:string" use="optional"/>

The filter allows to select which features need to be rolled back. This allows for rolling back
changes in a specific area, or with other specific characteristics. The user attribute allows
for gathering only the changes performed by a specific user, so it acts like a filter, but it's separate since the user id is not among the feature type attributes.

Finally, let's handle conflicts.
Version control system usually do not allow to commit a change if the server state changed in the meantime, and that's a very basic security measure to avoid losing changes and prevent conflicts.
But in our case, we do want to support versioned WFS unaware clients, so bypassing that mechanism is easy: we have to accept calls that do not specify a reference revision, allowing the overwrite of changes performed between GetFeature and Transaction (unless the client did set a Lock). A configuration parameter should also allow administrators to put unaware clients out of the game, since these unchecked calls are dangerous for data consistency.
Aware clients can leverage extra checks by setting a featureRevision on their update/delete elements, and the server should throw an exception if xxx is not the last revision for the features hit by the update/delete filters. This means the approach is to allow clients to leverage extra check, but without enforcing them.
The extended transaction elements would be:

<xsd:complexType name="VersionedUpdateElementType" >
         <xsd:extension base="wfs:UpdateElementType">
            <xsd:attribute name="featureVersion" type="xsd:string" use="required">
   <xsd:complexType name="VersionedDeleteElementType" >
         <xsd:extension base="wfs:DeleteElementType">
            <xsd:attribute name="featureVersion" type="xsd:string" use="required">
Document generated by Confluence on May 14, 2014 23:00