Announcement

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

  • Blama
    replied
    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

    Leave a comment:


  • claudiobosticco
    replied
    Originally posted by Isomorphic View Post
    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.

    Leave a comment:


  • Isomorphic
    replied
    Originally posted by Blama View Post
    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.

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    Originally posted by Isomorphic View Post
    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

    Leave a comment:


  • claudiobosticco
    replied
    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?

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • Blama
    replied
    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

    Leave a comment:


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

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • Blama
    replied
    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

    Leave a comment:


  • claudiobosticco
    replied
    Fine, thank you very much for the clarification.

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • claudiobosticco
    replied
    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?

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:

Working...
X