Announcement

**Isomorphic** · 15 Nov 2012, 13:04

As already covered over email:

It looks like you are trying to do a multi-record update by simulating the end user editing 1000s of records. This would be extremely inefficient if it works at all - instead, just do a multi-record update directly.

You can do an "update" DSRequest that affects multiple records by setting allowMultiUpdate:true.

**tamt** · 15 Nov 2012, 13:35

Dear support:

Just to understand the response correctly, are you stating that there is a performance limitation with the "mass update" framework? If so, what is the recommended maximum amount of records which can be pended prior to calling saveAllEdits().

I have another issue that I have not posted yet where at 2500 records, I am getting script hanging warnings from Internet Explorer and it seems that the framework is looping around trying to process the saveAllEdits().

My code is following the mass update example in the showcase and I wasn't expecting any issues. Is there any examples of an update operation available which involves the use of "allowMultiUpdate".

Finally, why isn't the "mass update" framework doing a multi-record update on a saveAllEdit() in the first place? Is there a way to have the framework do this instead of refactoring my code to manually do a updateData() call from the listgrid?

Thanks, T.

**Isomorphic** · 15 Nov 2012, 13:39

The maximum number of records that will work will differ by browser. As you can see you are already hitting the limits for IE, which are generally the lowest.

Again, the editValues system is for saving user edits. The "Mass Update" same shows appropriate usage: allowing an end user to modify several records.

Users do not edit 2500 individual records and then save all at once. What you are really doing is programmatic changes to a whole set of records, so you should represent this operation as a single update that affects multiple records (via allowMultiUpdate).

No, there is not currently a dedicated sample for allowMultiUpdate, it's a bit too trivial for that: just call setAllowMultiUpdate() and call setCriteria() with whatever criteria you want.

**tamt** · 15 Nov 2012, 14:26

Dear support:

The approach that you recommend is not that trivial since my listgrid is databound to my data source.

If I call updateData from the listgrid, the signature of the method is:

public void updateData(Record record,
DSCallback callback,
DSRequest requestProperties)

Do I set the record as null and perform setValues() in the DSRequest? Would this even work at all? The updateData method in listgird seems to be tailored to a single record.

Alternatively, are you suggesting that I bind to my datasource outside of the listgrid and perform the update from there?

Cheers, T.

**Isomorphic** · 15 Nov 2012, 14:34

From what you've shared, this update is pretty much unrelated to the grid or to end user editing, it's just a programmatic update. So there doesn't appear to be a reason to go through the grid at all.

Since this is not a CRUD operation in the usual sense of affecting just one record, the easiest way to do this is probably via DataSource.performCustomOperation() and using the server-side DSRequest.setCriteria() / setAllowMultiUpdate() APIs from a DMI.

**tamt** · 15 Nov 2012, 16:02

Hi,

To give a complete picture, we are attempting to implement a bulk live grid editor application. The grid can be loaded with records which are invalid and the end-user is given the ability to fix the errors prior to performing a bulk commit on the record set. One of the useful features we are attempting to implement is an auto-fill column feature which helps the end user correct data in an efficient manner. The auto-fill is only performed on the listgrid and is committed immediately to perminant data store.

To help understand why the saveAllEdits() is involved, we currently have a listgrid record cache on the server side in-between the client and the permiinant persistant store. The reason why the cache is there is to ensure the end user doesn't lose their edit changes prior to the bulk commit. Since they are dealing with 1000's of record edits prior to the bulk commit, it would be a very bad day for them if the changes are lost due to a browser crash etc. Going with local browser storage is also a concern since to our knowledge of the spec, the storage is not guaranteed to be secure.

The use case that I am having trouble with looks like this:

1. Load up the grid with 2500 records
2. Column A is missing data
3. Auto-fill the column in the listgrid via range programming techniques
4. Backup the edit on the server side in the server side cache to ensure that we don't lose the edits for any reason prior to the final commit of all the records.

The end user can be auto-filling 10's of columns in our application prior to the final commit.

The backing up of the edit is where I am seeing the performance issues. As you can see the auto-fill operation does have a relation to the grid. Based on what I describe above, do you still recommend that I create a seperate datasource binding outside of the grid to perform the mulit-record update. In addition, since I need the listgrid to be actually updated with the auto-fill data, I would assume the databound listgrid would automatically be updated on the client from the framework. If this is correct, will I see performance issues when the listgrid does the fetch of the updated records (eg. 2500 of them).

Thanks T.

**Isomorphic** · 15 Nov 2012, 16:09

do you still recommend that I create a seperate datasource binding outside of the grid to perform the mulit-record update.

This is an odd way of phrasing it which may indicate that you don't really understand the approach - we would recommend reading the QuickStart Guide about DMIs, and the documentation for the specific APIs we referred to. But, yes, the recommendation remains the same.

In addition, since I need the listgrid to be actually updated with the auto-fill data, I would assume the databound listgrid would automatically be updated on the client from the framework.

There's no mechanism that would do this for an update performed with arbitrary criteria. Once the mass update has been committed to the server, you'll need to update the Records using setAttribute (NOTE: *not* setEditValues).

If this is correct, will I see performance issues when the listgrid does the fetch of the updated records (eg. 2500 of them).

No reason to expect this, no.

**tamt** · 16 Nov 2012, 13:22

Dear Isomorphic Support:

Thanks for the help and the recommended solution worked out.

I did have a tough time figuring out how to pass the recordlist of the grid down via the DSRequest or Record parameters from the client side Datasource.performCustomOperation(...) call.

There doesn't seem to be any native support for a list of records on the client APIs and when I try to pass the recordList as an attribute value of either the Record or DSRequest, it ends up as empty encoding.

I ended up having to encode the listgrid recordlist manually to a JSON string and that got the recordlist from the client to the server.

Is there a better way than having to manually serialize the data?

Thanks T.

**Isomorphic** · 16 Nov 2012, 13:31

Yes. Pass the list of primaryKeys as an attribute on the single record, along with the changed fields, since this is common to all records. That's much less data, and far simpler.

Announcement

saveAllEdits() from a listgrid creates a form post > default maxFormContentSize

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment