saveAllEdits removes edited Record from ListGrid

[tece321]

SmartClient Version: v10.0p_2015-11-20/PowerEdition Deployment (built 2015-11-20)

I have just switched from 4.1 SmartClient to 5.0 version, dated 2015-11-20 as above and see this change in behavior.

I have a ListGrid with 3 records in it. One of the columns in one of the records gets edited / changed. autoSave is FALSE on the ListGrid. On clicking a save button a saveAllEdits( new Callback () {} ); is executed. Before execution of the saveAllEdits the number of records is seen to be 3. On entry into the Callback of saveAllEdits the number of records is 2, with the just correctly updated record removed from the Grid. ListGrid.getRecordList() returns the two unmodified records.

Before I attempt to recreate the issue in a test case, is this the expected behavior in 5.0 ? Is this different from 4.1 ?

[Isomorphic]

Way too little information to tell, but possible causes would include the Record no longer matching the criteria applied to the grid, or a bad response from your server code, which either doesn't include the record-as-saved, or has bad data in some way.

[tece321]

Okay. Certainly the update is successful as I can see in the server debug, and the console. It returns only those updated columns in the DSResponse. I will continue to debug. Just wanted to see if you might acknowledge if behavior may have changed.

[Isomorphic]

Returning only the updated columns would be wrong (in any version). The complete record should be returned.

[tece321]

Way too little information to tell, but possible causes would include the Record no longer matching the criteria applied to the grid, or a bad response from your server code, which either doesn't include the record-as-saved, or has bad data in some way.

Okay I have isolated the problem to the following line of code:

If my code, before the saveAllEdits() call, contains the line:

waiversDetailGrid.setEditValue(rows[i],"markedAsDeleted", false);

then on return from the saveAllEdits the row[i] will be deleted from the Grid. If I simply remove the line, the saveAllEdits() returns the full record list of the grid.

The saveAllEdits() is calling a server side DMI to process the records, which somewhere in the past used to look at a record attritbute "markedAsDelete" but no longer does. But simply putting this attribute on the record, even set to false, causes the record to be delete from the grid. Smells like a bug?

[Isomorphic]

Unfortunately this new information doesn't lead to any new theories, and is very far from suggesting a framework bug. Returning to what we said before:

... possible causes would include the Record no longer matching the criteria applied to the grid, or a bad response from your server code, which either doesn't include the record-as-saved, or has bad data in some way.

So, with respect to this markedAsDeleted property and the fact that you've noticed it influences your application's behavior:

1. maybe you have criteria that target this property

2. maybe your server response is different when this property is set

[tece321]

but possible causes would include the Record no longer matching the criteria applied to the grid, or a bad response from your server code, which either doesn't include the record-as-saved, or has bad data in some way.

Yes the markedAsDeleted attribute of the updated records was a red-herring.

I changed the server side code to include in the returned Data List of the update, the attributes (columns) base Criteria applied to the grid. The fields of the grid's criteria were not included in the Update data set sent down by the saveAllEdits() manager. They were in the OldValues Map. Seems like one has to copy the Grid criteria from the OldValues to the returned Data List of the update. Or one has to make sure the update data sent by saveAllEdits includes the base Grid's criteria.

This seems to be different behavior from 4.1. Can you confirm?

[Isomorphic]

No, grids have always sent just the updated fields as part of the update data, with the original values from the record in "oldValues".

If there's a behavior change in the framework here, it may be that a bug was corrected where the saved data would include fields that were not actually changed. But there's too little information here to pin that down.

Regardless, your changes to your server code now make it correct per docs (for any version of SmartGWT), because it should never have assumed dsRequest.data had the complete record.

Note also that oldValues specifically contains the original values of the Record - it's not that the grid's criteria are added, it's just that any record the user is editing is going to match the grid's criteria, so for simple criteria, the oldValues will have values that match the grid criteria.

[tece321]

Looking at my code again I noticed that a hack I made ilast week where I saved off the updated state of the records in the Grid, and then used the saved state in a setData(Reocord [])) following the update to restore the grid was still present. I removed the hack and I now get the following result.

The Update operation sends down just the changed values. The server side returns a Record List containing just the changed columns of the grid, along with the value of the current Criteria of the grid in each Record member of the Grid. The Grid refreshes, Grid.markForRedraw(), displaying ONLY the changed/edited columns. All the other columns are now blank in the grid.

The original issue where the edited row completely disappears no longer happens. The row is displayed, but only the edited columns.

Is the Server side expected to return the entire getOldValues() data set with the merged getValues() data set in the Update response. Does this explain why the grid refresh is only displaying the changed values?

What is supposed to be returned in the Update data set? Yes I have read and read the Interface Editing section of the docs and don't see an explanation of the this behavior.

[Isomorphic]

"update" and "add" operations are both expected to return the record-as-saved - not updated values plus criteria, the complete record. This has been the case since before SmartGWT was first released, so if you are trying to figure out if a framework behavior change is affecting you, this definitely wouldn't be it :)

Note this is also covered in the Data Integration chapter of the QuickStart Guide (where the contents of the DSResponse are first explained) and then reiterated in various parts of the reference (eg dsResponse.data member). It's not reiterated in the Grid Editing overview because it's not specific to grid editing - it's a system-wide behavior of DataSources regardless of what component uses them.