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.
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.
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 cleans up the main window class a bit which was getting quite large
and a bit harder to maintain than necessary.
This commit also includes two minor fixes to the plot system:
- The plot widgets are now disabled when no database file is opened.
- The progress bar shown when fetching all data is now initialised with
the correct row numbers.
Other than that this commit should in theory not change any
functionality.
This adds a basic table of 12 colours which DB4S chooses from when new
plot graphs are added. This also introduces a pointer to this table of
colours which if moved forward each time a graph is added. This it's
less likely that two graphs have the same colour in one plot.
A better but more complex approach would be to find an algorithm to
generate new colours dynamicalls. See issue #816 for details.
When trying to fetch a database don't load a hardcoded client
certificate but grab one from the certificate manager in the preferences
dialog.
Also add support for password protected private keys.
Note: Since this is all testing code on the front-end side, we just use
the first certificate in case multiple certificates are configured.
The fetch all data button in the plot area would load all data as if the
Browse Data tab was active even though the plot is based on a SQL query
in the EXecute SQL tab. That would lead to non-sensical results. With
this commit the button always load the correct data.
See issue #820.
Change the layout of the preferences dialog a bit.
Remove the server selection combo box from the preferences dialog as it
will probably never be required. The way we do logins using certificates
kind of makes this obsolete, I think.
Restructure the whole remote code a little bit. Also add helper
functions here and there.
Show a list of our the CA certificates built into the application in the
preferences dialog. This list is read only of course but still
informative as it tells the user which sites are supported ny DB4S.
This adds basic support for fetching databases via HTTPS using client
certificates. You can include CA certificates to verify any responses
from a server. For now, one test CA certificate is included but it's
easy to add more.
It's also possible to authentify the client using a client certificate,
a client key and a password. As of this commit all three items are
hardcoded.
It's still possible to access any remote database via HTTP but if a
request URL starts with 'https' this new mechanism will be used.
All certificates, keys, and password included in here are taken from my
node.js test server repository. They will be replaced soon-ish.
This adds some initial support for opening remote files. You can enter a
URL and DB4S will try to download the file. When successful you'll be
able to specify a place and name to save the file under, and after
saving it locally to disk it'll be opened just like any local database
file.
See the included TODO comments for missing features. Most notably
missing is the HTTPS and certificate handling code. Also any support
for storing the remote source of a database is lacking.
Store and restore the plot settings for each table - just like the
filter values or the column widths. This way you can have multiple
plots, one for each table.
Also, save these settings in the project files.
Fetching all table data using the button in the plot area might take a
long time. This commit adds a progress dialog which is displayed while
loading all the data.
See issue #499.
This enables plotting even for those columns which contain NULL values.
To distinguish NULL from a numeric 0 there is nothing drawn for NULL
values, i.e. there is a gap in the graph.
See issue #822.
Make the reload shortcut (at the moment F5 and Ctrl+R) dependent on the
currently active tab. This way it always performs some meaningful task,
depending on the current context.
See issue #759.
Report any errors that might occur while saving changes to the database
to the user. Also warn the user that this means the database wasn't
saved entirely.
See issue #770.
Previously, it was running the query at the current cursor position, but that
proved to be confusing. Now, it runs the SQL that contains the start of the
current line. So having:
SELECT * FROM table1;
SELECT * FROM table2;
and the cursor either before the first semicolon, either after it, the first
SQL will be run, and not the second one as before.
If the last character was a semicolon and the cursor was placed after
it, the Execute current line action didn't execute anything. It now
execute the last SQL found
