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

[Blama]

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:
1) http://forums.smartclient.com/showth...20on%20grids#5
2) Then I read http://forums.smartclient.com/showth...p?t=8159#aGrid, which is the mentioned FAQ, as I believe.
3) It leads to http://www.smartclient.com/smartgwte...a.DSRequest%29, 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,
Blama

[Blama]

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
Blama

[Blama]

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
Blama

[Isomorphic]

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

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

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

Best regards
Blama