When reading in the DB layout use our SQL grammar parser to determine
the fields of a table. This simplifies the code a bit and might also
give more detailed information in some situations.
Save views, triggers and indices before deleting the old table in
renameColumn() and try to create them again after renaming the new
table. This is likely to fail and we'd probably need a grammar for these
objects to make the appropriate changes, so in case it does fail this
just prints a warning with some ideas of what to do.
Fix the updateSchemea() method to also read and save the not null flag
and the default value of each column.
This fixes a problem in renameColumn() which made it "forget" these
values. It is now possible to set the not null flag of multiple columns
in EditTableDialog.
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.
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!
Add a new dialog which is shown when compacting the database. This
dialog allows selecting single objects individually to avoid vacuuming
the entire database.
It also shows a new warning if the database is dirty as changes are
going to be saved before vacuuming.
Create a restore point in executeSQL and executeMultiSQL instead of just
setting the dirty flag. This way the changes made using these functions
are not applied immediately when no restore point was created yet.
When creating a SQL dump of the database don't export the sqlite_stat1
table as it's impossible to import it later because SQLite generates it
automatically.
Remove some useless debug messages, e.g. because they just print an SQL
string which you can see in the SQL log window anyway.
Change some "critical" errors messages to just warning. No sense in
printing a critical error message when the program can handle the
problem by itself.
Now it should always be possible to add a new record,
no matter how the table is defined or what the new data default is.
The default new data setting will be removed in the next commit.
Rewrite the import SQL code using a similar method to the one used in
executeQuery(). This makes the code much easier to read and removes the
last remnants of that C code stolen from some demo application.
Store the data of a DB cell in a QByteArray, i.e. a binary data type,
instead of putting it in a QString, thus converting it to a UTF8 string.
Rewrite the reading and writing of DB cells to correctly handle binary
data containing 0x00 bytes.
Change the edit dialog to actually do all the data checks etc. on a
currently invisible QHexEdit widget instead of a QTextEdit.
All these changes combined make it possible to actually store binary
data without it being corrupted. You can for example import pictures
now, export them and actually open the exported file. So this is an
improvement.
