Cache Plugin prevents update of unselected topic/association

[dgf]

since the introduction of the Cache Plugin in version 4.1.1, only selected topics and associations can be updated

a webclient call like this

dm4c.do_update_association(anUpdatedAssociation)

is prevented by the Cache Plugin

uncaught exception: ID mismatch when preparing conditional PUT
request (/core/association/4841): the page panel displays object 4728

[jri]

Confirmed!
Thank you for reporting!

[Jörg Richter]

Caching plugin: update unselected objects (#547).

The Caching plugin no longer prevents updating topics/associations which are not selected (and thus appearing in the page panel).

A plugin can call dm4c.do_update_topic() and dm4c.do_update_association() for arbitrary topics/associations.

IMPORTANT: it is required that the topic's/association's last modified timestamp is stored in the composite property of the passed topic/association model.
Note: when retrieving a topic/association from the server, manipulating it in-place, and pass it back to dm4c.do_update_..() this requirement is already met.

IMPORTANT: in order a 2nd update request on the same object works the plugin must ensure to involve the up-to-date timestamp as contained in the response of the 1st update request. To enable a plugin to access this timestamp the dm4c.do_update_topic() and dm4c.do_update_association() methods now return the set of directives as received from the server. The plugin must scan the directives for UPDATE_TOPIC/UPDATE_ASSOCIATION.

Background is Edit Conflict Detection as introduced in DM 4.1.1. Edit Conflict Detection relies on an object's "last modified" timestamp. So a plugin who wants perform an update request must state the object "version" (in term of the timestamp) to which the request is bound. If there is meanwhile a newer version available on the server the request is rejected. This solves the "lost update problem". So, along with the feature of Edit Conflict Detection a plugin can no longer issue arbitrary update requests while possibly overridng changes performed by others.

CHANGES

1. New client-side event:

   pre_submit_form(object, new_object_model)
   

   It is fired before the standard page renderers (Topic Renderer and Association Renderer) submits the form input. 2 arguments are passed:

object -- the original object being edited (Topic or Association as received from the server, including e.g. its timestamps)
new_object_model -- the object model build from the user's form input that is about to be send to the server.

2. dm4c.do_update_topic() and dm4c.do_update_association() return the set of directives received from the server.

3. dm4c.page_panel.get_displayed_object() is no longer a public method.

See #547.

• Changeset: eee72fe627d72fc58fcd8f7f9d42902f2f4169c6
• URL: ​https://github.com/jri/deepamehta/commit/eee72fe627d72fc58fcd8f7f9d42902f2f4169c6

[jri]

Replying to Jörg Richter:

IMPORTANT: in order a 2nd update request on the same object works the plugin must ensure to involve the up-to-date timestamp as contained in the response of the 1st update request. To enable a plugin to access this timestamp the dm4c.do_update_topic() and dm4c.do_update_association() methods now return the set of directives as received from the server. The plugin must scan the directives for UPDATE_TOPIC/UPDATE_ASSOCIATION.

Clarification: this is required only if your plugin holds a topic/association instance in memory at client-side and wants to perform several update requests on it without retrieving it again.

In case of dm4-mail's onRecipientTypeSelect() it is probably easier to perform the association update at server-side by providing a RESTful setRecipientType(mailId, recipientId, recipientType) method. This would also provide for a higher-level "semantic" API.

[jri]

Replying to jri:

In case of dm4-mail's onRecipientTypeSelect() it is probably easier to perform the association update at server-side by providing a RESTful setRecipientType(mailId, recipientId, recipientType) method. This would also provide for a higher-level "semantic" API.

Is this what your MailService?'s associateRecipient() method already does? Would JAX-RS annotations be sufficient?

[Jörg Richter]

Caching plugin: update unselected objects (#547).

The Caching plugin no longer prevents updating topics/associations which are not selected (and thus appearing in the page panel).

A plugin can call dm4c.do_update_topic() and dm4c.do_update_association() for arbitrary topics/associations.

IMPORTANT: it is required that the topic's/association's last modified timestamp is stored in the composite property of the passed topic/association model.
Note: when retrieving a topic/association from the server, manipulating it in-place, and pass it back to dm4c.do_update_..() this requirement is already met.

IMPORTANT: in order a 2nd update request on the same object works the plugin must ensure to involve the up-to-date timestamp as contained in the response of the 1st update request. To enable a plugin to access this timestamp the dm4c.do_update_topic() and dm4c.do_update_association() methods now return the set of directives as received from the server. The plugin must scan the directives for UPDATE_TOPIC/UPDATE_ASSOCIATION.

Background is Edit Conflict Detection as introduced in DM 4.1.1. Edit Conflict Detection relies on an object's "last modified" timestamp. So a plugin who wants perform an update request must state the object "version" (in term of the timestamp) to which the request is bound. If there is meanwhile a newer version available on the server the request is rejected. This solves the "lost update problem". So, along with the feature of Edit Conflict Detection a plugin can no longer issue arbitrary update requests while possibly overridng changes performed by others.

CHANGES

1. New client-side event:

   pre_submit_form(object, new_object_model)
   

   It is fired before the standard page renderers (Topic Renderer and Association Renderer) submits the form input. 2 arguments are passed:

object -- the original object being edited (Topic or Association as received from the server, including e.g. its timestamps)
new_object_model -- the object model build from the user's form input that is about to be send to the server.

2. dm4c.do_update_topic() and dm4c.do_update_association() return the set of directives received from the server.

3. dm4c.page_panel.get_displayed_object() is no longer a public method.

See #547.

• Changeset: eee72fe627d72fc58fcd8f7f9d42902f2f4169c6
• URL: ​https://github.com/jri/deepamehta/commit/eee72fe627d72fc58fcd8f7f9d42902f2f4169c6

[dgf]

Replying to jri:

Is this what your MailService?'s associateRecipient() method already does? Would JAX-RS annotations be sufficient?

it would be an option, but the intention is to use the WebClient core. IMO the only way to get an up to date map view.

Replying to jri:

The plugin must scan the directives for UPDATE_TOPIC/UPDATE_ASSOCIATION.

A grep and reassign of the updated association enables an in-line edit with instant refresh of the topic map. It works, Thx.

[jri]

Topic Retyping does not work anymore since the Caching fix 3 days ago.

Thanks, JuergeN, for reporting!

[Jörg Richter]

Caching module: fix retyping (#547).

CHANGES

The Caching module's strategy for determining the last modification timestamp known at client-side (to be used for the If-Unmodified-Since request header) when performing a PUT request is extended:

1. if the object contained in the update request has already a timestamp (in its composite property) that one is used.

2. if not, it is checked weather the object contained in the update request is the same as currently displayed in the page panel (based on ID match), the page panel object's timestamp is used.

3. if the IDs do not match an exception is thrown at client-side and the request is not send.

New is step 2.
This means the caller of dm4c.update_topic() or dm4c.do_update_association() is not required to include a timestamp in the object to be updated as long as this object is currently displayed in the page panel.

dm4c.page_panel.get_displayed_object() is again a public method.

See #547.

• Changeset: a2b8d8f09636c21b6582d30cefc3e72bda32f8ea
• URL: ​https://github.com/jri/deepamehta/commit/a2b8d8f09636c21b6582d30cefc3e72bda32f8ea

[jri]

Replying to dgf:

Replying to jri:

Is this what your MailService?'s associateRecipient() method already does? Would JAX-RS annotations be sufficient?

it would be an option, but the intention is to use the WebClient core. IMO the only way to get an up to date map view.

Yes, you are right: when you do it server-side the directives returned by your resource method would not be processed at client-side. I remember, you told me that already a while ago.

This rises an interesting issue/requirement, which is now addressed in #556. I want realize that very soon. This would provide for both then: a server-side domain-specific (mail) service, and an in-sync topicmap view at client-side. In my opinion this is the way to go.

Replying to jri:

The plugin must scan the directives for UPDATE_TOPIC/UPDATE_ASSOCIATION.

A grep and reassign of the updated association enables an in-line edit with instant refresh of the topic map. It works, Thx.

Great!
It works for me as well.

[Jörg Richter]

Caching fix: regard 0 as valid timestamp (#547).

The Caching module regards 0 as a valid timestamp. Note: the server sends 0 as the default timestamp for objects which don't have a timestamp. This happens e.g. when upgrading from a DM 4.1 installation. Timestamps were introduced only in DM 4.1.1

Thank you very much, Malte, for testing the upgrade scenario!

See #547

• Changeset: e7d121406e06919ced4839094aa145c50db7b0a7
• URL: ​https://github.com/jri/deepamehta/commit/e7d121406e06919ced4839094aa145c50db7b0a7

[Jörg Richter]

Caching: fix and improve error reporting (#547).

Note: the Caching plugin depends on the Time plugin.

See #547.

• Changeset: 55906589c45a66e95e867f11a6585fb0329b9bdc
• URL: ​https://github.com/jri/deepamehta/commit/55906589c45a66e95e867f11a6585fb0329b9bdc