Edit Conflict Detection

[jri]

In a collaborative environment edit conflicts must be detected. That is, the server must reject PUT requests when the respective resource has been updated meanwhile. Conflict detection could be based on the timestamps also used for caching (see #478).

The Webclient must set the If-Unmodified-Since header in the PUT request. The server must compare that timestamp to the one stored in the DB (see #386) and respond with 412 (Precondition Failed) if indicated.

Conflict resolution is out of this ticket's scope.

[jri]

Time plugin: enrich with timestamp (#386, #479).

If the response contains a single DeepaMehtaObject? its composite model is enriched with a dm4.time.modified entry. The value is a UNIX timestamp. If the modification date is unknown the value is -1.

This way an object's timestamp is accessible at the Webclient application layer (client-side). It could be used for display or for setting the If-Unmodified-Since header in a conditional PUT request.

In preparation of #479 (Edit Conflict Detection).

See ticket 386.
See ticket 479.

Changeset: dfaa8f0ba4ee468cb589c267e41df7265bb2e016

[jri]

Caching plugin: edit conflict detection (#479).

The server rejects a PUT request when the resource has changed meanwhile. In this case the response is 412 (Precondition Failed). The check is based on the resource's "last modified" timestamp.

The Webclient makes a PUT request conditional by adding a If-Unmodified-Since header to it.

So the "edit conflict detection" feature is basically available. Issues remain.

2 requests are affected for the moment:

PUT /core/topic/{id}
PUT /core/association/{id}

See ticket 479.

Changeset: cae7a65c4f98c387f6f6ce2395f76d9630555a1d

[jri]

There is a bug: if a topic is just edited and the Edit button is pressed again the next PUT request fails with 412 (Precondition Failed). This is because the updated topic contained in the directives has no modification date set.

[jri]

Time and Caching fixes (#386, #478, #479).

FIXES

• Browser caching is enabled also for topics/associations which have no timestamp. 0 assumed as default (Jan 1, 1970).
• Edit conflict detection works also for topics/associations which have no timestamp.

CHANGES

Time plugin:

• for topics/associations send to the client their creation timestamp is available in the composite value as well (besides the modification timestamp).
• the time API's timestamp getter methods return 0 as default in case no timestamp is stored (before -1 has been returned).
• the Last-Modified response header is also set for a default timestamp value (0).

Caching plugin:

• a request's precondiction is also checked for a default timestamp value (0).

See #386.
See #478.
See #479.

Changeset: 1b5bbdb7c6b963915168f5a7c69e6ccb8a13d427