Ticket #547 (closed Defect: fixed)

Opened 7 years ago

Last modified 7 years ago

Cache Plugin prevents update of unselected topic/association

Reported by: dgf Owned by: jri
Priority: Major Milestone: Release 4.1.3
Component: DeepaMehta Standard Distribution Version: 4.1.1
Keywords: Cc: Malte, JuergeN
Complexity: 3 Area: Application Framework / API
Module: deepamehta-caching

Description

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

Change History

comment:1 Changed 7 years ago by jri

  • Status changed from new to accepted

Confirmed!
Thank you for reporting!

comment:2 Changed 7 years ago by jri

  • Cc Malte added

comment:3 follow-up: ↓ 4 Changed 7 years ago by 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.

  1. dm4c.do_update_topic() and dm4c.do_update_association() return the set of directives received from the server.
  1. dm4c.page_panel.get_displayed_object() is no longer a public method.

See #547.

comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 7 years ago by 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.

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 7 Changed 7 years ago by 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?

comment:6 Changed 7 years ago by 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.

  1. dm4c.do_update_topic() and dm4c.do_update_association() return the set of directives received from the server.
  1. dm4c.page_panel.get_displayed_object() is no longer a public method.

See #547.

comment:7 in reply to: ↑ 5 ; follow-up: ↓ 11 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by jri

  • Cc JuergeN added

comment:9 Changed 7 years ago by jri

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

Thanks, JuergeN, for reporting!

comment:10 Changed 7 years ago by 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.
  1. 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.
  1. 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.

comment:11 in reply to: ↑ 7 Changed 7 years ago by 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.

comment:12 Changed 7 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed

comment:13 Changed 7 years ago by 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

comment:14 Changed 7 years ago by Jörg Richter

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

Note: the Caching plugin depends on the Time plugin.

See #547.

Note: See TracTickets for help on using tickets.