83c9ebbd66
Previously the method attempted to reset only as a last resort. Now reset() is deprecated and resetting must happen between emitting modelAboutToBeReset() and modelReset(). Since this suffices in all cases to notify views that they must reinterrogate the model, it is no longer necessary to signal explicitly row removals and insertions within the scope of the reset. Additionally, fetchMore() is now called within the scope of the reset so insert signals do not have to be emitted here either. This improved handling of resetting in QSqlQueryModel also allows the cache in QSqlTableModel to be cleared directly at select(). This change may actually allow views to operate more efficiently since they no longer have to react to separate row removal and insert signals. Views can avoid pointless deallocation and reallocation by considering row count only after the reset is finished. The cost is that the columns and horizontal headers must be considered in the view at each setQuery() call. In any case, it is not clear that trying to be smart about this in the model justifies additional complexity. Tests had to be adjusted where they expected explicit row removal and insert signals. Change-Id: I4f7eac1419824361d7d9bdcc6a87092b33e80d7a Task-Id: QTBUG-25419 Reviewed-by: Andy Shaw <andy.shaw@digia.com> Reviewed-by: Olivier Goffart <ogoffart@woboq.com> Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com> |
||
|---|---|---|
| .. | ||
| qsqlquerymodel | ||
| qsqlrelationaltablemodel | ||
| qsqltablemodel | ||
| models.pro | ||