Monitoring an SQLite database with QFileSystemWatcher does not work as expected
-
@JonB said in Monitoring an SQLite database with QFileSystemWatcher does not work as expected:
@l3u_
I don't really know what you expect to achieve realistically.The idea is quite simple. The database is not intended to be accessed by multiple processes. So if another process changes something while the program runs, it's possible that it breaks. By setting "locking_mode", I can prevent such changes, as simply the database can't be used by any other connection until it's closed. That's one thing I wanted (and achieved in an elegant way I think, as both my program does handle such a lock now, and e. g. a manual cli connection also refuses to work on the database as long as it's open).
The other thing is to inform the user if e. g. the file has been accidentally deleted while it's open. By now, the program doesn't know it, and on the next change, all data is gone without an error message, which is imo not a desirable behavior. Instead, an error should pop up saying something like "The database file has been deleted, so we reset our program as if we closed it now".
And this is probably possible by monitoring it via a
QFileSystemWatcher, isn't it? If I check if it's still there on each change, I know if it was deleted and can handle this. -
@l3u_
As I tried to show in examples, I do not believe you can reliably achieve what you would like to achieve, at least not cross-platform.@JonB Apart from the change protection (changes by accident by opening the same database with two program instances), I'm actually only interested in knowing if the file has been deleted during runtime … Should I simply let a
QFileSystemWatcherwatch it an check it's still there after each change? Or is this the wrong way? -
@JonB Apart from the change protection (changes by accident by opening the same database with two program instances), I'm actually only interested in knowing if the file has been deleted during runtime … Should I simply let a
QFileSystemWatcherwatch it an check it's still there after each change? Or is this the wrong way?@l3u_
I have said, I'm not convinced it will work in this circumstance, at least under Linux, and I still don't think you've said which OS you're under. But why don't you first test the situation: run up your database Qt app, then go separately try to delete the file and see whether you can? If you can, test to see ifQFileSystemWatcherdetects it correctly.I don't think you "let a
QFileSystemWatcherwatch it an check it's still there after each change". You set up aQFileSystemWatcher, then it will signal you on file delete. Rather than you do any checking at certain periods yourself. -
@l3u_
I have said, I'm not convinced it will work in this circumstance, at least under Linux, and I still don't think you've said which OS you're under. But why don't you first test the situation: run up your database Qt app, then go separately try to delete the file and see whether you can? If you can, test to see ifQFileSystemWatcherdetects it correctly.I don't think you "let a
QFileSystemWatcherwatch it an check it's still there after each change". You set up aQFileSystemWatcher, then it will signal you on file delete. Rather than you do any checking at certain periods yourself.@JonB I'm on Linux and also compile the program on Windows. And, at least on Linux, I can delete the file while it's open.
The
QFileSystemWatcherwon't only signal me on file delete, but on each change, won't it? So I will have to find out if the file has been deleted on each change, won't I? -
@JonB I'm on Linux and also compile the program on Windows. And, at least on Linux, I can delete the file while it's open.
The
QFileSystemWatcherwon't only signal me on file delete, but on each change, won't it? So I will have to find out if the file has been deleted on each change, won't I?I'm on Linux and also compile the program on Windows. And, at least on Linux, I can delete the file while it's open.
I expected that. But I'm saying: in that situation, have you actually tested whether your
QFileSystemWatchersignals you that's it's been deleted (while you still have the database open)? I'm not sure it will, you need to check.So I will have to find out if the file has been deleted on each change, won't I?
I had thought you made "on each change you make to the database". Now I think you mean "on each change signalled by
QFileSystemWatcher".void QFileSystemWatcher::fileChanged(const QString &path)¶
This signal is emitted when the file at the specified path is modified, renamed or removed from disk.Yes, that's all you get. So you would have to check whether the file still exists. Don't do that too often!
Worse, I presume this means you'll get signalled when you make changes to your own database file.
Like I said, you now need to try a bit of code to see when you do & do not get these file notification messages.
-
I'm on Linux and also compile the program on Windows. And, at least on Linux, I can delete the file while it's open.
I expected that. But I'm saying: in that situation, have you actually tested whether your
QFileSystemWatchersignals you that's it's been deleted (while you still have the database open)? I'm not sure it will, you need to check.So I will have to find out if the file has been deleted on each change, won't I?
I had thought you made "on each change you make to the database". Now I think you mean "on each change signalled by
QFileSystemWatcher".void QFileSystemWatcher::fileChanged(const QString &path)¶
This signal is emitted when the file at the specified path is modified, renamed or removed from disk.Yes, that's all you get. So you would have to check whether the file still exists. Don't do that too often!
Worse, I presume this means you'll get signalled when you make changes to your own database file.
Like I said, you now need to try a bit of code to see when you do & do not get these file notification messages.
@JonB said in Monitoring an SQLite database with QFileSystemWatcher does not work as expected:
Worse, I presume this means you'll get signalled when you make changes to your own database file.
Yes, and that's the problem – I already tried to setup a
QFileSystemWatcherand silent it when I do changes myself (because I'm only interested in changes done outside the scope of my program cf. my initial post!), but that didn't work as expected.And now I'm, not sure if using it is the right way for a case that won't happen very often. I mean if e. g. KWrite sets up a
QFileSystemWatcher, the only case it will receive a signal is when something else modified or deleted the file, because it lives and is modified in KWrite's cache, not on disk. But I work on the database directly, so it's changed with eachINSERTorUPDATEstatement … -
@JonB said in Monitoring an SQLite database with QFileSystemWatcher does not work as expected:
Worse, I presume this means you'll get signalled when you make changes to your own database file.
Yes, and that's the problem – I already tried to setup a
QFileSystemWatcherand silent it when I do changes myself (because I'm only interested in changes done outside the scope of my program cf. my initial post!), but that didn't work as expected.And now I'm, not sure if using it is the right way for a case that won't happen very often. I mean if e. g. KWrite sets up a
QFileSystemWatcher, the only case it will receive a signal is when something else modified or deleted the file, because it lives and is modified in KWrite's cache, not on disk. But I work on the database directly, so it's changed with eachINSERTorUPDATEstatement … -
@JonB Most probably, it's simply the wrong approach at all when using an SQLite database …
Perhaps, I should create a copy of the original database in a temporary location, work on this one and copy it back if the user "saves".
Apparently, it's also possible to read an on-disk database to a :memory: database and back using SQLite's backup mechanism … this way, one could work on in-memory data without having to mess with the user or other processes changing the data. But this doesn't seem to be too easy, at least, it's not supported by Qt functions.
Well, let's see if and how this can be solved …
-
@JonB Most probably, it's simply the wrong approach at all when using an SQLite database …
Perhaps, I should create a copy of the original database in a temporary location, work on this one and copy it back if the user "saves".
Apparently, it's also possible to read an on-disk database to a :memory: database and back using SQLite's backup mechanism … this way, one could work on in-memory data without having to mess with the user or other processes changing the data. But this doesn't seem to be too easy, at least, it's not supported by Qt functions.
Well, let's see if and how this can be solved …
@l3u_
This is all possible.But why is your situation so special? Many programs will "not do well" if something external deletes whatever files they need. Why isn't the world full of code for dealing with what if someone deletes a database you're using? Have you asked this as a non-Qt question on stackoverflow? That's how I see it.
-
@l3u_
This is all possible.But why is your situation so special? Many programs will "not do well" if something external deletes whatever files they need. Why isn't the world full of code for dealing with what if someone deletes a database you're using? Have you asked this as a non-Qt question on stackoverflow? That's how I see it.
@JonB It's not speacial at all I think – I thought I could make my program a bit more fool-proof without much effort, but perhaps, I simply should leave it as-is, as nobody can expect it to work normally if an open database is manipulated or deleted – and if somebody does so, he or she will know what he or she does ;-)
-
@JonB It's not speacial at all I think – I thought I could make my program a bit more fool-proof without much effort, but perhaps, I simply should leave it as-is, as nobody can expect it to work normally if an open database is manipulated or deleted – and if somebody does so, he or she will know what he or she does ;-)
