This test fails fairly often. On my system, I can trigger it with:
go test . -run=TestExecContextCancel -count=10 -failfast -v
This makes the test less flaky by timing out the context after a
consistent 50 millisecond delay. This was enough time for the query
to start, then get cancelled with sqlite3_interrupt() in my tests.
This now passes the above check.
This is a modified version of the change suggested in:
https://github.com/mattn/go-sqlite3/pull/865
Commit 4f7abea96e added a test that uses Conn.Raw, which was added in
Go >= 1.13. The go-sqlite3 project runs tests with Go >= 1.11. Remove
the test from sqlite3_test.go, so it only runs with the correct
versions of Go.
Instead of adding a new test, modify the existing test that already
uses Conn.Raw() to check the type of driverConn.
* Fix "cannot start a transaction within a transaction" issue
[why]
If db.BeginTx(ctx, nil) context is cancelled too fast, "BEGIN" statement can be
completed inside DB, but we still try to cancel it with sqlite3_interrupt.
In such case we get context.Cancelled or context.DeadlineExceeded from exec(),
but operation really completed. Connection returned into pool, and returns "cannot
start a transaction within a transaction" error for next db.BeginTx() call.
[how]
Handle status code returned from cancelled operation.
[testing]
Added unit-test which reproduces issue.
* Reduce TestQueryRowContextCancelParallel concurrency
[why]
Tests times out in travis-ci when run with -race option.
Set go_import_path to tell Travis-CI where to checkout the code, so the
Travis build can also work on forks. This is important when building
without Go modules support.
Changes in Go versions for the Travis-CI builds:
- reverse order of Go versions so the latest ones are checked first
- add Go 1.14.x (latest stable) at the first position
- use 'tip' instead of 'master' (like https://tip.golang.org) and move
it just after 1.14.x
My app can use PostgreSQL and – optionally – SQLite. I would like to be
able to compile the app without cgo when SQLite isn't used, as this
removes the need for a C compiler which makes builds easier and faster,
especially for end-users.
In the simple case, this is not a problem go-sqlite3 already provides a
simple non-cgo mock so it compiles and gives a runtime error if you try
to use it anyway.
However, now I'd like to register a function for my SQLite connection to
match a PostgreSQL function like so:
sql.Register("sqlite3_custom", &sqlite3.SQLiteDriver{
ConnectHook: func(conn *sqlite3.SQLiteConn) error {
return conn.RegisterFunc("pow", pow, true); err != nil {
},
})
But this makes it quite hard to keep the same logic since it refers to
types that don't exist with CGO_ENABLED=0. I will need to create a db.go
with `+build !cgo` and db_cgo.go with `+buid cgo` which duplicates all
the logic but with the sqlite hooks. In my case, this actually affects
quite a lot; for example I have a helper function which connects and
runs migrations and whatnot which looks like:
type ConnectOptions struct {
Connect string // Connect string.
Schema []byte // Database schema to create on startup.
Migrate *Migrate
SQLiteHook func(*sqlite3.SQLiteConn) error
}
And I'd have to have two versions of that, too. You could perhaps do
something with interfaces, but because the sql.Register() call above
references the `sqlite3.SQLiteDriver.ConnectHook` struct field that's
not so straightforward (and wrapping stuff in interfaces probably won't
do much for the general clarity either).
This simplifies all of that by providing some common types that may be
used when setting up a SQLite connectin. I renamed the
`SQLiteDriverMock` to `&SQLiteDriver` for this reason. As far as I can
tell in my testing, this has no real downsides (but perhaps I missed
something?)
---
Note: it might also be worth doing something similar for error.go, as I
already have two variants of the below function (one with cgo as below,
and one without cgo which checks just PostgreSQL):
// ErrUnique reports if this error reports a UNIQUE constraint violation.
//
// This is the cgo version which works for PostgreSQL and SQLite.
func ErrUnique(err error) bool {
var sqlErr *sqlite3.Error
if errors.As(err, &sqlErr) && sqlErr.ExtendedCode == sqlite3.ErrConstraintUnique {
return true
}
var pqErr *pq.Error
if errors.As(err, &pqErr) && pqErr.Code == "23505" {
return true
}
return false
}
This is a lot more manageable than the ConnectHook case, but it would be
nicer if it would work without the need for build tags.
* Allow unused named parameters
Try to bind all named parameters and ignore those not used.
* Allow "@" and "$" for named parameters
* Add tests for named parameters
Co-authored-by: Guido Berhoerster <guido+go-sqlite3@berhoerster.name>
Once the regex encountered the first instance of a non-match, it would return without processing the rest of the rows in the statement. This change allows it to process the remaining, only setting the sqlite3_result_int to zero then continuing. This worked fine for the example as it only had one item to process.
* adding SystemErrno to Error, and fixing error logic when open fails
* fix for old versions of libsqlite3 that do not have sqlite3_system_errno defined
* fixing pre-processor logic
[why]
see https://github.com/mattn/go-sqlite3/issues/607
SQLite default journal mode is DELETE, but forcing it on open causes "database is locked"
if other connection exists with WAL mode, for example.
[how]
Don't set DELETE mode if not set in DSN explicitly.
[testing]
Run tests in my project where WAL mode is used.
[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.
