mirror of
https://github.com/hanzoai/base.git
synced 2026-10-21 03:41:50 +00:00
zeekayandHanzo Dev
65fdb03b35
deploy / build (push) Waiting to run
core/sqlite_math_required.go failed any cgo build not carrying the
sqlite_math_functions tag, by referencing a symbol that was never defined
anywhere. So `go build ./...` — no tags, default CGO_ENABLED — did not
work in this repo or in any repo importing core, and the error named a
symbol rather than the problem:
undefined: cgoBuildNeedsSQLiteMathFunctions
The capability it was protecting is real. tools/search emits acos, cos,
sin and radians for geoDistance, and SQLite only has those when compiled
with SQLITE_ENABLE_MATH_FUNCTIONS. Measured, per config:
CGO_ENABLED=0 present (what the Dockerfile ships)
CGO_ENABLED=1 ABSENT <- the one deficient config
CGO_ENABLED=1 -tags sqlite_math_functions present
CGO_ENABLED=1 -tags libsqlite3 present <- blocked anyway
The tag was a proxy for the capability, and the proxy was wrong. Row four
is the config the driver's own doc comment calls production: that tag
links the system sqlcipher, so the amalgamation's -D flag is never
compiled and the tag decides nothing, yet the guard rejected the build.
It also could not have caught a system libsqlcipher genuinely missing the
functions, and no library can satisfy it from the inside, because build
tags are chosen by the top-level build command.
Replace it with a measurement. VerifySQLiteMathFunctions runs the
geoDistance expression once per process against a throwaway in-memory
database and DefaultDBConnect refuses to hand back a connection when the
answer is no, so a deficient binary dies at startup with the three ways
to fix it rather than at a customer's failed search. A probe that could
not run at all is not an error: this reports a measured absence, never a
failure to measure.
Detection is strictly better than before. tools/search already had
TestTokenFunctionsGeoDistanceExec executing the real emitted SQL, and it
fails on the deficient config today; core now carries its own, since
tools/search does not import core and its failure said nothing about
this package.
build, all four configs above exit 0 (was: 2 of 4 refused)
go test ./... CGO_ENABLED=0 64 packages ok, 0 failures
go test ./core -run SQLiteMath CGO=1 FAIL, as it should
Co-authored-by: Hanzo Dev <[email protected]>
35 lines
1.4 KiB
Go
35 lines
1.4 KiB
Go
//go:build !no_default_driver
|
|
|
|
package core
|
|
|
|
import (
|
|
"github.com/hanzoai/dbx"
|
|
"github.com/hanzoai/sqlite"
|
|
)
|
|
|
|
// DefaultDBConnect opens an embedded SQLite database on the canonical Hanzo
|
|
// driver (github.com/hanzoai/sqlite). That package registers the "sqlite"
|
|
// database/sql driver name under BOTH build configs — its pure-Go backend
|
|
// (!cgo) and its hanzoai/sqlcipher (cgo) backend — so exactly ONE package
|
|
// registers "sqlite" no matter how Base is linked (standalone !cgo, or embedded
|
|
// into a cgo binary such as commerce). Base MUST NOT import a low-level SQLite
|
|
// driver (modernc.org/sqlite or hanzoai/csqlite) directly, or a build
|
|
// double-registers "sqlite" and panics at init.
|
|
//
|
|
// sqlite.PragmaDSN encodes sqlite.DefaultPragmas (busy_timeout leads — a
|
|
// connection must block on a busy DB before journal_mode=WAL is set) in the
|
|
// ACTIVE backend's DSN syntax, so the pragmas apply on both backends; a
|
|
// single-form DSN would be silently dropped by the other backend.
|
|
//
|
|
// VerifySQLiteMathFunctions runs once per process and refuses a build whose
|
|
// linked SQLite cannot answer the search layer's geoDistance filter, so a
|
|
// deficient binary dies here rather than at a customer's failed search. See
|
|
// sqlite_math.go.
|
|
func DefaultDBConnect(dbPath string) (*dbx.DB, error) {
|
|
if err := VerifySQLiteMathFunctions(); err != nil {
|
|
return nil, err
|
|
}
|
|
|
|
return dbx.Open("sqlite", sqlite.PragmaDSN(dbPath, sqlite.DefaultPragmas))
|
|
}
|