ListGrid: updateCaches doesn't work when grouping is active

[d.cavestro]

Calling DataSource.updateCaches doesn't reflect changes on a ListGrid bound to the DataSource when the ListGrid is grouping values on a column.

I've seen another user reported the same more than a year ago, but then forgot it.

The relevant cache update is triggered by

...
final Button button = new Button ("Update caches");
button.addClickHandler (new ClickHandler() {
    
    @Override
    public void onClick (ClickEvent event) {
        final DSResponse dsResponse = new DSResponse ();
        final DSRequest dsRequest = new DSRequest ();
        
        Record record = new Record (changingRecord.toMap ());
        record.setAttribute ("name", "row 2 with changed value!!!");
        dsResponse.setData (new Record [] {record});
        dsRequest.setOperationType (DSOperationType.UPDATE);
        dataSource.updateCaches (dsResponse, dsRequest);
    }
});
...

I'm going to attach a complete test case at [ATTACH]4840[/ATTACH] showing two listgrid that share the same datasource: the grouped one doesn't reflect the cache update, while the other do.
What's wrong with my code? Or is there any workaround?

Reproduced both with SmartGWT 3.0 LGPL and 3.1 [SmartClient Version: v8.3_2012-11-20/LGPL Development Only (built 2012-11-20)]

[Isomorphic]

Setting operationType on the dsResponse is required. Having done so, you do not need to provide a dsRequest at all.

[d.cavestro]

Setting operationType on the dsResponse is required. Having done so, you do not need to provide a dsRequest at all.

The issue persists removing dsRequest and setting operationType to UPDATE this way

...
record.setAttribute ("name", "row 2 with changed value!!!");
dsResponse.setData (new Record [] {record});
dsResponse.setOperationType (DSOperationType.UPDATE);
dataSource.updateCaches (dsResponse);

I've also tried almost every combination of setting/not setting operationType on request and/or response and also calling DataSource.updateCaches() (I could produce a truth table if needed) but the problem continues only on the table with grouping activated.

[Isomorphic]

The FAQ contains instructions on what to check on if a grid is not updating. If, after reviewing those possible problems, you think there's a framework bug here, please create a minimal, ready-to-run test case and we'll take a look.

[d.cavestro]

As I previously said, I attached on my first post a complete standalone test (at [ATTACH]4840[/ATTACH]) with two identical ListGrids sharing the same DataSource: the first grid has grouping on, the second has no grouping. Doing a cache update on the datasource a listgrid reflects the change, while the other not.
As you pointed out that example had no operationType set on the DSResponse (that was my fault), but even adding it (and also removing the DSRequest from the updateCaches call) does not resolve the issue.

At the moment I have no dev tools available so I cannot correct-check-and-repost the example, but some years ago I tested them and the issue remains.

I cannot say it's a framework bug, but the fact that two ListGrid varying only for the grouping have different behavior regarding updateCaches seems a bit strange...

BTW I'll repost a complete example ASAP

The FAQ contains instructions on what to check on if a grid is not updating. If, after reviewing those possible problems, you think there's a framework bug here, please create a minimal, ready-to-run test case and we'll take a look.

[Isomorphic]

A complete example is great, but you still need to look at the FAQ and look at causes. Otherwise you could be posting a complete example with a usage issue covered in the FAQ..

[d.cavestro]

A complete example is great, but you still need to look at the FAQ and look at causes. Otherwise you could be posting a complete example with a usage issue covered in the FAQ..

I've re-read carefully the FAQ, especially the "I saved data and my grid/tree/picker didn't update..." section.

Maybe I'm wrong, but it give no evidence of something wrong on my use case.

However it has been a very useful reading, cause setting the log level to Debug for ResultSet on the Dev Console I got this output

10:15:38.189:MUP0:WARN:Log:JSO::convertMapToJavascriptObject : skipping __ref in map
10:15:38.196:MUP0:DEBUG:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):dataSource data changed firing
10:15:38.196:MUP0:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):updating cache in place after operationType: update, allMatchingRowsCached true
10:15:38.199:MUP0:INFO:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):Updating cache: operationType 'update' (no componentID) ,1 rows update data:
[
{id: "2",
name: "row 2 with changed value!!!"}
]
10:15:38.204:MUP0:DEBUG:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):updated cache: 0 row(s) added, 1 row(s) updated, 0 row(s) removed.
10:15:38.213:MUP0:DEBUG:ResultSet:isc_ResultSet_1 (created by: isc_ListGrid_1):dataSource data changed firing
10:15:38.213:MUP0:INFO:ResultSet:isc_ResultSet_1 (created by: isc_ListGrid_1):updating cache in place after operationType: update, allMatchingRowsCached true
10:15:38.216:MUP0:INFO:ResultSet:isc_ResultSet_1 (created by: isc_ListGrid_1):Updating cache: operationType 'update' (no componentID) ,1 rows update data:
[
{id: "2",
name: "row 2 with changed value!!!"}
]
10:15:38.221:MUP0:DEBUG:ResultSet:isc_ResultSet_1 (created by: isc_ListGrid_1):updated cache: 0 row(s) added, 1 row(s) updated, 0 row(s) removed.
10:15:38.376:TMR2:DEBUG:ResultSet:isc_ResultSet_1 (created by: isc_ListGrid_1):getRange(0, 2) satisfied from cache

It seems interesting to me, cause it shows that the two listgrids operates the same way (in that their respectively ResultSets receive exactly one updated row) but only the listgrid that works properly (with no grouping) says

10:15:38.376:TMR2:DEBUG:ResultSet:isc_ResultSet_1 (created by: isc_ListGrid_1):getRange(0, 2) satisfied from cache

I'm going to attach the revised example used to produce the above logs: it basically triggers a cache update hardcoded as a change for the name field of the record with id=2.

Given the example, please note that on wathever ListGrid:
* if you enable grouping on the id column the cache update is NOT reflected on that ListGrid
* if you disable grouping the cache update is reflected on that ListGrid
* if you enable grouping on the name column the cache update is reflected on that ListGrid

[Isomorphic]

Thank you for the clear test case and description. We have investigated thoroughly and found there was indeed a bug here.
We have now resolved this in both the mainline (4.0d SmartGWT / 9.0d SmartClient) codebase and in the latest patch branch (3.1p SmartGWT / 8.3p SmartClient).

Please try the next nightly build dated Dec 18 and let us know if you continue to see this

Regards
Isomorphic Software

[Isomorphic]

For context, this issue would only affect a grid that was grouped on the primaryKey (which is why it hadn't come up before).

[d.cavestro]

Fix ok

Please try the next nightly build dated Dec 18 and let us know if you continue to see this

Your fix is ok for grids grouped on the primaryKey.
Sorry for the long delay (I've been out for a while).

Before holidays I've struggled - with no results at all - to isolate a reproducible test case for a similar problem on non-primaryKey grouping (as it seems I have some corner cases somewhat related).

In case I succeed in reproducing the potentially related problem I'll let you know.
Many thanks