This simplifies the usage and the implementation of the SqliteTableModel
a bit by making the two operating modes it supports (manual query and
interactive query) more obvious in its public interface as well as
simplifying the control flow in the private implementation.
This partially reverts 89587a7d67 to fix
some issues it introduced. Using the knowledge we gained in the further
optimisation process, this commit now gets us the best of both worlds:
good performance when executing complex queries as well as a more
straightforward way to deal with the multithreaded nature of data
loading.
See issue #2537.
This fixes a remaining issue which was introduced in the series of
commits made for improving the performance of running SELECT statements
in the Execute SQL tab. The problem here was that rerunning a query did
not show any results in the view.
See issue #2165.
This further improves the performance of SELECT statements by not
triggering the row count determiniation if it is not needed. So for
queries which return less rows than the configured prefetch block size
we save an extra query. Because this requires querying the data first
and the row count second (before this the order was reversed) the data
also appears faster in the UI.
This commit also fixes another issue which was introduced in commit
89587a7d67: When setting a filter which
made the query not return any data, the column names and the filter row
became invisible. Because of that it was also impossible to change the
filter again.
This improves the performance of running SQL queries in the
SqliteTableModel class by avoiding an extra query for figuring out the
column names and data types of the returned data.
See issue #2165.
This disables the lazy population feature for queries in the Execute SQL
tab which contain a compound operator (UNION, EXCEPT, INTERSECT). Adding
a LIMIT clause to the statements (as needed for lazy population) results
in a syntax error, so running these queries does not show any data.
See issue #2316.
Always send the fetched() signal when a RowLoader thread has finished a
fetch task. Before this the signal was only sent when some data was
actually retrieved from the task. This fixes some rare problems in the
Execute SQL tab where the query for determining the row count of a
SELECT statement changes something, so the subsequent row loading task
does not return any rows after all.
The only case I know of is when loading an extension using the
'SELECT load_extension()' function. The load_extension function is
actually called twice when SQLite for some reason reports that rows
where returned from this statement. These calls are:
SELECT COUNT(*) FROM (SELECT load_extension('...'));
SELECT load_extension('...');
After the first call is executed, the extension is loaded. So the second
call does not return any rows and we indefinitely wait for the rows we
expect. Strangely enough this only happens for some extensions.
The change here should have no side effects becaue the signal is only
connected to one slot which skips most steps when no rows where fetched.
See issue #1932.
This improves the performance for loading row data with my setup by
about 10%. Incidentally, the conversion from Qt to STL containers
reduced the performance by about the same number.
For queries built from a table and filters, use a specialised count query
that only takes into account the where part of the statement. This will
speed-up the Browse Data tab for big tables.
See issue #1666
Make strings translatable, remove some more debug code, fix tests,
reduce size of patch slightly, remove weird tooltip, don't crash when
closing database, simplify code, fix filters, don't link agains pthread
on Windows.
