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.
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.
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.
This adds a basic table of 12 colours which DB4S chooses from when new
plot graphs are added. This also introduces a pointer to this table of
colours which if moved forward each time a graph is added. This it's
less likely that two graphs have the same colour in one plot.
A better but more complex approach would be to find an algorithm to
generate new colours dynamicalls. See issue #816 for details.
Previously all savepoints were added to and deleted from
`savepointList`, so some savepoints could not be released, which lead to
warnings and errors, e.g. it was impossible to save database or to move
newly created row in 'Edit Table' window.
When trying to fetch a database don't load a hardcoded client
certificate but grab one from the certificate manager in the preferences
dialog.
Also add support for password protected private keys.
Note: Since this is all testing code on the front-end side, we just use
the first certificate in case multiple certificates are configured.
The fetch all data button in the plot area would load all data as if the
Browse Data tab was active even though the plot is based on a SQL query
in the EXecute SQL tab. That would lead to non-sensical results. With
this commit the button always load the correct data.
See issue #820.
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.
Add a list of all configured client certificates to the preferences
dialog and show some information on them.
Add two button to the preferences dialog to add and remove client
certificates.
Copy configured client certificates to some safe place where they aren't
deleted by accident.
Change the remote code to expect certificate and private key in one
file. The path to this file is still hardcoded, now to client.cert.pem.
Remove the example client certificate as it's not up-to-date anymore
anyway.
Still missing: Option to use a configured client certificate from the
preferences dialog to authenticate.
Change the layout of the preferences dialog a bit.
Remove the server selection combo box from the preferences dialog as it
will probably never be required. The way we do logins using certificates
kind of makes this obsolete, I think.
Restructure the whole remote code a little bit. Also add helper
functions here and there.
Show a list of our the CA certificates built into the application in the
preferences dialog. This list is read only of course but still
informative as it tells the user which sites are supported ny DB4S.
SQLite version 3.15.0 introduced a new feature called row values. These
are basically vectors of values that can be used to simplify some
expressions.
For example instead of this
CREATE TABLE x(a int, b int, c int, CHECK(a=1 and b=2));
you could write this:
CREATE TABLE x(a int, b int, c int, CHECK((a,b) = (1,2)));
However, the new syntax wasn't supported by our grammar parser which
made it impossible to access or edit that table. This commit attempts to
fix this.
lulol