Do you have plan to support sqlite3?

[jacobzeng]

Thank you first for the repo.
Do you have plan to support sqlite3?

[glebarez]

it is indeed sqlite3. What do you mean?

[misterunix]

@jacobzeng you can use this repo just like you would use "github.com/mattn/go-sqlite3". I have had very good results using this repo.

[jacobzeng]

I can't open DB with sql.Open("sqlite3","data.db") ,maybe I did something wrong?

[jacobzeng]

@jacobzeng you can use this repo just like you would use "github.com/mattn/go-sqlite3". I have had very good results using this repo.

Thanks for your tip, but I think mattn/go-sqlite3 need CGO, right? I hate that ^^

[glebarez]

I can't open DB with sql.Open("sqlite3","data.db") ,maybe I did something wrong?

use

sql.Open("sqlite","data.db")

[misterunix]

Correct mattn needs cgo, thats why I use this repo.

[benstigsen]

This issue could probably be closed, but I'm asking in here at the same time.
Why does this module depend on the sqlite3 mattn module?

[glebarez]

This issue could probably be closed, but I'm asking in here at the same time. Why does this module depend on the sqlite3 mattn module?

This repo does not depend on sqlite3 mattn module (see go.mod).
But underlying sqlite lib has it in its go.mod (but still does not use it in code, only for tests)
see https://gitlab.com/cznic/sqlite/-/issues/69

[benstigsen]

Ah okay.

[costela]

sql.Open("sqlite","data.db")

The problem with that suggestion is that there are loads of code out there (e.g. ent) that check against the well-known "sqlite3" string to choose SQL dialects.

I see at least a couple of alternatives to deal with this and keep backward-compatibility:

• add a "compat" subpackage that just does sql.Register("sqlite3", newDriver()) (has the down-side of "acknowledging" the de-facto standard name of "sqlite3")
• add a way to get the globally initialized Driver, so that the consumer can re-register it under a different name (more flexible but less idiomatic)
• add something like RegisterAs(string) global function to re-register the Driver (also not idiomatic; probably confusing)

[glebarez]

sql.Open("sqlite","data.db")

The problem with that suggestion is that there are loads of code out there (e.g. ent) that check against the well-known "sqlite3" string to chose SQL dialects.

I see at least a couple of alternatives to deal with this and keep backward-compatibility:

• add a "compat" subpackage that just does sql.Register("sqlite3", newDriver()) (has the down-side of "acknowledging" the de-facto standard name of "sqlite3")

• add a way to get the globally initialized Driver, so that the consumer can re-register it under a different name (more flexible but less idiomatic)

• add something like RegisterAs(string) global function to re-register the Driver (also not idiomatic; probably confusing)

I really like option 1 of your suggestion, since it will be a simple import of such compat package, without additional calls.
Sounds like good drop-in fix.