Otherwise the UI dynamic property does not seem to work, although it
use to and should. Please, improve it if a way to return to the correct
behaviour.
Fixes issue #2078
Setting a collation in a newly added field in the Edit Table dialog did
not work when the field name was edited just before. This is fixed now.
See issue #2011.
When creating a new foreign key constraint in the Edit Table dialog, a
list of tables to reference is displayed. This list is updated whenever
the name of the edited table changes because this is the only table the
name of which can change while the Edit Table dialog is opened. However,
this meant that when the name of the table changes to some existing
table name, the field list of that existing table is replaced by the
field list of the current table. If the name of the current table is
changed once again, it is deleted entirely from the list. This commit
fixes this behaviour by separating the static part of the table and
field list from the one table which can change.
See issue #1991.
This commit changes the class hierarchy to make primary key constraints
a type of unique constraints. This fits nicely with reality because
primary key columns do not allow duplicate values. It also makes our
life easier as the other changes which are introduced here add some code
required by both unique and primary key constraints and which now can be
shared.
Move the auto increment flag from the field class to the primary key
class. This changes how auto increment fields work and look and might be
a bit unfamiliar but it simplifies things a lot for us because an auto
increment field is always a primary key. So before we had to maintain
two places: the field with the auto increment flag and the primary key
which belongs to it. Now it is all in one place in the primary key.
Add support for storing and manipulating sort order for columns in
primary key and unique constraints. It does not add support for them to
the grammar parser though.
Finally add a way to store and manipulate on conflict clauses for unique
and primary key constraints. Again, parser support for them is not added.
This fixes a regression which was introduced by the changes in Commit
0768ccd1db. The newly added combo box for
setting the collation of a field was not created for fields which were
newly added to the table. This broke the setting of the data type for
these fields.
See issue #1973.
Add a new column to the field table of the Edit Table dialog which
allows you to set, remove, and modify the collation of each field. This
is done by showing a combo box which lists all currently available
collations.
See issue #1973.
Enable the combo box in the Edit Table dialog to change the type of a
table constraint and add the code to try to transform a constraint from
one type into another as best as possible.
This changes the way we store the constraints associated with a table
from using a map to using a set. The map was mapping from the list of
field names to the constraint applied on these fields. Now the field
list is stored inside the constraint and we can store the constraints in
a simple set. This turns out to simplify the code noticeably.
This adds support for modifying the columns a constraint is applied on
in the Constraints tab of the Edit Table dialog. This is a major step
towards full constraint editing capabilities (adding new constraints,
modifying constraint type, and editing constraint type-dependent
parameters are the other missing pieces).
The reasoning behind the popup dialog is to not introduce another full
dialog on top of the Edit Table dialog. After opening the Edit Table
dialog, then switching to the Constraints tab, then opening another
modal dialog, I felt like losing track of what I am currently editing.
The popup dialog is certainly not great but feels a bit less intrusive.
Any suggestions regarding this are appreciated.
This adds support for changing the names of existing constraints in the
Edit Table dialog. It should be possible to extend the code to allow
further modifications of the constraints.
As a minor change, this commit makes the SQL column of the constraints
table read only.
Add a new tab to the Edit Table dialog to show a list of all table
constraints. Before this, some of them were visible in the field list
but others were not shown at all. This new view is still rather basic
and currently read-only but will be improved over time.
In the Table class we need to store whether this is a WITHOUT ROWID
table or now. Instead of just storing a boolean flag for that we were
storing a list of the rowid column(s). This is not just more complicated
to handle than a simple flag but also more error-prone because the list
must always be kept equal to the list of primary key columns. Failing to
keep them equal would result in an invalid SQL statement.
This add initial and mostly untested support for WITHOUT ROWID tables
with multiple primary key columns. It should now be possible to update
and to delete records in these tables.
This commit also improves the overall handling of multiple primary key
columns in preparation for better support of them in general.
Note that this makes us depend on an SQLite version with a built-in JSON
extension.
See issues #516, #1075, and #1834.
This fixes a bug in the code to modify multiple table columns in one go.
We were accidentally adding more tracked columns when adding a new
column and then changing its name.
See issue #1627.
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.