| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
| |
Currently, no way to fix failing
|
| |
|
|
|
| |
* Add go.mod and go.sum for upgrade
* Fix upgrade tools to have to run on upgrade directory
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Selecting only some tests with go test -run=... does not work, because
some of the tests are executed using testing.RunTests(). That function
is documented as "an internal function". This changes TestSuite to use
the testing subtests feature instead.
This has a behaviour change: the benchmarks now need to be
selected at the command line with the standard go test -bench=.
flag. This will also set up the test database twice when running
benchmarks, rather than once.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* sqlite3_type update
The main reason for this change is that the original reflected values are nil. I found that there was no good mapping when dealing with the code here
* Update sqlite3_type.go
Update 'ColumnTypeScanType' method,
Different types of mapping values
* Restore copyright
* Update go.mod
* Update go.mod
|
| |
|
| |
uses snippet suggested by @rittneje https://github.com/mattn/go-sqlite3/issues/897#issuecomment-752162125
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The busy_timeout pragma was added in sqlite 3.7.15 as an alternative
to calling sqlite3_busy_timeout directly:
https://sqlite.org/pragma.html#pragma_busy_timeout
While there's no functional change here, using the pragma does align
setting busy_timeout with other settings and removes the special case
for calling sqlite3_busy_timeout directly.
|
| | |
|
| | |
|
| |
|
| |
seperated -> separated
|
| |
|
| |
Do not use `-u` flag when fetching go-acc
|
| | |
|
| |
|
|
|
|
|
| |
* chore: readme: Fix link, typos, copy editing
Also closes #914, #939.
* Update README.md
|
| |
|
| |
fixes #963
|
| | |
|
| |
|
|
|
| |
* Update amalgamation code
* Apply realPy's patch
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
* Go get go-acc with environment variable for go modules
* Go get with modules for windows as well
|
| |
|
|
|
| |
* Adds a fuzz target
* Fixes memory leak
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This can be used like in the test; I wrote a little wrapper around
sql.DB which uses this, and allows concurrent reads but just one single
write. This is perhaps a better generic "table locked"-solution than
setting the connections to 1 and/or cache=shared (although even better
would be to design your app in such a way that this doesn't happpen in
the first place, but even then a little seat belt isn't a bad thing).
The parsing adds about 0.1ms to 0.2ms of overhead in the wrapper, which
isn't too bad (and it caches the results, so only needs to do this
once).
At any rate, I can't really access functions from sqlite3-binding.c from
my application, so expose it via SQLiteStmt.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* add support for defining an "eponymous only" virtual table
As suggested here: https://github.com/mattn/go-sqlite3/issues/846#issuecomment-736206222
* add an example of an eponymous only vtab module
* add a test case for an eponymous only vtab module
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a shortcut for PRAGMA cache_size; this is a pretty useful setting:
the default of -2000 (2M) is not especially high, and a lot of people
will probably want to increase this.
For example, while running a bunch of fairy expensive queries in
parallel:
With SetMaxOpenConns(1):
-2000: 5762ms
-20000: 4714ms
With SetMaxOpenConns(20):
-2000: 3067ms
-20000: 2532ms
Which isn't a bad performance boost for changing a single number.
|
| | |
|
| | |
|
| |
|
|
|
| |
* Drop go1.11
* Use go1.12
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This option was enabled by default in sqlite3 on 2014-07-03.
This setting does nothing. It can now be disabled with
SQLITE_DISABLE_FTS3_UNICODE. See the upstream commit:
https://sqlite.org/src/info/0cc0230ae9cfc976
I think this change was imported into this project with commit
ee9da4840dd680d1fe2927692ea4ab5f8cd7c91c on 2015-06-12.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This "disables the use of compiler-specific built-in functions such
as __builtin_bswap32()" (from the SQLite docs) so this change might
produce slightly better code. My primary motivation, however, is that
the "default" configuration for SQLite, which is widely tested, does
not set this preprocessor macro.
From looking at Github issues, it appears this was added to avoid a
build error on Mac OS X 10.11, in 2017:
https://github.com/mattn/go-sqlite3/issues/386
There have been a number of changes to sqlite3 since we tried this
last. I think it would be worth trying to remove this setting again.
I found a machine running Mac OS X 10.11.6. It was able to build and
run the tests in this package with this change.
Mac OS X 10.11 is has not been supported by Apple since 2018
(currently Apple is releasing updates for Mac OS 10.13 and newer; 11
is the current release). However, Go 1.14 is supported, and it
requires Mac OS X 10.11 or newer: https://golang.org/doc/go1.14
Go 1.15 only supports Mac OS 10.12 and newer:
https://golang.org/doc/go1.15
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Github is disabling the add-path command in workflows on 2020-11-16.
Switch to their new preferred way of doing this, by appending to the
file referred to with $GITHUB_PATH. See:
https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-commands-for-github-actions#adding-a-system-path
This should fix the following warning from the workflows:
.github#L1
The `add-path` command is deprecated and will be disabled on November
16th. Please upgrade to using Environment Files. For more information
see:
https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
|
| |
|
| |
Closes #876
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This can be easier that registering a new driver, in some cases.
Add a test to verify that this works.
|
| |
|
|
| |
This relates to #870; it's not immediately clear that you need to pass a
different driver name to sql.Open from the documentation.
|
| |
|
| |
Fix overshadowing of entrypoint variable.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Use go-pointer instead of uintptr hacks.
Fixes #791
* Do same of go-pointer
* Drop older verion of Go
* Fix build
* Fix build
|
| | |
|
| |
|
|
|
| |
* coveralls to codecov
* README badge coveralls to codecov
|
| | |
|
| | |
|
| |
|
| |
and remove .travis.yml
|
