[Interest] QSqlTableModel -- best approach for simple database application?

[K. Frank]

Hi Mark!

I appreciate you comments.

On Thu, May 24, 2012 at 11:22 AM, Mark Brand <mabrand at mabrand.nl> wrote:
>
>> I've started browsing the SQL Table Model example in the 4.8 documentation
>> (sql/tablemodel/tablemodel.cpp), but I seem to recall some discussions
>> suggesting that QSqlTableModel has some limitations or problems that
>> might make it not the best choice.
>
> Qt 5 has many improvements for QSqlTableModel, so if it's feasible for you,
> consider using Qt 5. With any luck, Qt 5.0 will be released before your
> application.

I could be game for that.

A couple of questions about Qt 5.0:

Would I expect any significant compatibility issues with relatively
simple, widget-based, Qt 4.8 applications?  I am using qwt 6.0.1
in some of these applications, if that matters.

Do you now, offhand, if there is a reasonably stable Qt 5.0 release
candidate available?

Would I expect any difficulty building Qt 5.0 with mingw-w64?
When I built Qt 4.8.0-rc1 I was right on the edge of running
out of memory with the particular build go mingw-w64 I was
using.

> ...
>>
>> As a possible enhancement, I might want the data to be edited to be
>> displayed in the application based on views in the database, rather
>> than raw tables, or possibly in terms of "views" constructed with
>> application logic (e.g., various select statements), but I wouldn't
>> bother with this if it added much complexity to the application.
>
> You can point QSqlTableModel at a database view. Editing will work if the
> view is updatable. Sqlite and other DBMSs allow you to create triggers to
> make your views updatable.

That's good to know.  It could make life a little easier.

> If you do this, be sure to explicitly setPrimaryKey() so QSqlTableModel will
> know how to construct UPDATE statements. Otherwise, the WHERE clause will
> refer to all columns which doesn't work well for float type.

Thanks for the heads-up.

> Models and views must be in the same thread, which means queries are
> executed in the GUI thread. So avoid queries (and views) that take a long
> time to execute.

Fortunately, my application won't be demanding at all (and, in any
event, will only be for internal consumption).  So having the queries
in the GUI thread shouldn't be a problem in practice.

>> Any suggestions for how to approach building such an application
>> would be greatly appreciated.
>>
>> (And if the answer is "copy the sql/tablemodel/ example, and tweak
>> it as needed," that would be fine.)
>
> Yes, take a look at the examples. The sqlbrowser example is pretty nice.

Thank you, I will.  It looks like QSqlTableModel will be adequate
for my relatively undemanding application.

> Mark

Again, I appreciate your help.


K. Frank