This commit fixes a regression which was introduced in commit
788134eee6 which broke the parsing of row
values.
It also makes sure CHECK expressions are parsed in exactly the same way,
no matter whether they are a column or a table constraint. Before spaces
were added to the query in a different way. The way it was done for
column constaints had also an error were the minus sign of a negative
number was separated from the first digit by a space. This is fixed,
too.
Because of all the changes this commit also adjusts the tests to expect
the new layout of the check expressions. It also adds some new tests for
row values and for complex expressions to make sure both work. Finally,
it also removes all QScintilla dependencies from the tests which don't
seem to be necessary.
This fixes parsing of expressions of the form '(x) AND/OR y' and similar
types. It also fixes expression of the '(x)' type and of the '(x op y
AND z op w)' type.
See issue #1454.
Modified some tests for taking into account the new standard quoting and
added some more for testing the quoting configuration and for correct
parsing of different quoting styles.
Default branch in escapeIdentifier() for trying to avoid warning.
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.
Antlr uses the current system locale when parsing SQL statements. This
is problematic because SQL is case-independent and for converting
characters to lower/upper case it is going to use the locale. For
Turkish however this adds implicit conversions between the dotted and
dotless I which triggers another problem in Antlr: it doesn't cover the
whole Unicode character set. This commit fixes the implicit conversions.
See issue #1194.
At the moment space is inserted between all tokens from which a type
consists. This adds extra spaces to types like VARCHAR(5) which become
"VARCHAR ( 5 )" which causes problems in some applications.
This patch modifies the way tokens are concatenated for a type. It makes
sure that the extra space isn't inserted before "(" and ")" and also
after "(".
This adds support for multiple foreign keys in a column constraint.
Example:
CREATE TABLE t1(a int, b int);
CREATE TABLE t2(a int, b int);
CREATE TABLE test(
x int REFERENCES t1(a) REFERENCES t2(a), -- This is now supported
y int
);
Multiple foreign keys if they are a table constraint were already
supported before.
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
);
When having a table definition like this, detect the parse errors in the
table constraints correctly:
CREATE TABLE test(
a INTEGER,
b TEXT,
PRIMARY KEY(a ASC), -- ASC here
UNIQUE(b COLLATE NOCASE) -- COLLATE here
);
The next step is to actually parse and store this information.
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.
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 fixes two issues with unusual but valid data types for columns:
1) When having a data type that consists of more than one word these
wouldn't be separated anymore after parsing. This is fixed now. Example:
CREATE TABLE test(a long int);
would have become
CREATE TABLE test(a longint);
2) Some keywords are allowed to be used as data types. Parsing these
tables would have failed entire prior to this. This is fixed, too.
Example:
CREATE TABLE test(a no);
would fail.
This fixes tables like these where a keyword (in this case NO) is used
as an unquoted default value for a column:
CREATE TABLE test(a DEFAULT NO);
See issue #877.
Parse named primary keys correctly when they are in a column constraint,
not in a table constraint. E.g.
CREATE TABLE `a` (
`x` INTEGER CONSTRAINT c PRIMARY KEY, -- Name 'c' here
`y` INTEGER,
);
See issue #741.
Previously the grammar parser would fail to extract and store the name
of a foreign key constraint in statements like these:
CREATE TABLE test(
a int,
b int CONSTRAINT this REFERENCES xy(id) -- See the 'this' name
);
See issue #741.
Table definitions like these wouldn't work before:
CREATE TABLE test(
a int NOT NULL, -- This worked fine
b int NULL -- This didn't but does now.
);
See issue #741.
When our grammar parser doesn't fully understand a create table
statement yet, it'll set a flag to indicate the modifying this table
will result in errors: the nonunderstood parts will be removed from the
table while editing it.
The code for this feature, however, had a bug that was triggered by some
compilers (gcc in my case) because of an ambiguous function call. That
ambiguity and thus the resulting bug are fixed by this commit, making
sure the warning appears on all systems.
This was fun to debug...
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.
Suppose you have this table:
CREATE TABLE `test` (
`a` INTEGER PRIMARY KEY AUTOINCREMENT,
`b` INTEGER
);
Editing this and removing the primary key would lead to this table
statement:
CREATE TABLE `test` (
`a` INTEGER,
`b` INTEGER,
PRIMARY KEY()
);
This is fixed by this commit, the invalid empty primary key line isn't
outputted anymore.
