| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
This commit adds the `sqlite_os_trace` build tag which sets the
`SQLITE_FORCE_OS_TRACE` and `SQLITE_DEBUG_OS_TRACE` compilation
flags. This produces verbose debugging output of every operating
system call made by SQLite.
|
| |
|
|
|
|
|
|
|
| |
(For #965.)
This retraction will take effect when this commit is included in the
latest v1 release (presumably v1.14.11).
|
| |
|
|
|
| |
Support returning any from callbacks
|
|
|
|
| |
Based on https://golang.org/pkg/database/sql/#Tx.Commit this function returns an error type.
So why not check it.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This commit adds the SQLiteConn.FileControlInt() method which calls the
underlying sqlite3_file_control() function with an int argument. This can
be used for low-level operations on SQLite databases such as persisting
the WAL file after database close.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
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.
|
| |
|