You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
darwin/amd64
What did you do?
Generate code with XO for a productive Sqlite3 database.
An integer Primary Key column which is implicitly, but not explicitly declared as "not null", causes invalid code.
CREATE TABLE revinfo (
rev INTEGER primary key
);
XO generates this revinfo.xo.go which does not compile:
// Revinfo represents a row from 'revinfo'.
type Revinfo struct {
Rev sql.NullInt64 `json:"rev"` // rev
// xo fields
_exists, _deleted bool
}
// ...
// Insert inserts the Revinfo to the database.
func (r *Revinfo) Insert(db XODB) error {
var err error
// if already exist, bail
if r._exists {
return errors.New("insert failed: already exists")
}
// sql insert query, primary key provided by autoincrement
const sqlstr = `INSERT INTO revinfo (` +
`` +
`) VALUES (` +
`` +
`)`
// run query
XOLog(sqlstr)
res, err := db.Exec(sqlstr)
if err != nil {
return err
}
// retrieve id
id, err := res.LastInsertId()
if err != nil {
return err
}
// set primary key and existence
r.Rev = sql.NullInt64(id) // <<<<< Compile Error because invalid conversion
r._exists = true
return nil
}
Analogously, all Foreign Key references to the "rev" column generate the same invalid conversion in their files.
Note 1: Such "revinfo" tables are generated by Hibernate Envers.
Note 2: There is a historical bug in SQlite so that Primary Keys indeed can be Nullable, which does not conform to the SQL standard.
I'd find it acceptable that XO creates invalid code where SQlite allows invalid DDL :-)
But this does not apply here. The "rev" column is of type "integer" and in this special case, SQlite conforms to the SQL standard and implicitly defines the Primary Key as "Not Null".
Suggestion: XO could implicitly assume Primary Keys to be "Not Null". This should fit the SQL standard.
personal limitation#1 I'm aware that implicit behaviour needs to fit in any case, and I expect to miss some implications.
personal limitation#2 I'm unsure whom to blame. Eventually, the SQlite driver should already report the Primary Key as "Not Null".
The text was updated successfully, but these errors were encountered:
This doesn't seem related to any feature of the Go programming language. I think you probably want to close this and open an issue in https://github.com/xo/xo (I'm assuming this is the package that you're referring to here).
What version of Go are you using (
go version
)?go 1.9
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?darwin/amd64
What did you do?
Generate code with XO for a productive Sqlite3 database.
An integer Primary Key column which is implicitly, but not explicitly declared as "not null", causes invalid code.
XO generates this revinfo.xo.go which does not compile:
Analogously, all Foreign Key references to the "rev" column generate the same invalid conversion in their files.
Note 1: Such "revinfo" tables are generated by Hibernate Envers.
Note 2: There is a historical bug in SQlite so that Primary Keys indeed can be Nullable, which does not conform to the SQL standard.
I'd find it acceptable that XO creates invalid code where SQlite allows invalid DDL :-)
But this does not apply here. The "rev" column is of type "integer" and in this special case, SQlite conforms to the SQL standard and implicitly defines the Primary Key as "Not Null".
Suggestion: XO could implicitly assume Primary Keys to be "Not Null". This should fit the SQL standard.
personal limitation#1 I'm aware that implicit behaviour needs to fit in any case, and I expect to miss some implications.
personal limitation#2 I'm unsure whom to blame. Eventually, the SQlite driver should already report the Primary Key as "Not Null".
The text was updated successfully, but these errors were encountered: