The grammar parser returns a bool value to indicate if it encountered
some SQL feature that it doesn't understand yet. We might as well use
that bit of information and show it to the user.
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.
This uses a somewhat different approach to the previous
one. It now selectively stores the data into either
the text *or* hex widget buffer, and only copies the
data between them when the edit mode is changed.
Additionally, unneeded copy operations are minimised
where possible to reduce overall slowdown.:
Don't allow the user to type in a field name that is already used in
the edited table. Show a warning and reset the name if he tries do so
anyway.
Also fix the warning for the foreign key check. Here a warning was shown
and the renaming cancelled but the field name wasn't reset to the old
value.
When generating SQL statements properly escape all identifiers, even
those containing backticks which apparently are allowed inside
identifiers in SQLite.
See issue #387.
In the EditTableDialog, when trying to edit a column which is referenced
in a foreign key of some other column (and thus cannot be changed
without errors ocurring during the rename process) print an error
message instead of just going on.
See issue #362.
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...).
When editing an existing table with a function used inside a default
value of a field add a '=' character before the default expression
string to match our own input format for these kind of default values.
See issue #166.
This is a first rough implementation of QScintilla support as SQL text
editor.
It should work mostly and build fine with qmake as well as cmake. The
new code supports all the features of the old one plus adding a few
subtle improvements. The main point of this, however, is reducing the
code we have to maintain and making it easier to add new features to the
editor.
Apparently SQLite supports empty table names for whatever reason. This
commit patches SQLiteBrowser to support databases with a table with an
empty name. I haven't removed the check for an empty table name in the
Create/Edit table dialog though because you probably really shouldn't
create such a table.
See issue #194.
When entering a default value like "=(strftime('%s','now'))", don't
quote it but remove the '=' character and use the following expression
as default value.
See issue #166.
Commit c29702a1b9 fixed the handling of
default values and added a check to enforce quote characters when they
are needed. This check wasn't prepare for empty default values (i.e. no
default value) and would add quote characters in this case, too. This is
fixed by this commit.
See issue #133.
Fix the handling of default values in the Edit Table dialog by doing two
things: First, change the sqlb::Field class so that it doesn't put quotes
around any default values no matter what. This breaks for example NULL
default values but also causes invalid syntax if the default value is
already in quotes. Secondly, change the Edit Table dialog itself to
double check if the user should've put quotes around their default value
but hasn't. In this case add them automatically.
See issues #64 and #126.
Add a checkbox for setting the 'WITHOUT rowid' flag in the
EditTableDialog. All functionality concerning the checkbox is
implemented by this commit with one exception: Setting/unsetting the
flag on an existing table won't perform any changes yet.
See issue #51.
This adds support for editing and deleting rows from tables without
rowid. It also fixes a check in the EditTableDialog when activating the
not null constraint as well as making some progress when it comes to
adding new rows.
Also 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
* ??
All the editing in the EditTableDialog, that is the DBBrowserDB class to
be specific, messes up the current representation of the DB schema. This
is fine when the changes are actually committed by clicking the OK
button but causes confusion when the dialog is cancelled. None of the
changes are actually written to the database but the UI looks like they
are.
This closes issue #74.
Also update the internal table representation and thus the SQL string at
the bottom of the window when the type of a column is changed
automatically, e.g. when the AI checkbox is clicked.
Closes#24.
Spaces in table, index and field names are actually allowed by SQLite,
so no need to check for them.
However, "`" characters cause problems when appearing in SQL statements
so disallow them instead.
Add two buttons to move the currently selected field up or down to allow
changing the field order of a table.
Extend the DBBrowserDB::renameColumn() method to support changing the
position of a field.
Delete the getTableSQL() method in DBBrowserDB. Because we reload and
store the SQL statements for tables after every change to the DB layout
we can just use these strings instead of having an extra function doing
an extra DB query. This simplifies the code a bit and also reduces the
number of SQL statements executed by the application.
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().
Show a warning and abort the action when trying to set the auto increment
flag on a column with non-integer values in it because SQLite doesn't
allow setting the flag on these columns.
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...
When setting the Not Null flag of a column in an existing table check if
there are rows with NULL values in this column before making any
changes. This avoids an error in renameColumn() caused by the INSERT
INTO ... SELECT ... statement failing. In a next step we could check if
a default value for this column has been specified and use this in these
kind of situations.
Allow setting the default value, the check values and under some
circumstances the not null flag when editing existing tables.
This required some changes to DBBrowserDB::renameColumn() which is now
using some more features of sqlitetypes.cpp but could still be improved.
Restore the possibility to change the data type of a column of an
existing table - a feature we lost some time ago.
Also change the updateTypes() method to not actually update the types of
all columns when only one can be changed at a time.
