In 11bff0ded8 a settings option was
introduced in order to limit the number of characters loaded into each
cell in the Browse Data tab.
However, when editing the cell you wouldn't see the full data, i.e.
rendering the data incomplete and/or cropping it when it's being edited
anyway. This commit fixes this behaviour: when editing a cell (either
in-line or using the edit dialog/dock) the full data for this particular
cell is loaded and shown.
We used to reload the database schema whenever it might have been
changed and the latest version was required. For example: when the user
switches to the Structure tab we need the current schema; so we just
reloaded it to be safe - it might have been changed in the Execute SQL
tab or wherever.
With this commit we don't reload the database schema anymore when an
up-to-date version is needed but instead when it was changed by the
application. So in the example above it's not reloaded at all anymore.
Only if and when the user would execute some structure changing SQL it
would be reloaded.
Benefits:
- Better performance
- State of the structure tree view isn't lost as frequently
- Structure tree view gets updated when changing the structure in the
Execute SQL tab
Downsides:
- Less error proof (testing!)
- No 'automatic' updates when the db is changed by an external
application.
Any suggestions welcome!
This should update the master branch to use "DB Browser
for SQLite" naming, and fix the problem with the
uninstaller not showing up in Add/Remove programs on
Windows (issue #742)
Also restructure the unique constraint handling a bit to be more
parallel to the foreign key handling.
Note that this (intentionally) introduces a bit of unnecessary
code duplication which is to be eliminated in one of the next commits.
This adds some basic functionality for exporting JSON files by extending
the CSV export dialog. There is still a bit of work required for
fine-tuning the JSON export feature though. But a standard export of a
table s working well already.
See issue #688.
The grammar parser returns a bool value to indicate if it encountered
some SQL feature that it doesn't understand yet. We might as well use
that bit of information and show it to the user.
Foreign keys used to be stored along with the column information even
though it's more or less a table constraint. However, as we only support
single column foreign keys it was easier to store it inside that single
column. Now with multi-column foreign keys coming, a mechanism has been
introduced to store those multi-column foreign keys in the table data.
This lead to two different storing places for foreign key information:
inside the field for one-column foreign keys and inside the table for
multi-column foreign keys. This commit deletes the foreign key storage
inside fields and changes all code to use the table storage.
This is purely a performance optimisation. It reduced the number of
calls to Table::setField() from three to two when the user only wants to
rename a field in EditTableDialog and not move it.
