mattn / go-sqlite3 / 1 / 13
53%
master: 54%

LAST BUILD BRANCH: add-github-actions
DEFAULT BRANCH: master
Ran
Files 8
Run time 2s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 66.354% (+0.6%) from 65.772%
GOTAGS=trace

push

travis-ci-com

arp242 
Add mock versions of SQLiteDriver and SQLiteConn for +build !cgo

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
non-existing types. 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
some stuff with interfaces, but because the sql.Register() call
references the sqlite.SQLiteDriver.ConnectHook struct field that's not
so straightforward, either.

This simplifies all of that by just providing some common types that may
be used in this case. 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 the same for error.go, as I already
have two variants of the below function (one with cgo as below, and one
with... (continued)

779 of 1174 relevant lines covered (66.35%)

83996.14 hits per line

Source Files on job 1.10 (GOTAGS=trace)
Coverage ∆ File Lines Relevant Covered Missed Hits/Line