Когда используют разные стратегии модели данных

Если установить через setData(..) значение поля таблицы, а потом сразу прочитать его через data(..), то результат очевидно будет такой же не зависимо от стратегии модели данных.

Потому, что setData и data работают с единым хранилищем данных в конкретной стратегии редактирования модели данных.

База данных это по сути данные в файловой системе.

OnFieldChanged стратегия сразу вызывает запись в базу при установке нового значения полю таблицы. И сразу потом идет select к базе данных и таблица обновляется.

Буквально сразу вызывается query update запрос.

Стратегия модели данных onRowChanged подразумевает, что изменения накапливаются в буфере editBuffer и запись в базу данных кэша будет происходить не просто  при потере фокуса строки (переход на другую строку), а при записи в поле другой уже строки.

До этого момента при setData данные будут меняться только в буфере редактируемой строки, а именно в editBuffer.

Стратегия onManualSubmit ничего не записывает в базу пока вы не вызовете вручную submitAll, до этого момента все изменения накапливаются в кеше, смотрите  контейнер cache.

Все вроде понятно, но когда, где и какую стратегию надо использовать.

Можно привести очень характерный пример таблицы представленной классами: модели данных my_QSqlTabelModel, унаследованной от QSqlTabelModel, и визуального ее представления my_QTableView, унаследованной от QTableView.

В таблице допустим есть вычисляемое поле sum, которое зависит от значений полей price и qty. То есть sum должно устанавливаться автоматически при установке price или qty (sum=price*qty).

И еще есть много полей, корректность значений которых (корректность сочетаний и т.д.) надо проверять перед записью в базы.

Так как после записи в базу уже проверять что-то поздно, то логично надо все проверять до записи в базу данных. 

Причём при полученных не корректных сочетаний значений полей мы должны аннулировать попытку установки значения поля в базе данных и визуально в таблице тоже отменить.

Это касается не только редактирования поля, но и копирования строки.

Может показаться, что если строка источник копирования корректная, то как может быть некорректной ее копия. Но так тоже бывает в разных алгоритмах проверки корректности всей таблицы. Например итог по колонке sum не может превышать определенный лимит.

Надо учесть, что аналогичная ситуация бывает и при удалении строки.

Так вот напрашивается такая логика использования стратегий.

Использование onFieldChanged надо запрещать, так как идет сразу запись в базу.

Далее по умолчанию для таблицы устанавливаем стратегию onRowChanged.

В модели данных my_QSqlTabelModel реализуем вычисление sum, то есть делаем setData для sum, если делается setData для price или qty.

Но только при стратегии onRowChanged. Это важно!

Вызывает нашу функцию с алгоритмом проверки разных корректностей (назовём ее sig_recalculation). sig потому что удобнее ее реализовать как сигнал.

Если sig_recalculation возвращает true (а сигналы могут возвращать значения), то вызываем submit, иначе revert в модели данных.

Теперь по поводу проверки корректности данных таблицы при копировании строки или удалении.

Может показаться, что временно можно  установить стратегию в один вариант, например onManualSubmit, а впоследствии вернуть обратно,  но на самом деле надо просто хорошо разобратся и понять разные стратегии и менять их динамически не надо. Это только больше запутает.