This fixes issues that assigning the main representation of the database
in DBBrowserDB::objectMap is modified when playing around with the
database in the Edit Table and Edit Index dialogs.
These bugs were caused by my refactoring. Let's hope there's not much
more fallout from this refactoring...
This finally gets rid of the DBBrowserObject class entirely and moves
all its functionality to the newer classes in the sqlb namespace.
I'm still not entirely happy with this but at least things should be a
little more consistent now.
In the SQL export don't use the base table name of a table when you
should actually use the table name itself. The way SQLite reports its
data these just happen to be the same for tables.
This doesn't change anything when it comes to functionality but is
semantically more correct.
Parsing views or generating a CREATE VIEW statement isn't implemented
yet.
Also unify the process by which it's possible to retrieve information on
the fields of a database object.
Simplify the code by storing the flag that indicates if the parsing was
successful in the parsed object itself instead of handing around pairs
of parsed objects and bools.
This changes the class structure in the sqlb namespace as well as the
DBBrowserObject class. The rest of the commit are changes that are
required by the modifications in sqlb and DBBrowserObject.
The idea behind this refactoring is this: we currently have the
DBBrowserObject class which holds some basic information about the
database object (name, type, SQL string, etc.). It also contains a
sqlb::Table and a sqlb::Index object. Those are used if the type of
the object is table or index and they contain a whole lot more
information on the object than the DBBrowserObject class, including the
name, the type, the SQL string, etc.
So we have a duplication here. There are two class structures for
storing the same information. This has historic reasons but other than
that there is no point in keeping it this way. With this commit I start
the work of consolidating the sqlb classes in order to get rid of the
DBBrowserObject class entirely.
This commit only starts this task, it doesn't finish it. This is why it
is a little messy here and there, but then again the old structure was a
little messy, too. We will need at least a very basic trigger and view
parser before finishing this is even possible. When this is done, I hope
the ode will be much easier to read and understand. But even in the
current state there already is some progress: we save a little bit of
memory, don't copy big objects all the time anymore, and replace a lot
of unnecessary string comparisons with integer comparisons.
When renaming a column of a table it might be necessary to recreate any
triggers nd indices referencing this column. There are several reasons
why this might fail and which are difficult to catch for us. For this
reason we just show an error message to the user in these cases so they
can fix the statements and run them manually. Previously to this commit
this error message contained a list of all SQL statements which were
tried to execute. So if you had 10 references to the table (not the
column!) and 7 of them could be recreated, the error message would still
have shown all 10 SQL statements. With this commit it only shows the
remaining 3 statements. This should make the dialog much easier to print
for large databases and makes it much easier for the user to grasp.
Suppose you have this database:
CREATE TABLE a(
x INTEGER,
y INTEGER
);
CREATE INDEX i ON a(x ASC);
Now, when trying to rename column x of table a to some other name using
the Edit Table dialog will work but index i will be lost during the
process. This is because it needs to be recreated after having modified
the table, however its create statement isn't valid anymore because the
column name x doesn't exist anymore. This is changed by this commit to
significantly increase the chance that renaming a column won't throw an
error, thus making the Edit Table dialog a lot safer to use.
Just like the Edit Table dialog, this dialog handles both creating and
editing. For consistency's sake this dialog is therefore renamed to Edit
Index dialog.
Improve the Create Index dialog so that it allows creating as well as
editing indices.
Chenge the code for the main window to allow editing existing indices.
This commit adds support for CREATE INDEX statements to our grammar
parser. The new parser is called for each index when reloading the
database schema. However, the resulting index representation isn't used
yet. Also note that this duplicates some code, though not much. The idea
is to consolidate this later in a way that includes triggers and views
as well.
This adds a new class for indices, similar to the one for tables. This
class is supposed to make creating and editing indices a lot easier,
making all manual string concatenation unnecessary.
For now this is only used for simplifying the index creation procedure
in the Create Index dialog.
You can create temporary table using CREATE TEMPORARY TABLE xxx
statements. DB4S shows them as ordinary tables which is fine most of the
time. However, it wouldn't remember the temporary status when editing
them via the Edit Table dialog. This means that editing them would
create a normal, non-temporary table. This is fixed by this commit.
When opening a database fails a proper error message is now shown which
hopefully tells the user what the source of the problem is. Note: this
will only work for newer versions of SQLite.
This requires a bug fix which is included in this commit. The error
message wasn't taken from the correct database handle, so it had nothing
to do with the actual error source. This is fixed by this commit as
well.
This fixes two issues with unusual but valid data types for columns:
1) When having a data type that consists of more than one word these
wouldn't be separated anymore after parsing. This is fixed now. Example:
CREATE TABLE test(a long int);
would have become
CREATE TABLE test(a longint);
2) Some keywords are allowed to be used as data types. Parsing these
tables would have failed entire prior to this. This is fixed, too.
Example:
CREATE TABLE test(a no);
would fail.
This fixes tables like these where a keyword (in this case NO) is used
as an unquoted default value for a column:
CREATE TABLE test(a DEFAULT NO);
See issue #877.
