When a conditional format is used and the table does not load all the rows
at once, a deadlock ocurred when scrolling to a not yet loaded area.
This avoids the deadlock by unlocking before the conditional format query
is performed.
Additionally the cancel-query dialog is avoided when the threading mode of
SQLite is Serialize, since in that case the queries can be sent to SQLite
concurrently.
See discussion in PR #1503
If we execute a select statement and there is some trailing whitespace or
comments in the buffer, we are passing that to SQLite and fooling
ourselves thinking that it may be a query modifying the database. Since
we aren't very smart about knowing which queries modify the database, this
change at least avoids this particular case by breaking when there is only
trailing whitespace and comments.
The issue has probably origin in #1455, since previously we didn't pass
the comments to SQLite.
This commit changes the project file format (and some internal data
structures) to support multiple sort columns in the Browse Data tab.
Note that this does not add actual support for multiple sort columns,
it's just a preparation for that.
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).
* Fixed code style
* Added last location saving and loading per action type
This saves and loads different paths per action type when presenting the
native file dialog popup.
Add a new dropdown box to the Import CSV dialog to set an ON CONFLICT
strategy when importing into an existing table. You can now choose
between the old and still default behaviour of aborting the import in
case of a conflict, ignoring the conflicting row from the CSV file, and
replacing the existing row in the table.
See issue #1585.
Make sure to show the correct error message when there is an error
during CSV import.
Make sure to release the DB handle used for the import before rolling
back to the last savepoint in case of an error in the CSV import. This
avoids a deadlock situation.
See issue #1590.
SQLite 3.25.0 introduced an extended ALTER TABLE command which now
allows renaming an existing field. Before this we were emulating this
functionality in our code. There are however three reasons to switch to
the new feature from SQLite, even though it doesn't safe us any code:
1) It is faster because it does less steps
2) It is less error prone for the same reason
3) It is better at also renaming the field in triggers and views
This is somewhat improving the situation in issue #1444 but not
addressing the main problem described there.
There are cases where the default configuration makes impossible to
use the application, due to some misbehaviour, like in issue #1560. This
new command line option allows users to set any setting to any value.
The setting is not saved unless user enters Preferences and saves the
current values. This allows overriding the preferences for the session
duration from the command line and also overriding the defaults for the
first session to work around problems with those defaults.
See issue #1588
Since Qt 5.10, the Windows Vista style has been moved to its own plugin. This plugin must be included in order to show the new style. It will be included for the 64-bit build only for now, since we are using a different Qt version (5.7) for the 32-bit build.
See #1580.
This solves these two problems that seem to have being introduced in
d5a049062d
- The unlocked-view status was not applied again when switching back to the
view (you cannot edit and the Delete Record button is not reenabled) or
after refreshing.
- The 'Unlock view editing' check state persisted when switching between
views.
See issue #141.
There are two new strings in Preferences (an option and its tooltip) and
two functions call-tips that are updated with this appendix:
"Use of this function must be authorized from Preferences."
Line number changes have been discarded after lupdate so the amount of
changes for merging of translation pull requests are minimised.
* Leaving the loading of extensions enabled might be a security risk
Using sqlite3_enable_load_extension not only allows loading extensions
through the C-API but also through the SQL functioon load_extension().
That might be a security risk if the user is unaware that executing an
SQL file can lead to native code execution and not only to database file
modification.
See issue #1551
* Preference for allowing loading extensions from SQL code
New setting that authorizes the execution of load_extension() from SQL
code. Default value, false, following the design decision of SQLite, that
disables this function unless by default.
Added notice about the option in the calltips of the two function
variants.
* Problems with WITHOUT ROWID tables with PK of string type
This fixes two related problems:
- When the PK is updated the hidden column 0 must be updated too,
otherwise any further editing of the same row before a table refresh is
broken.
- When a new record is inserted and the PK has string type we cannot
simply make a pseudo auto-increment and insert that value as rowid
because that added key would be impossible to update because our
UPDATE clause will try to update a column with a string and it contains
an integer. In this case it's better to let the user enter the PK value,
so the new Add Record dialog is directly invoked.
See issue #1332 and (tangentially) #1049. The first should be fixed now.
The later not, but at least there is now a workaround: removing the
AUTOINCREMENT option and use the WITHOUT ROWID one.
* Problems with WITHOUT ROWID tables with PK of string type (alternative 2)
Update after review:
- cached_row is not modified after unlock();
- Alternative solution to initial key value insertion:
When a new record is inserted and the PK has string type we still make a
pseudo auto-increment and insert that value as a string literal. In this
way we can later update that row. When we inserted it as integer an
actual integer will be inserted by SQLite, and our UPDATE clause, which
always uses string in the WHERE condition, won't match the row (SQLite
does not convert to integer when the column is of type string in this
context).
See issue #1332.
The schema column of objects is pre-formatted with wrapped style. In this
way, if the "db.hideschemalinebreaks" setting is enabled, the printed
output is formatted in the same way, but with a wrapping style, so long
lines do not extend the Schema column too much.
Added tooltip to Preferences dialog, so it isn't a so hidden feature.
Translations updated accordingly for the release.
The header style is not applied in that same case.
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.
