Qt-contributors-summit-2011-SQL session notes

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

QSql module session notes

Slides [slideshare.net] from André's presentation.

• Add generic DDL C++ APIs in QtSql possible include most of the RDBMS DDL operations on TABLE, VIEW, SYNONYMS, DICTIONARY, INDEX, FUNCTION, PROCEDURE, TABLESPACE, TRIGGER, etc.
• Better transaction support RAII for transaction, automatically rollback transaction if not committed.
• Asynchronous support for QtSQL
• Make QtSQL thread safe or add a thread safe QtSql model wrapper
• Better mechanism to remove hand written SQL string, especially SQL dialet string. something like Database template or Query/Sql statement Builder or SQL parser would be nice to do this job.
• Support more database driver related informations name, vendor, icon, human readable description, etc.
• Better support database server related feature list all databases in a database server, etc.
• Enhancements for query sorting, top/limitation/paging, grouping, async. Better WHERE statements, etc.
• Better handling for table relationships
• Remove all painful/sucks sql model problems
• Really need more contributors, reviewers and maintainers.
• Current QtSQL bug fixings, merge requests are not processed well, looking forward the upcoming new code review and contribution model can solve this problem.

Followup

• Qt SQL is still important for Nokia, but as a support module. It is not core. Easy to display is important, but Nokia is not a DB company.
• Vendor issues (TDS, ODBC) take a lot of time to fix/work around.
• Two main questions
  • What can we do for improving the core functionality?
    • Things like moving some connection specific stuff to connections rather than drivers (e.g. escaping, reading relations from database etc)
    • transaction RAII
    • multiple statement execution (consistent – some dbs can, some can't)
  • What additional functionality do we need (DDL)?
    • incremental sort/filter thing for tableview
    • extend query class like Andre's project above (for DDL but also other stuff)
    • async API
    • consistent threading

Suggestion: separate modules for different databases? And what can we do with different types of data stores (SparQL, name-value stores, NoSQL)

Problem is testing infrastructure. Nokia can probably provide some database testing infrastructure. (at least be able to run code in CI system against test databases, and provide instructions for configuring local databases)

Warning about scope and closing databases should be fixed. Just make letting QSqlDatabase go out of scope.

We discussed the in-view editing with the different submit strategies. There is a problem with the concept of rows there. It was suggested that basically only ManualSubmit works. There is a bit of a mismatch between the design of databases (row based) and item views (multi level grid).

Is it feasable to let all database stuff be done in a separate thread?

Idea: Could embedded SQLite be used as a cache for other databases? Probably not…

Async is needed. We need two API's, both have use cases. The synchronous can be done on top of the async one.

Removal of rows in views is an issue.

• The issue is that there is static result set you work on. There is a difference with the strategies with insertion. Could that be fixed?
  • The reason is that on manual submit strategy, if something goes wrong, we have no means to identify the row, since it'll be gone from the model
  • Also, on manual submit strategy, the user could "undo" the "delete row" operation. If the row is gone from the model, there's no way to recover it
  • Idea: Mark row as hidden or deleted, so it's still in the model, but not shown in the view?
  • Or – re-introduce a QSqlCursor like class that manages the result set. The model would just be a thin wrapper around the QSqlCursor. The QSqlCursor would have all the "raw" data, the model in turn could filter out already deleted rows and pretend they don't exist.

Feel free to contribute: Trolls are available for help, but work needs to come from the community.

Discussion on qt5-feedback.