2019-11-18 12:03:31 +03:00
|
|
|
// Copyright (C) 2019 Yasuhiro Matsumoto <mattn.jp@gmail.com>.
|
|
|
|
|
//
|
|
|
|
|
// Use of this source code is governed by an MIT-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
2024-01-25 16:36:27 +03:00
|
|
|
//go:build !cgo
|
2018-02-01 07:24:37 +03:00
|
|
|
// +build !cgo
|
|
|
|
|
|
|
|
|
|
package sqlite3
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"database/sql"
|
|
|
|
|
"database/sql/driver"
|
|
|
|
|
"errors"
|
|
|
|
|
)
|
|
|
|
|
|
Add mock versions of SQLiteDriver and SQLiteConn for +build !cgo (#819)
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.
2020-06-05 16:06:55 +03:00
|
|
|
var errorMsg = errors.New("Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub")
|
|
|
|
|
|
2018-02-01 07:24:37 +03:00
|
|
|
func init() {
|
Add mock versions of SQLiteDriver and SQLiteConn for +build !cgo (#819)
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.
2020-06-05 16:06:55 +03:00
|
|
|
sql.Register("sqlite3", &SQLiteDriver{})
|
2018-02-01 07:24:37 +03:00
|
|
|
}
|
|
|
|
|
|
Add mock versions of SQLiteDriver and SQLiteConn for +build !cgo (#819)
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.
2020-06-05 16:06:55 +03:00
|
|
|
type (
|
|
|
|
|
SQLiteDriver struct {
|
|
|
|
|
Extensions []string
|
|
|
|
|
ConnectHook func(*SQLiteConn) error
|
|
|
|
|
}
|
|
|
|
|
SQLiteConn struct{}
|
|
|
|
|
)
|
2018-02-01 07:24:37 +03:00
|
|
|
|
Add mock versions of SQLiteDriver and SQLiteConn for +build !cgo (#819)
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.
2020-06-05 16:06:55 +03:00
|
|
|
func (SQLiteDriver) Open(s string) (driver.Conn, error) { return nil, errorMsg }
|
2024-01-25 16:36:27 +03:00
|
|
|
func (c *SQLiteConn) RegisterAggregator(string, any, bool) error { return errorMsg }
|
Add mock versions of SQLiteDriver and SQLiteConn for +build !cgo (#819)
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.
2020-06-05 16:06:55 +03:00
|
|
|
func (c *SQLiteConn) RegisterAuthorizer(func(int, string, string, string) int) {}
|
|
|
|
|
func (c *SQLiteConn) RegisterCollation(string, func(string, string) int) error { return errorMsg }
|
|
|
|
|
func (c *SQLiteConn) RegisterCommitHook(func() int) {}
|
2024-01-25 16:36:27 +03:00
|
|
|
func (c *SQLiteConn) RegisterFunc(string, any, bool) error { return errorMsg }
|
Add mock versions of SQLiteDriver and SQLiteConn for +build !cgo (#819)
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.
2020-06-05 16:06:55 +03:00
|
|
|
func (c *SQLiteConn) RegisterRollbackHook(func()) {}
|
|
|
|
|
func (c *SQLiteConn) RegisterUpdateHook(func(int, string, string, int64)) {}
|