No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Advice and question on DSResponse.addRelatedUpdate() with additional "fetch"-Requests

    Hi Isomorphic,

    I had a strange problem with the following use case:
    1) client: update-request from a from.
    2) server-side: executing the request + additional *fetch* one row (WHERE pk = 123, in same transaction) from a DataSource (accessing a view) depending on the updated row.
    3) addRelatedUpdate on the 1st request.
    4) return 1st request with the relatedUpdate.

    In result I can see the data arrived at the client side via the ResultSet and RPCManager in the Developer Console, but the ListGrid showing the row from the DataSource/view doesn't update itself. A PK is set in the view's ds.xml.

    So I started searching and found this:
    2) Then I read, which is the mentioned FAQ, as I believe.
    3) It leads to, which includes this fragment
    The provided DSResponse should have operationType "update", "add" or "remove" - there is no way for a "fetch" response to meaningfully update arbitrary caches. However, if you have a list of updated records (possibly retrieved via DataSource.fetchData) you can call updateCaches() multiple times with DSResponses of type "update" formed from the list of records retrieved via fetchData().
    It further says
    As an alternative to calling updateCaches() directly, if updates to other DataSources occur as a result of server-side logic, you can use the server-side API DSResponse.addRelatedUpdate(DSResponse) (Pro Edition and above), which ultimately calls updateCaches() for you - see that method's documentation for details.
    So I figured out that my fetch to the view's DS is not enough and did the following:
    DSResponse additionalResponse = additionalResponse.execute(); //fetch request
    [B]additionalResponse = additionalResponse.setOperationType("update");[/B]
    response = response.addRelatedUpdate(additionalResponse);
    return response;
    This works like a charm, but was really not easy to find out. My question if this is the correct and suggested appoach.

    Just from curiosity: Why doesn't the framework update the ListGrid for a fetch?
    Responses for "add" and "update" should be almost the same as for "fetch". For "remove" I'm not that sure, but it should be possible to update a ResultSet accordingly for 1)"SELECT * FROM table WHERE pk = 123" -> 2) 0 rows returned -> 3) remove row from client-side ResultSet and update dependent databound components.

    Thanks for advising. If my approach is really the correct one, it would be great if you could add the information that one normally should not do addRelatedUpdate for (unmodified) fetches. I hope that this thread helps other people as well.

    Thank you & Best regards,

    Hi all,

    to answer my own old question: The approach with additionalResponse.setOperationType("update") is correct.
    Isomorphic: It would be great if you included a note in the docs that chaining a fetch-DSResponse with DSResponse.addRelatedUpdate() will most likely not have the intended effect.

    Best regards


      Hi Isomorphic,

      thinking about it, wouldn't it make sense to warn on the client side in the Developer Console if the client receives a relatedUpdate with fetch-operationType?

      Best regards


        We've made a change to warn users about this case. Please try the next nightly build, dated Dec 05.

        Isomorphic Software


          Hi Isomorphic,

          great, thank you. Let's hope that I never see that warning :)

          Best regards