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.
When changing the table in the Browse Data tab we used to remember the
column widths for that particular table. When changing the tab and then
coming back or when pressing the refresh button we used to save the
filters (but not for a table change). The sort order wasn't remembered
at all. I think this behaviour doesn't make any sense.
With this patch we remember column widths, sort order and filter values
for each table individually and restore it when the user switches back to
the table. All the settings are handled the same way and as much
information as possible is stored. It gets also saved in our project
file format.
They are kind of pointless because, really, they never should be visible
to the user. If there is no error we shouldn't show an error message and
if there is an error we should show a proper error message.
Especially during bunch executions of SQL statements by calling
DBBrowserDB::executeSQL() (like when importing a huge CSV file) this
avoids a whole bunch of string copy operations and calls to tr() and
should therefore increase the performance a bit, too.
This suddenly failed on my system and broke the CSV import. Maybe
because of some new version of some software? Either way, the new
version should work anywhere.
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.
When foreign keys are enabled it used to be impossible to change a
column of a table which is referenced in a foreign key. This is because
the table gets dropped in the process of renaming the column and only
then replaced by a new version.
With this commit the foreign keys are disabled for this short period of
time where the table doesn't exist and the old settings value is
restored as soon as the renaming is done.
See issue #362.
When opening a database we set the foreign key constraint checking
according to the preferences set in the Preferences Dialog. But when
creating a new database this wasn't done accordingly which means the
behaviour of the application is different depending on wether a database
was opened or newly created. This is changed by this commit.
In the EditTableDialog, when trying to edit a column which is referenced
in a foreign key of some other column (and thus cannot be changed
without errors ocurring during the rename process) print an error
message instead of just going on.
See issue #362.
This changes the SQL grammar parser so that it parses foreign key
clauses instead of just reading to the end of the clause when
encoutering one. This allows using the information inside the clause
later in a more effective way. However, as of now this isn't used yet.
This commit only attempts to imitate the old behaviour using the new
approach (and might fail doing so, causing new errors...).
When editing an existing table with a function used inside a default
value of a field add a '=' character before the default expression
string to match our own input format for these kind of default values.
See issue #166.
