When pushing a local database to the remote server, the new commit id is
returned. Grab that id and insert it into the database of local
checkouts. If there already is an entry for the given file, update that
record. When doing an initial push of a database, also copy the source
database file to our checkout directory to avoid redownloading the file
upon first use.
This should eliminate all unnecessary database downloads, both after
doing the initial push and after committing a modified database.
Instead of just adding and adding records to the local checkout
database, search for a previous checkout and update its record. This
avoids all sorts of problems in the rest of the code which always
assumed that there is only one record per file.
This fixes a crash that occurs if there is an error while fetching
something other than a database and no database has been downloaded
before, e.g. when getting the root directory listing fails.
If there is a local clone of a remote database but the remote database
has been updated to a newer version in the meantime, we're now asking
the user what to do. The choice is between downloading the newer version
and overwriting the local one with all the changes it might have
contained or opening the local version and not downloading anything.
See issue #1096.
This feature isn't explicitly available via the UI (yet) but should
prevent errors when the user is faster than the network connection, e.g.
when opening two directories very quickly.
When changing the client certificate we need to clear the authentication
and access cache of our Qt network access manager instance. If we don't
do so, Qt might decide to use the old certificate information which is
still in the cache for some recurring queries.
This improves the user experience for pushing database files. Before
this you had to type in the entire URL for pushing, e.g.:
https://db4s-beta.dbhub.io:5550/username/databasename
With this the host name as well as the user name is taken from the
currently active client certificate. So all you have to type in now is
the database name. And for this we make a sensible automatic suggestion
based on the name of the local file you're trying to push.
Note that while this makes pushing databases a lot easier, it still
doesn't implement proper version control or any extra code for handling
conflicts etc.
This commit removes the File -> Remote menu entirely. The only menu item
that was left was the Save to Remote item which is replaces by a button
in the remote dock.
The button is only enabled when a database file is opened and the user
has logged in using a certificate.
Clicking the button opens the same dialog and performs the same actions
as before. The only difference is that we don't use the first client
certificate - no matter which one it is - but instead use the client
certificate that was used for logging in.
This changes all the code to use the commit id of a database version
instead of a version number. This means changing the UI, the code for
the communication with dhhub.io, and the internal database for storing
information on downloaded databases.
The last step makes it necessary to delete that database file on your
system, so it will be recreated! Please do that :)
This adds a local database to keep track of all the cloned databases.
For now we only use this information to prevent exactly the same
database being downloaded twice.
Rename the settings accessor functions from Settings::getSettingsValue()
(and similar) to Settings::getValue() (and similar). The 'Settings' bit
seems a bit redundant and costs a lot of screen space.
When fetching a remote database automatically generate a file name to
save the database as instead of asking the user for a path and name.
Also add a preferences option to set the directory for all cloned remote
databases.
This is obviously a trade-off: on the one hand this makes opening remote
databases simpler (it's just a double click), on the other hand it takes
control away from the users. The main reason for doing this, however, is
to indicate to the user that the cloned databases are going to be
controlled by DB4S. We have to keep track of the local databases in
order to update them from the right place, push them back to the right
place, etc. And because the local copies are under DB4S control we don't
want the user to move, rename, or delete them.
Move the network part of the automatic version check code into the
dbhub.io parts. While semantically this doesn't make a lot of sense it
simplifies the code a bit, reduces the size of the main window class,
and avoids duplication of code e.g. when introducing proxy support.
Fix progress dialog interfering with the save file dialog.
Fix cancelling of progress dialog. Before this you couldn't download a
file anymore after cancelling a download.
This adds a new dock to the main window that contains all the remote
functionality (or is supposed to contain it all in the future).
It also adds a directory browsing feature which allows you to browse
through the folders and files on the dbhub server.
By double clicking a database you can download and open it. The Open
Remote menu action isn't needed anymore and has been removed.
This also fixes an issue with pushing databases where, after sending the
file is completed, the save dialog was opened.
Note that this is still WIP and is far from polished.
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.
Add a list of all configured client certificates to the preferences
dialog and show some information on them.
Add two button to the preferences dialog to add and remove client
certificates.
Copy configured client certificates to some safe place where they aren't
deleted by accident.
Change the remote code to expect certificate and private key in one
file. The path to this file is still hardcoded, now to client.cert.pem.
Remove the example client certificate as it's not up-to-date anymore
anyway.
Still missing: Option to use a configured client certificate from the
preferences dialog to authenticate.
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.
Previously we'd only ignore errors about a single self signed
certificate but apparently it's an entirely different matter to Qt or
OpenSSL if we're talking about a self signed certificate in a
certificate chain.