[why]
Context cancellation goroutine is not in sync with Next() method lifetime.
It leads to sql.ErrNoRows instead of context.Canceled often (easy to reproduce).
It leads to interruption of next query executed on same connection (harder to reproduce).
[how]
Do query in goroutine, wait when interruption done.
[testing]
Add unit test that reproduces error cases.
As opposed to []byte arrays. This brings sqlite closer
in line with other dbs like postgres, allowing downstream
consumers to assume the scanned value is string across underlying
dbs.
See,
$ gometalinter --vendor --disable-all --enable=misspell ./...
sqlite3.go:1379:45⚠️ "succesfully" is a misspelling of "successfully" (misspell)
sqlite3.go:1390:30⚠️ "registerd" is a misspelling of "registered" (misspell)
sqlite3_func_crypt.go:16:27⚠️ "ceasar" is a misspelling of "caesar" (misspell)
sqlite3_func_crypt.go:43:59⚠️ "Ceasar" is a misspelling of "Caesar" (misspell)
sqlite3_opt_userauth_test.go:450:27⚠️ "succesful" is a misspelling of "successful" (misspell)
sqlite3_opt_userauth_test.go:456:27⚠️ "succesful" is a misspelling of "successful" (misspell)
Apparently the cgo typechecks get better on tip, so use C.int instead
of Go integers.
Build tip as part of the Travis build, so we can ensure that any
errors are resolved before they get released to a wider audience.
sql.Driver, sql.Conn, sql.Tx sql.Stmt, and sql.Rows are not interfaces.
Updated the comments to refer to the correct interfaces: driver.Driver,
driver.Conn, driver.Tx, driver.Stmt, and driver.Rows.
Because the closed property of the SQLiteRows's *SqliteStmt
was not guarded, it was causing an issue during context
cancellation.
be424d27ac/sqlite3.go (L1785-L1796)
When a statement is performing a query(), if it determines that
the context has been canceled, it will launch a goroutine that
closes the resulting driver.Rows if it's not already completed.
If the driver.Rows is not done (and the context has been canceled),
it will interrupt the connection and more importantly, perform
a rows.Close(). The method rows.Close() guards the closed bool with
a sync.Mutex to set it to true.
If a reader is reading from the SqliteRow, it will call Next()
and that performs this check:
be424d27ac/sqlite3.go (L1915-L1917)
Because this is not guarded, a data race ensues, and this was
actually caught by the Go race detector recently.
I didn't include a test case here because the fix seemed
straightforward enough and because race conditions are hard
to test for. It's been verified in another program that this
fixes the issue. If tests should be provided I'm more than
happy to do so.
* User Authentication Implementation
* Rename file to conform to fileformat `sqlite3_*_omit.go`
* Updated sqlite3-binding.* with new upgrade tool
* Add: callbackRetNil required for error type return because of adding `RegisterFunc`s directly on the connection.
* Add: TestCreateAuthDatabase
* Conform keys to match PRAGMA
* UPD: README
* Fix error of _auto_vacuum
* Fix error of _case_sensitive_like
* Fix error of _locking_mode
* Fix error of _secure_delete
Andrii Zavorotnii