path: root/dist
diff options
authorMark Brand <>2012-02-28 23:41:31 +0100
committerQt by Nokia <>2012-03-15 15:35:17 +0100
commitf6ca63f896b5f9a330ff497aebff6943653dc35d (patch)
treebda2324ac276d175787d0aae3de458be52f61ae6 /dist
parente2b6bebbed0d905c6461a65518de010d9db57176 (diff)
QSqlTableModel::setData()/setRecord(): fix incorrect row
For OnFieldChange and OnRowChange, before submitting new changes, setData() and setRecord() attempt to submit pending changes and revert them upon failure. However, they fail to consider that reverting pending insertions removes rows from the model. As a result, the new change can be applied to a row higher than intended. One possible solution would be to adjust the targetted index for the removed rows, so that the intended row is affected by the new change. But this still causes the strange editing experience as rows jump up just as they are being edited. It does not seem right in the first place for the model to initiate reverting changes. It should be up to the application to decide what to do when data cannot be committed. In particular, setData() and setRecord() should not have the side effect of reverting already pending changes. The chosen solution is simply to refuse new changes that don't make sense for the edit strategy. For OnFieldChange, flag() will indicate read-only when editing is blocked by a pending change. Since setData() and setRecord() submit data immediately for OnFieldChange, it no longer makes sense to resubmit changes automatically before a new change. For OnRowChange, setData() keeps the behavior of automatically submitting a pending row before starting on a new row. This is historical behavior and is probably motivated by the fact that QTableView does not automatically call submit() when editing leaves a row. The obvious shortcoming of this is that the last row to be edited will not be submitted automatically. It also prevents us from flagging rows other than the pending row as read-only. For OnRowChange, setRecord(), being row-oriented by nature, should submit the change immediately rather than waiting for the next call to setRecord(). This makes setRecord() consistent with insertRecord(). Change-Id: Icb4019d8b7c53a7ee48f8121a7a525e8bc35d523 Reviewed-by: Honglei Zhang <>
Diffstat (limited to 'dist')
1 files changed, 7 insertions, 0 deletions
diff --git a/dist/changes-5.0.0 b/dist/changes-5.0.0
index 3bc23c810a..c85749f2eb 100644
--- a/dist/changes-5.0.0
+++ b/dist/changes-5.0.0
@@ -420,6 +420,7 @@ ignore the rest of the range.
map were simply ignored.
-For OnManualSubmit, insertRecord() no longer leaves behind an empty
row if setRecord() fails.
+ -setRecord() now automatically submits for OnRowChange.
* QSqlQueryModel::indexInQuery() is now virtual. See
QSqlTableModel::indexInQuery() as example of how to implement in a
@@ -439,6 +440,12 @@ selectRow() is called to refresh only the affected row.
* QSqlTableModel::isDirty(): New overloaded method to check whether model
has any changes to submit. QTBUG-3108
+* QSqlTableModel::setData() and setRecord() no longer revert pending changes
+that fail upon resubmitting for edit strategies OnFieldChange and OnRowChange.
+Instead, pending (failed) changes cause new changes inappropriate to the
+edit strategy to be refused. The application should resolve or revert pending
* Database Drivers *