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...).
This commit allows you to add new rows to a table without rowid column.
The main problem here is that SQLite won't create the next value for the
primary key column itself, so we have to do that instead.
See issue #51.
This doesn't really solve the problem, but reduces the chance
to have a nameclash with rowid, until we come up with something better
we can't fully support tables with a column name _rowid_ but that should
be very seldom
This flag should indicate if we can fully handle this table definition
in our edit table dialog. if not we should do one of these things:
* disable the edit table dialog to modify the table
* display a warning message that modifying this table may remove constraints
* ??
Since version 3.8.2 SQLite supports tables without the internal rowid
column added to the table. For these tables the primary key serves as a
replacement for the rowid column.
These changes update the grammar parser to correctly handle 'without
rowid' tables and also generate 'without rowid' SQL statements.
Merge the renameColumn() and dropColumn() methods. They are just way too
long and complicated but also very similar that it makes no sense to
keep them separated.
This also simplifies the code of renameColumn() a bit while fixing the
trigger/view/index problem in dropColumn().
Store the primary key flag(s) inside the sqlb::Field objects instead of
the sqlb::Table object. Technically this doesn't make a lot of sense but
then again it makes things a lot easier for us. So this should fix quite
a few issues in the entire program, especially - again - in
renameColumn(). It also magically fixes createColumn() which had no
chance of guessing which column should be a PK prior to this.
To benefit from these changes the EditTableDialog has changes as well.
- It should now be possible to set and unset PK and AI flags and they
are actually saved.
- Setting the AI flag automatically sets the data type to Integer
because that's the only type SQLite can handle in an autoincrement
field.
- Clicking on the entry in the data type combobox which is currently
selected doesn't update the DB anymore.
This commit also makes some changes to the unit tests to reflect the API
changes made. But it also adds missing quote characters in some
verification strings.
I hope this is a worthy 500th commit - at least it's got a long commit
message...
There is also a "create table" ast walker which fills
info for the new sqlitetype objects.
A dependency to the antlr2 runtime was added.
The grammar most probably still contain bugs.
Why all this?
First writing grammars is fun and this is the only way
we can get all information for proper table editing + some time
in the future when the grammar is finished we can provide real
auto completion.
