-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test file-based db read/write operations #345
Conversation
15ed9d9
to
19bb208
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like a worthy thing to test a little, but not too much.
In the QSM tests I originally had an Open
command for testing this type of thing. However I removed it because I confirmed that the wallet process will only ever have a single DBLayer instantiated during its lifetime. So we can assume no concurrent access to .db files, and that the very well tested SQLite library will handle "power cable unplugged" type situations.
@@ -177,17 +178,17 @@ newDBLayer | |||
:: forall s t. (W.IsOurs s, NFData s, Show s, PersistState s, W.TxId t) | |||
=> Maybe FilePath | |||
-- ^ Database file location, or Nothing for in-memory database | |||
-> IO (DBLayer IO s t) | |||
-> IO (Sqlite.Connection, DBLayer IO s t) | |||
newDBLayer fp = do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps call this newDBLayer'
and have newDBLayer = fmap snd . newDBLayer'
?
# Ignore everything in this directory | ||
* | ||
# Except this file | ||
!.gitignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reckon it will be better for tests to create a new directory in /tmp
so that they're less susceptible to differences in local state.
close conn | ||
|
||
|
||
prop_randomOpChunks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
prop_randomOpChunks | |
-- This property checks that executing series of wallet operations in a single | |
-- SQLite session has the same effect as executing the same operations over | |
-- multiple sessions. | |
prop_randomOpChunks |
unsafeRunExceptT $ createWallet db testPk testCp testMetadata | ||
listWallets db `shouldReturn` [testPk] | ||
close conn | ||
forM_ [1..25] openCloseDB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would replicateM_ 25 openCloseDB
be equivalent?
-> s | ||
-> s | ||
-> Expectation | ||
testOpeningCleaning call expectedAfterOpen expectedAfterClean = do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect that cleanDB is already pretty well tested because it's run before every DBSpec test case.
But I think the intention of this is to check that changes made with one connection have an effect on the db file, which can be seen from subsequent connections.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cleanDB works fine - I agree, but we had problem with closing DB. See comment below for more details on it
I'm guessing the SQLite ErrorBusy exception is due to the tests not promptly closing the database connection. |
19bb208
to
fd3ca18
Compare
@rvl @KtorZ I made not so small investigation. When we have disk-backed db we should probably be able to close gracefully. I added a number of tests to persuade myself and others that this is the case. A number of things popped out:
Moving forward, I was not able to just migrate and addIndexes. I dived deeper and this was probably because of not using Still createSqlBackend needs refactoring and we have one property test failing (although open/close tests and unit tests passes) :
In detail we have in CI (the same reason as above listed ):
I believe, this kind of testing is important as it is exposing some not so obvious issues that could come up with db connection and would be very difficult to understand later. |
enableForeignKeys conn = do | ||
stmt <- Sqlite.prepare conn "PRAGMA foreign_keys = ON;" | ||
_ <- Sqlite.step stmt | ||
Sqlite.finalize stmt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is needed to be able to close and avoid SQLite3 returned ErrorBusy while attempting to perform close: unable to close due to unfinalized statements or unfinished backups
backend <- wrapConnection conn logFunc | ||
pure (conn, backend) | ||
|
||
createSqliteBackend1 :: Maybe FilePath -> LogFunc -> IO SqlBackend |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need still to think how this can be married with createSqliteBackend
(conn, _backend) <- createSqliteBackend fp (dbLogs [LevelError]) | ||
|
||
let runQuery' cmd = | ||
withMVar bigLock $ const $ runResourceT $ runNoLoggingT $ withSqlConn (createSqliteBackend1 fp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using withSqlConn
is needed to be able to close and avoid SQLite3 returned ErrorBusy while attempting to perform close: unable to close due to unfinalized statements or unfinished backups
OR we can somehow use close'
there (remarks refers to file-based solution)
Strange:
gives In contrast to
which works fine. |
7b75243
to
87e8346
Compare
@paweljakubas I look through the tests, poked some things, and tried to make the failing test pass. However I don't think it's a realistic test to call |
f4a6d02
to
7b75243
Compare
…capability to close it compile fix
hlint fix
7b75243
to
71ebcd8
Compare
Closing in favor of #370 |
Issue Number
#154
Overview
newDBLayer
in order to have a possibility toclose
it. I presume it will be needed in file-backed db instancesComments
I have an error - need to investigate it
but not really confident here as I have :