5.1d BatchUploader error-message and behavior in case of an failure-response for ADD

[Blama]

Hi Isomorphic,

please see this SNAPSHOT_v10.1d_2015-10-22 BuilinDS based testcase (add ",supplyItemUpload,batchUpload" to the DSLoader call in BuiltInDS.html).


It returns errors for items that start with "A" or "T", which are three in the provided file. See the result in a screenshot:


This is a bit constructed, but one can not be sure that all add operations will run through smoothly, so the following questions/issues are important.

1. See the status=-10 rows (the ones that could be saved) if it were not for the A/T-rows. (By the way: The -10-display-issue is still open).
   Shouldn't they be saved? IMHO they should be successful, shouldn't they? Is it possible to save them anyway, perhaps with explicit commit-calls?
2. See the SC.warn-error message: It shows only the last error.
   Should it not collect all error messages for the queue and display them all?
   I'd expect a message like "2 record added, 3 records with errors". Also, I'd expect the one row with validation error to still be there after the commit-click. For me, the ListGrid is gone.
3. The "ListGrid" gone issue comes with a Error in the Developer Console:
   

   15:53:41.157:XRP3:WARN:Log:TypeError: _1.grid is null
   	Stack from error.stack:
   	    BatchUploader.commit/<() @ builtinds/sc/modules/ISC_DataBinding.js:3433
   	    [c]Class.fireCallback() @ builtinds/sc/modules/ISC_Core.js:290
   	    [c]Class.fireCallback() @ builtinds/sc/modules/ISC_Core.js:358
   	    RPCManager._performTransactionReply() @ builtinds/sc/modules/ISC_DataBinding.js:1704
   	    [c]RPCManager.performTransactionReply() @ builtinds/sc/modules/ISC_DataBinding.js:1611
   	    anonymous() @ builtinds/sc/modules/ISC_Core.js:77
   	    [c]Class.fireCallback() @ builtinds/sc/modules/ISC_Core.js:290
   	    [c]Comm.performXmlTransactionReply() @ builtinds/sc/modules/ISC_Core.js:1304
   	    anonymous() @ builtinds/sc/modules/ISC_Core.js:77
   	    [c]Class.fireCallback() @ builtinds/sc/modules/ISC_Core.js:290
   	    Comm._fireXMLCallback() @ builtinds/sc/modules/ISC_Core.js:1284
   	    Comm.sendXmlHttpRequest/_13() @ builtinds/sc/modules/ISC_Core.js:1291
   	
   	15:53:41.169:XRP3:WARN:Log:Uncaught JavaScript exception: TypeError: _1.grid is null in http://127.0.0.1:8888/builtinds/sc/modules/ISC_DataBinding.js, line 3433

   This is somehow related to batchUploader.setPartialCommit(PartialCommitOption.RETAIN), because it does not happen without it.
4. This is more of an enhancement: My supplyItemUpload-DS does not have a PK like in the sample because all my PKs are sequences. If I added an artificial PK in the data (e.g. by having the user enter the row number in the data and using this as PK-column in supplyItemUpload-DS (or, even better using the number from ListGrid.setShowRowNumbers(true)), I could return the PK/rownumber of the rows with errors and the ListGrid could retain there rows and show the errormessage returned for the specific add as error for this row. This would be in total for the row, not per column, so it would be best at the beginning of the row, perhaps in the setShowRowNumbers-column. I don't think that I'll need it as I should be able to ensure data quality with validators, but for longer lists where some DB issue shows up (most likely referential problem with a now deleted key because of the long-running BatchUploader operation), this might be a good idea.

Best regards
Blama

PS: I made this testcase for the server-related parts of this thread.

[Isomorphic]

1. They aren't saved because they are sent to the server in a queue and automatic transaction management is kicking in. It is absolutely intentional and correct, in that circumstance, that it rolls back successful adds if it encounters an unsuccessful one - that is how transactions are supposed to work. There are many ways to influence the framework's transactional behavior - have a read through the autoJoinTransactions documentation

An engineer has been assigned to look at the issues described in (2) and (3)

[Isomorphic]

We have fixed the bug that was making the grid disappear and made changes so that multiple "hard" errors result in a message box that tries to show all of them rather than just the last one. We have not made extensive efforts to make this polished, however, because it seems unlikely that it would be seen by a user very often. As you say yourself, the example in this thread is contrived - you would never normally report a problem of this kind by throwing an Exception from a DMI method. Rather, you would create a validation, the failure of which would lead to a validation error indication right there in the grid.

We have also introduced a new property to BatchUploader, "updatesRolledBackMessage". This is text we will append to the error message box if any of the updates in the queue were rolled back because of the failure of another update. For this use case, however, perhaps switching off transactions and allowing it to commit individual records would make more sense to an end user