Synchronize 2 models for 1 table

[darkadept]

I have a sql table with a lot of rows and I need to display this information in 2 different table views on different forms. I want the first view to show a certain set of rows and the second view to show a different, unrelated, set of rows. My first thought is to select all the rows (using a QSqlTableModel) and then use 2 separate QSortFilterProxyModels to filter the data into the 2 views.

In reality my app is more complex then the single table I described above. It has a lot of tables that need the same sort of filter. For performance and resource managing reasons I don't think it's wise to load my entire database into the client's memory. That's where sql SELECT statements make sense, or more specifically QSqlTableModel's setFilter() method.

So now I have two instances of my above model that point to the same sql table but filter only the needed set.

What happens now when the filtered row sets overlap? If the user edits the first model it won't automatically show up in the second model until I call QSqlTableModel::select(), right?

A further idea I had was to go back to a single model and use the setFilter() method to select all of my filtered row sets (for both views) and then use the two QSortFilterProxyModels to filter from there. My problem here is how do I get the two views (or actually the form widgets the views are displayed on) to play nice when using setFilter() since my two views (form widgets) have no knowledge of each other?

Ooh I hope that made sense. The hardest part is defining what the problem is! =)

[wysota]

What happens now when the filtered row sets overlap? If the user edits the first model it won't automatically show up in the second model until I call QSqlTableModel::select(), right?

Right.

A further idea I had was to go back to a single model and use the setFilter() method to select all of my filtered row sets (for both views) and then use the two QSortFilterProxyModels to filter from there. My problem here is how do I get the two views (or actually the form widgets the views are displayed on) to play nice when using setFilter() since my two views (form widgets) have no knowledge of each other?

They don't need to know of each other. If you have the same model beneath the two proxies, both views will be updated correctly when the source model is updated.

[darkadept]

Thanks a ton for the help and direction!

So is my last idea the "best" one?

I guess I'll need to code a helper class to help with taking in filter arguments, storing them, and translating that to a setFilter() call. Otherwise when a certain view wants to change it's specific row set it would overwrite the filter of the other unknown view.

[wysota]

So is my last idea the "best" one?

That I don't know.

I guess I'll need to code a helper class to help with taking in filter arguments, storing them, and translating that to a setFilter() call. Otherwise when a certain view wants to change it's specific row set it would overwrite the filter of the other unknown view.

It depends. I don't know how versatile your views are. It'd best if you had a filter that would fetch all the records any of the view could ever want and then filter them using custom proxy models.

[darkadept]

It'd best if you had a filter that would fetch all the records any of the view could ever want and then filter them using custom proxy models.

I'm going to go check the Qt source myself to see how it's actually implemented but is calling the select() method on an unfiltered (not using the setFilter() method) QSqlTableModel for a huge sql table (let's say with a lot of columns and millions of rows) a massive memory drain? Or how does Qt handle it's returned cursor set?

Ideally it would be great to represent each table as a model so that all parts of the program would receive updates if a different part updated the model. But I guess calling setFilter() and then select() every once in a while isn't that bad either.

[wysota]

is calling the select() method on an unfiltered (not using the setFilter() method) QSqlTableModel for a huge sql table (let's say with a lot of columns and millions of rows) a massive memory drain? Or how does Qt handle it's returned cursor set?

Qt performs caching of items, so when you access a particular row for the first time, it surely gets stuck in memory.

Ideally it would be great to represent each table as a model so that all parts of the program would receive updates if a different part updated the model. But I guess calling setFilter() and then select() every once in a while isn't that bad either.

Be aware that by calling select() you loose all selections in all views.