On 10/29/2016 13:06, Richard Hipp wrote:
>SQLite should preserve data in such case, it should fail operations that
>can't be performed, but the old data should absolutely stay intact.
That is what is suppose to happen - everything should be preserved.
This is tested extensively and there are no known problems in SQLite
that can cause the behavior you observe. But perhaps you have come
across something nobody has yet seen or thought of. (Or perhaps the
problem is with some other component other than SQLite - we don't know
yet.)
Do you have a way to reproduce the problem? Do you have any
additional information that might help us to reproduce it here?
I spent all morning trying to reproduce the problem with the in-memory
disk having disk-full and couldn't reproduce it. I didn't see any
'delete' operations issued by my program, this was as expected. But no
row disappearance.
I think you need to have such testcase: On the table with a lot of
key/value pairs you run a set of updates and inserts. Random file
operations should fail with some low probability with various error
codes, like disk full. The test should check that all updated values
still have either old or new values, and not anything else. All inserted
values should be checked to be either there or not there, and values
untouched by queries should stay intact. Nothing should disappear.
The tricky part might be to simulate file failures. But sqlite library
is essentially a convertor between the SQLite API executing SQL
statements, and the file access API provided by OS. You can't guarantee
the behavior of the file API that you don't control, so random failures
in it should be processed properly.
Only if such case passes every time after a lot of tries with random
file failure this can be an assurance that there are no such bugs in SQLite.
Software often relies on certain behavior of the outside API, and when
those calls once in a while behave differently
What does "PRAGMA integrity_check" say about your database?
It returns "ok", but this file has been opened and written into again.
Yuri
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
