[Development] Regression / Behavioral Change in QSqlTableModel / QTableView in Qt 5

[Mark Brand]

Harald Fernengel wrote:
> Hi,
>
> On Tuesday 11 September 2012 14:49:22 ext Mark Brand wrote:
>> We could consider removing the row from the model only after verifying
>> that the corresponding record no longer exists in the database table.
> One principle of the SQL module was not to try to outsmart the database. We
> use static result sets to show the data as it was at the time of the SELECT,
> so it's possible to scroll up & down and see a consistent set of data.
>
> Once the data is modified e.g. by INSERT, DELETE, UPDATE, we must re-SELECT the
> data to show whatever is in the tables after the database performed its magic,
> as there's no way to figure out what actually happened (e.g., as Mark said,
> because of server-side triggers).

Just to avoid any misunderstanding, Harald is describing the Qt 4 
behavior of QSqlTableModel.

In Qt 5, we still don't want to outsmart the database. But there is no 
longer an automatic select() after submitting INSERT, DELETE or UPDATE 
statements. One reason for this change is not to ruin view navigation 
and selections. Another reason is to avoid the overhead of a complete 
select after editing each and every field or record in the respective 
edit strategies. In general, this gives more control to the application.

The compromise now is that a new overloaded virtual method select(row) 
is used to refresh just the affected rows after submitting. This 
probably suits most applications

In cases where, for example, triggers or views might cause other rows to 
change as well, the application can extend this as appropriate, or use a 
custom subclass that refreshes more rows or even the whole table.

>
> Losing the focus / selection is anoying, but we always felt that this should
> be fixed in the UI (e.g. by remembering the primary key, then re-setting focus
> after the model re-SELECTs), rather than trying to over-complicate the model.
This sounds like a layering violation to me, contrary to the spirit of 
itemviews. The UI shouldn't necessarily have to know the underside of 
the model or primary keys.

QTableView itself only knows the QAbstractItemModel interface, so it 
obviously doesn't know about primary keys.

Mark