volatiletech / sqlboiler-sqlite3

SQLBoiler v4 adds a go.mod file and requires use of v8.1.0 of github.com/volatiletech/null using the import path github.com/volatiletech/null/v8, but the sqlite3 driver in this repository still generates code using the old github.com/volatiletech/null import path.

sqlboiler-sqlite3/driver/sqlite3.go

Line 488 in 3300e96

col.BasedOnType = importers.Map{

This generates compile-time errors when trying to use the code generated by this driver in a code base that has upgraded to SQLBoiler v4 (and thus is using the github.com/volatiletech/null/v8 import path in code interacting with null types).

Based on the changes to the drivers in this commit:

volatiletech/sqlboiler@4df9241

a few import path changes may be required in the code for sqlboiler-sqlite3 as well, outside of those generate by the templates:

import (
        "github.com/volatiletech/sqlboiler/drivers"   // "github.com/volatiletech/sqlboiler/v4/drivers"
        "github.com/volatiletech/sqlboiler/importers" // "github.com/volatiletech/sqlboiler/v4/importers"
        "github.com/volatiletech/sqlboiler/randomize" // "github.com/volatiletech/randomize"
        "github.com/volatiletech/sqlboiler/strmangle" // "github.com/volatiletech/strmangle"
        "github.com/volatiletech/sqlboiler/types"     // "github.com/volatiletech/sqlboiler/v4/types"
)

For now, a workaround is to override the import paths by adding the following to the config file passed in as sqlboiler's --config argument:

[[types]]
  [types.match]
    type = "null.String"
    nullable = true

  [types.replace]
    type = "null.String"

  [types.imports]
    third_party = ['"github.com/volatiletech/null/v8"']

[[types]]
  [types.match]
    type = "null.Int64"
    nullable = true

  [types.replace]
    type = "null.Int64"

  [types.imports]
    third_party = ['"github.com/volatiletech/null/v8"']

You can repeat this pattern for any other types included in the null package.

Add support for SQLBoiler v4