After setting a filter, the user can select from the context menu in the
filter line a new option "Use for Conditional Format", that assigns
automatically a colour to the background of cells fulfilling that
condition.
The formatting is preserved after the user has removed the filter. Several
conditional formats can be successively added to a column using different
filters.
The conditional formats of a column can be cleared when the filter is empty
selecting "Clear All Conditional Formats" from the filter line context
menu.
The conditional formats are saved and loaded in project files as other
browse table settings.
A new class Palette has been added for reusing the automatic colour
assignment of the Plot Dock. It takes into account the theme kind of the
application (dark, light) for the colour selection.
A new class CondFormat for using the conditional formatting settings from
several classes. The conversion of a filter string from our format to an
SQL condition has been moved here for reuse in filters and conditional
formatting.
Whether the conditional format applies is resolved by SQLite, so filters
and conditional formats give the same exact results.
Code for getting a pragma value has been reused for getting the condition
result, and consequently renamed to selectSingleCell.
Possible future improvement:
- New dialog for editing the conditional formatting (at least colour and
application order of conditions, but maybe too: adding new conditions and
editing the condition itself).
When a table is filtered and the browsed tabled is changed and then we
return to this filtered table, the table view shows several incorrect
disabled rows. The same may happen when refreshing this table. This seems
to be produced by a (yet unsolved) concurrency problem triggered by
several consecutive queries, that are signalled by setting the text of
the stored filters in the table header filter.
These unnecessary queries are avoided by setting the stored filter values
at the same time as the table in the SQL table model, making sure that
no intermediate queries are executed while the filters are set.
This seems to work around the concurrency problem and the symptom of the
invalid rows does not appear in those situations.
The multithreading patch didn't properly load all data into the cache
when this was necessary. It would only do so if the chunk size was
sufficiently high. This is fixed in this commit.
Show a progress dialog while loading all data which can be cancelled by
the user.
When cancelling the loading of all data in those cases which require all
data to be loaded, stop whatever process needs the data too.
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.
The crash is avoided if the table model is not editable, since insertRows
checks that. A table model for a DB view should be not editable, so this
fix avoids the crash and possibly other possible misbehaviours.
A new button is added to the Browse Data tab for saving the current display
of the table (current filter, sort column and display formats) as a new
view. This allows (specially for non advanced users) the creation of simple
views. It can be seen, either as a way of storing the current
filtering or as an easy way of creating views.
This reuses the query set in sqlitetablemodel, but the column aliases when
a display format is used has been changed from col%1 to the original column
names, i.e. format(`orig`) AS `orig`.
Exporting SQL files crashed because of the multi-threaded loading of
data which also affects the SQL export. Because the table models were
destructed relatively quickly during the export's progress estimation,
their threads were still running and trying to access invalid data
structures.
See issue #1228.
Remove the valid flag from the SqliteTableModel class and remove its
usage in the Execute SQL tab of the main window. I believe this hasn't
been used for some time now because the main sources of error should
really be noticed before the query is even handed over to the model.
Additionally the valid flag wasn't as realible either anymore because of
the multi-threaded execution of the model queries.
In the SqliteTableModel class we need to know the total number of rows
in the table or returned by the query. This takes a considerable amount
of time and can be moved into a separate thread. I haven't done any
performance measurements with this but it might speed up switching
between large tables a bit.
Similar to commit 44eb2d4f99 this commit
makes use of the backend code improvements introduced in commit
532fcd3f6b.
It adds support for database schemata other than "main" to the Browse
Data tab. With this it's possible again to browse and edit data of
temporary tables using the Browse Data tab. This time, however, they are
separated logically from "main" tables. So handling temporary tables
should be a lot less error prone now, plus it's easier to tell for the
user what tables goes in what schema.
This commit changes the project file format. There is some code included
which allows loading of project files in the old format. However,
project files generated using versions after this commit can't be loaded
by older versions of DB4S.
This adds initial basic support for handling different database schemata
at once to the backend code. This is still far from working properly but
shouldn't break much either - mostly because it's not really used yet in
the user interface code.
Browsing WITHOUT ROWID tables was broken since a couple of commits. An
error message would be printed to the console and all cells would stay
empty. This is fixed by this commit.
This adds a new context menu option that allows unlocking views for
updating. This requires appropriate triggers to be in place and the user
to type in a column name that can be used as a 'primary key' for the
view. By default views are still locked from editing.
Inserting into and deleting from views isn't supported yet.
See issue #141.
When browsing a table and changing the sort order, then switching to
another table, and then switching back, we would sort the table twice:
once using the default sort order and then again using the previously
used sort order. This results in four instead of two queries for those
tables (including the COUNT queries). This commit fixes this so that
only two queries are executed which should cut the run time for these
cases in half.
See issue #1007.
When browsing and editing a table in the Browse Data tab allow the user
to change the assumed encoding of the text in the table. We'll then try
to convert from this encoding to Unicode for display purposes and to
convert from Unicode to this encoding for editing purposes. This way the
UI and all tools will keep using Unicode while the database format is
still respected. I hope the amount conversions generated this way won't
affect the performance too much.
See issue #414.
This is a proof-of-concept or even a basic first implementation of a new
feature I'd like to have in DB4S which at the moment I call display
formats.
The idea here is to allow the user to change the data in the Browse Data
tab on a per column basis before displaying it. This means even though
the data is stored in format X in the database it can be shown in format
Y in the browser. This should be useful in cases where the original
format X is hard to read or just not useful in a particular case.
This first implementation allows the user to right click on the header
of a column and open a new dialog for setting the display format which
offers a (limited) list of pre-defined formats. The selected format is
then integrated into the SELECT statement which is sent to SQLite.
While it works, this draft implementation lacks a number of features.
Here are the most prominent ones I'm currently aware of:
* Data not editable (or only via the Edit Dialog) because it isn't
transformed back yet.
* More display formats needed; maybe customizable ones, too.
* No indication in the UI for which columns a format has been set.
* Could _maybe_ be integrated into the import/export etc. for optional
use.
Add a tooltip to the database browser when you hover a cell with a
foreign key set in order to show the referenced table and column.
When clicking on such a cell while holding the Ctrl and Shift key (only
one of them won't work because they are for multiselection and Alt
doesn't do the trick on my system because it's just for grabbing and
moving the window) try to jump to the table and row which is referenced
in the clicked cell.
See issue #192.
Change the approach to count the total number of rows returned by an SQL
query to also support EXPLAIN and PRAGMA statements. These failed before
because you are not allowed to put them into a COUNT query. This commit
adds the code needed to count the number of rows manually when one of
these queries is executed.
Call beginRemoveRows() and endRemoveRows() when emptying the cache. This
silences those warnings from QAbstractItemModel::endInsertRows() and
fixes a crash when exiting the program both ocurring when the data was
resorted.
