[Blama]

Hi Isomorphic,

thanks for adding the block

Regarding operationIds and how they affect caching, take into account that cache sync is based on the fetch used - any add or update operation uses a fetch to retrieve updated data, and the operationId of that fetch can be set via cacheSyncOperation. If the operationId of the cache is different from the operationId of the cache update data, it won't be used to update the cache, since the fields included and other aspects of the data are allowed to be different across different operationIds. This allows to maintain distinct caches on a per component basis, so when two components are using separate operationIds they are assumed to have distinct caches, because updates performed with one operationId will not affect the cache obtained via another operationId. Also, take into account that operationId must be unique per DataSource, across all operationTypes for that DataSource.

Very helpful. Perhaps the Quick Start Guide can link/refer to this as well.

Best regards
Blama

[claudiobosticco]

claudiobosticco: transformResponse is not triggered for the relatedUpdates, as they are themselves only partial DSResponses, and code designed to handle normal DSResponses could easily fail to handle them.

Thanks for the clarification, I've moved the transformation in a DMI method.

[Isomorphic]

Hi Isomorphic,

were the docs really updated? Searching for cacheSync does not give hits in the upper part of the docs.

Best regards
Blama

The issue with the stale SGWT javadocs for ResultSet has been resolved. The improved content should make it onto the website by tomorrow.

[Isomorphic]

claudiobosticco: transformResponse is not triggered for the relatedUpdates, as they are themselves only partial DSResponses, and code designed to handle normal DSResponses could easily fail to handle them.

[Blama]

Hi Isomorphic,

You can find the documentation regarding cache synchronization under the "Updates and Automatic Cache Synchronization" section of the ResultSet class overview, where we have elaborated further about operationId based on this post's discussion. You'll find it updated in tomorrow's nightly build.

were the docs really updated? Searching for cacheSync does not give hits in the upper part of the docs.

Best regards
Blama

[claudiobosticco]

Hello, while using DataSource.transformResponse() as suggested, I've noticed that when arrives a 'relatedUpdate' on that dataSource, the transformResponse method is not triggered. No operation ids involved, only default fetches.
Is it expected?

[Isomorphic]

You can find the documentation regarding cache synchronization under the "Updates and Automatic Cache Synchronization" section of the ResultSet class overview, where we have elaborated further about operationId based on this post's discussion. You'll find it updated in tomorrow's nightly build.

[Blama]

Hi Isomorphic,

all the information I needed, thank you.
Perhaps this is something for the CacheSync-docs. Or is it already documented somewhere?

Best regards
Blama

[Isomorphic]

Oh, and operationId must be unique per DataSource, across all operationTypes for that DataSource.

[Isomorphic]

Cache sync is based on the fetch used - any add or update operation uses a fetch to retrieve updated data, which can be set via operationBinding.cacheSyncOperation. If the operationId of the cache is different from the operationId of the cache update data, it won't be used to update the cache, since the fields included and other aspects of the data are allowed to be different across different operationIds.

[Blama]

Hi Isomorphic,

could you explain how ResultSet caching / application to DataBoundComponents is done? Your last posts makes me wonder a bit.

Until now, I (not the OP) thought that there is only one cache per DataSource, e.g.

1. LG1: fetch operationId1 (with some criteria on the server) -> Result 1
2. LG2: fetch operationId2 (with some other criteria on the server) -> Result 2
3. Update in one ListGrid -> Response will be incorporated in both ListGrids, no matter what

Is there some way to stop this behavior, perhaps by having

• operationBinding: type="fetch" operationId="op1"
• operationBinding: type="update" operationId="op1" (same operationId as for fetch above)
• operationBinding: type="fetch" operationId="op2"
• operationBinding: type="update" operationId="op2" (same operationId as for fetch above)

resulting in DSResponses from update:op1 only affecting ListGrids with current data for fetch:db1 and
DSResponses from update:op2 only affecting ListGrids with current data for fetch:db2?

Further: Should an operationId be unique per DataSource or per DataSource+Type?
Which docs cover this best?

Thank you & Best regards
Blama

[claudiobosticco]

Fine, thank you very much for the clarification.

[Isomorphic]

Reading it is fine, just bear in mind, when two components are using separate operationIds they are assumed to have distinct caches: updates performed with one operationId will not affect the cache obtained via another operationId. With two different componentIds, this is not the cache: any changes will update all caches.

[claudiobosticco]

Ok, but I did not intend to set dsRequest.componentId. I intend to read it in transformResponse to distinguish which grid has issued the dsRequest. Is it a valid usage or I must rely only on operationId?

[Isomorphic]

It's never valid to set dsRequest.componentId, it's doc'd as read-only. So operationId is the way to go if for some reason you need different data on refresh of different grids.