In the Edit Table dialog we used to call our alterTable function (which
works around SQLite's missing full ALTER TABLE support by - besided
other things - copying all the data of the table) for pretty much every
change immediately. This was taking a lot of time for larger tables.
Our alterTable function allowed any number of changes if they affect
only one field of the table at once. So we could have reduced the number
of calls a lot by just using that capability. Instead however, this
commit improves the alterTable function to make possible transforming a
table completely in just one call. It does so by taking the new table
schema and using that without further modification. It also takes a new
parameter to keep track of what column in the old table becomes what
column in the new table, so the data can be preserved.
This commit obviously also changes the Edit Table dialog to make proper
use of the new features. This means that whatever changes you make to a
table, you will only have to wait once until for the alterTable call,
and that's when clicking the OK button.
See issue #1444.
This commit refactors vast parts of the sqlitetypes.h interface. Its
main goals are: less code, easier code, a more modern interface, reduced
likelihood for strange errors and more flexibility for future
extensions.
The main reason why the sqlitetypes.h functions were working so well in
DB4S was not because they were that stable but because they were
extremely interlinked with the rest of the code. This is fine because we
do not plan to ship them as a separate library. But it makes it hard to
find the obvious spot to fix an issue or to put a new function. It can
always be done in the sqlitetypes function or in the rest of the DB4S
code because it is just not clear what the interface between the two
should look like. This is supposed to be improved by this commit. One
main thing here is to make ownership of objects a bit clearer.
In theory the new code should be faster too but that difference will be
neglectable from a user POV.
This commit also fixes a hidden bug which caused all table constraints
to be removed in the Edit Table dialog when a single field was removed
from the table.
This is all still WIP and more work is needed to be done here.
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.
* - [NEW] Add new interface and functionality to manage database file extension. (Implements feature request #659)
* - [FIX] Fixed CMake file to src.pro
* - Applied changes requested by mgrojo to uniform code with sqlitebrowser standards
- Add "history" when closing editor window, but reopen before closing preferences
- Revert some changes done by QtCreator
* Refuse from previous commit
* Additional changes requested by MKleusberg:
- [CHG] Always add "All files (*)" to filters
- [FIX] Removed unused include
* merged from master
* Merge sqlitebrowser master
* [FIX] Fixed compatibility to compile on KUbuntu 14.04 with Qt 5.2.1
* [FIX] Fix Qt version for QOpenGLWidget support on previous commit
* [CHG] Uniformed QT_VERSION_CHECK style
[CHG] Reverted macOS check on Mainwindow for OpenGL context creation
Fix a crash which happened when opening a table in the Edit Table dialog
for modification and changing its schema and then (without reopening the
dialog) change the schema again or doing some other modifications to the
table.
See issue #1131.
At the moment when user types a custom type into the type combo box and
doesn't press enter, the entered type isn't used. This patch tries to fix
the problem by installing an event filter for the combo box and checking
when it loses focus - when it does, it performs type updates too.
On the way the patch also changes the signal used inside moveCurrentField()
from activated() to currentIndexChanged() to make it consistent with the
rest of the file.
When moving an existing table to a different schema which already
contains a table of that name, this causes an error. With this commit we
try to detect this type of error as early as possible.
This commit also updates the error message for that case. The old error
message still mentioned the 'temporary flag' which isn't correct
anymore.
Also, when changing the schema fails, reset the dropdown box back to a
working schema to avoid any confusion about whether the change worked or
not.
This replaces the checkbox for creating tables in the temporary schema
by a dropdown box that lets you select between all available schemata,
i.e. main, temp, and all attached databases. This way it becomes
possible to create new tables in attached databases as well as move
existing tables between all schemata.
This improves the Edit Table dialog to better handle moving tables from
one schema to another, though the UI currently only knows about the main
and the temp schema.
This also simplifies the grammar code by removing the temporary flag
from all classes because it's redundant now that we support multiple
schemata.
Commit 532fcd3f6b added support for
multiple database schemata to the backend code. While doing this, it
removed support for showing temporary database objects in the user
interface.
This functionally is partially reimplemented by this commit. With this
commit temporary database objects are shown in the Database Structure
tab and in the Db Structure dock. Unlike before however, they are
visually separated from 'normal' database objects. Also this commit
tries to make use of the new schema handling code wherever possible to
also separate temporary objects programatically from the normal ones.
This wasn't done in earlier versions and effectively was a source of
all sorts of errors.
This commit still lacks support for temporary tables in the foreign key
editor and in the Browse Data tab. Also a substantial amount of testing
is still required.
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.
Allow changing the case of a column name in the Edit Table dialog
without complaining about the name already being taken. This happened
when for example changing a column called 'A' to 'a', making this sort
of changes impossible.
See issue #985.
Rename the settings accessor functions from Settings::getSettingsValue()
(and similar) to Settings::getValue() (and similar). The 'Settings' bit
seems a bit redundant and costs a lot of screen space.
This finally gets rid of the DBBrowserObject class entirely and moves
all its functionality to the newer classes in the sqlb namespace.
I'm still not entirely happy with this but at least things should be a
little more consistent now.
Simplify the code by storing the flag that indicates if the parsing was
successful in the parsed object itself instead of handing around pairs
of parsed objects and bools.
This changes the class structure in the sqlb namespace as well as the
DBBrowserObject class. The rest of the commit are changes that are
required by the modifications in sqlb and DBBrowserObject.
The idea behind this refactoring is this: we currently have the
DBBrowserObject class which holds some basic information about the
database object (name, type, SQL string, etc.). It also contains a
sqlb::Table and a sqlb::Index object. Those are used if the type of
the object is table or index and they contain a whole lot more
information on the object than the DBBrowserObject class, including the
name, the type, the SQL string, etc.
So we have a duplication here. There are two class structures for
storing the same information. This has historic reasons but other than
that there is no point in keeping it this way. With this commit I start
the work of consolidating the sqlb classes in order to get rid of the
DBBrowserObject class entirely.
This commit only starts this task, it doesn't finish it. This is why it
is a little messy here and there, but then again the old structure was a
little messy, too. We will need at least a very basic trigger and view
parser before finishing this is even possible. When this is done, I hope
the ode will be much easier to read and understand. But even in the
current state there already is some progress: we save a little bit of
memory, don't copy big objects all the time anymore, and replace a lot
of unnecessary string comparisons with integer comparisons.
You can create temporary table using CREATE TEMPORARY TABLE xxx
statements. DB4S shows them as ordinary tables which is fine most of the
time. However, it wouldn't remember the temporary status when editing
them via the Edit Table dialog. This means that editing them would
create a normal, non-temporary table. This is fixed by this commit.
Renaming a table always happens *after* editing all table columns (at
least that's the order we're doing it currently). So for all
renameColumn() names we'll need to use the table name as it is in the
database, *not* as it is in the table name widget because that might
have been changed in the meantime.
When editing a column of an existing table, this process might fail for
all sorts of reasons. Instead of printing an error message to stdout
this commit changes it to show a message box, so the user knows the
editing failed.
Adding a primary key to a table that didn't had a primary key before
would have added the column to the sqlb::Table::primaryKey::emptyFieldVector
variable (which is static!) instead of actually creating a new primary
key.
This way the primary key wouldn't be created as a new table constraint.
See issue #918.
- the table now scroll to the bottom so the newly inserted field will be
in view
- the first column (Name) is now auto-selected for easy text update
- related to #769
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!
