A new option is added to the SQL tab in Preferences for choosing which
quoting characters must be used by the application when it inserts an
identifier in SQL code. The three options supported by SQLite are
available.
Default quoting characters have been changed from `Grave accents` to
"Double quotes" (SQL standard).
This options also affect the highlighting of double quoted strings: when
the SQL standard is selected, double quoted expressions are highlighted as
identifiers, otherwise as literal strings.
* - [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
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.
Similar to commit 44eb2d4f99 this commit
makes use of the backend code improvements introduced in commit
532fcd3f6b.
It adds support for database schemata other than "main" to the Browse
Data tab. With this it's possible again to browse and edit data of
temporary tables using the Browse Data tab. This time, however, they are
separated logically from "main" tables. So handling temporary tables
should be a lot less error prone now, plus it's easier to tell for the
user what tables goes in what schema.
This commit changes the project file format. There is some code included
which allows loading of project files in the old format. However,
project files generated using versions after this commit can't be loaded
by older versions of DB4S.
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.
When possible, don't write 'CREATE TABLE/VIEW/... `name`' but 'CREATE
TABLE/VIEW/... IF NOT EXISTS `name`' to the file.
Add an option to add DROP TABLE statements before each create statement.
This needs to be enhanced to apply to views, indices, and triggers as
well. See issue #629.
Clean up code.
This adds support for CHECK table constraints. We already had support
for CHECK column constraints and still mostly use that but with this
commit there are no more hickups when encountering such a table. It also
adds basic support for editing those tables: the CHECK constraint isn't
removed anymore when editing a different part of the table.
Example:
CREATE TABLE test(
a int CHECK a IN(1,2,3), -- This was supported before
b int,
CHECK b IN (1,2,3) -- This is added by this commit
);
This fixes issues that assigning the main representation of the database
in DBBrowserDB::objectMap is modified when playing around with the
database in the Edit Table and Edit Index dialogs.
These bugs were caused by my refactoring. Let's hope there's not much
more fallout from this refactoring...
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.
Parsing views or generating a CREATE VIEW statement isn't implemented
yet.
Also unify the process by which it's possible to retrieve information on
the fields of a database object.
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.
Improve the Create Index dialog so that it allows creating as well as
editing indices.
Chenge the code for the main window to allow editing existing indices.
This commit adds support for CREATE INDEX statements to our grammar
parser. The new parser is called for each index when reloading the
database schema. However, the resulting index representation isn't used
yet. Also note that this duplicates some code, though not much. The idea
is to consolidate this later in a way that includes triggers and views
as well.
This adds a new class for indices, similar to the one for tables. This
class is supposed to make creating and editing indices a lot easier,
making all manual string concatenation unnecessary.
For now this is only used for simplifying the index creation procedure
in the Create Index dialog.
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.
This adds basic support for parsing CREATE VIRTUAL TABLE statements to
the grammar parser.
This doesn't mean that those tables are handled correctly at all.
Especially editing them and browsing them isn't working. But it didn't
work before this either.
See issue #917.
Our key type here is a vector of fields and vectors aren't less than
comparable by default (and I have no idea how to implement a sane
operator<() for them). But because maps require less than comparability,
change the map to a hash which only requires an operator==() which a
vector should have by default.
No idea how this ever worked with a map?!
See issue #854.
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.
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.
When generating SQL statements properly escape all identifiers, even
those containing backticks which apparently are allowed inside
identifiers in SQLite.
See issue #387.
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...).
