I am attempting to create a table that can be directly edited and that will then update the data table whose contents it is displaying. I need the following criteria to be met:
Must update upon closure of each amended cell.
Must update the 'update' timestamp for the record that has been updated automatically
I'm not aware that I can combine record Updates with moment() and have it update the timestamp in the 'modified' field of the record whose cell has a new value.
If there's a syntax for that I'll be really grateful.
So, I have deleted snagUpdate2 and the table does not update. I think this is because, as I mentioned above, I want the table to update automatically when the cell contents change. I do not want the operator to have to click an 'update' button.
For this reason it is necessary to run an event handler that triggers when the contents of a cell change, and the only command that seems to be available is bulkUpdate.
As I stated earlier, sangUpdate2 works perfectly for this purpose. When navigating away from the edited cell, or when executing a carriage return within the cell, the change is written to the data table.
snagUpdate also works to push moment() into the 'amended' field of the record. Both of these queries do what they should do, except when they share the same trigger. I have tried using two change handlers, one for each fuction. I have also tried chaining them together, having one triggered by the 'on success' function of the other. Neither of these approaches works. In all cases the updated cell value is written back to the data table, but the 'amended' timestamp is not.
I will continue to poke about but I am running out of ideas...
Have just reinstated both queries and chained one to the other. Both ran successfully but sangUpdate2 that contains the bulkUpdate command takes 0.9s to run, and snagUpdate that performs the timestamp update takes 1.0s to run. I presume that this means that the timestamp update 'misses the boat' and is not performed.
This makes no sense to me as the timestamp update is a simple field update that works just fine in isolation. The only reason why this scenario fails has to be because both operations are triggered by the same event and the timestamp component loses the 'processor race'.