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.
Make it possible to rename the columns of already existing tables using
the EditTableDialog. This is a feature we lost somewhere around commit
b36800ea02.
Remove the dirty flag as it is no longer needed. Because we track the
savepoints currently held open we can just use that list to see wether
there are changes to be committed. So there is no need to track this in
a separate variable.
Allow multiple savepoints in DBBrowserDB, i.e. setRestorePoint() doesn't
simply return if the DB is already set to dirty but creates an
additional savepoint.
Track the names of all savepoints which have not been either saved or
reverted yet.
Finally, and that's the whole point of this commit, change the savepoint
logic of the EditTableDialog. We used to have a transaction started when
opening a database which was only committed when the file was closed
again. This way the EditFileDialog could savely create a savepoint when
being opened and just release it when OK was clicked or revert to it
when cancel was clicked. Getting rid of the transaction broke this
logic. The dialog still worked but as the savepoint was released when
the changes were applied all changes made via the dialog were
immediately committed to the database. So clicking the revert button had
no effect on those changes. This is at best an unexpected behaviour but
could also be a problem when some changes are reverted while others
aren't. So, having the option now of keeping multiple savepoints opened
this problem can be fixed by just creating a new savepoint every time
the dialog is opened, reverting to it when it is cancelled and _not_
releasing it when OK is clicked.
I hope this works!
