New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

INTEGER PRIMARY KEY in SQLite #852

Closed
lnicola opened this Issue Apr 8, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@lnicola

lnicola commented Apr 8, 2017

Diesel deduces the a column's type as BigInt if it's declared as BIGINT in the database. This is generally fine in SQLite because INTEGER and BIGINT are synonyms, but INTEGER PRIMARY KEY is treated differently and is always 64-bit according to https://sqlite.org/autoinc.html. Moreso, BIGINT PRIMARY KEY AUTOINCREMENT is not accepted.

It might be a good idea to detect these columns and use BigInt for them. Note that the SQLite documentation says that INTEGER PRIMARY KEY is special only for tables that aren't declared with WITHOUT ROWID, but BIGINT PRIMARY KEY is still not allowed even when using that.

@Eijebong

This comment has been minimized.

Member

Eijebong commented Jul 17, 2017

Is this really an issue ? I just tried and I was able to insert 2^256 in an integer field. SQLite does not really care about types. It would be confusing for users to deserialize what they think is an integer to an i64 though as I'm sure nobody knows about this bug. If you need to retrieve a I Bigint from SQLite, you can use the table macro and say it's a bigint

@lnicola

This comment has been minimized.

lnicola commented Jul 17, 2017

It's not an issue for SQLite, but diesel deduces the type as i32 IIRC.

If you need to retrieve a I Bigint from SQLite, you can use the table macro and say it's a bigint

Yeah, that works.

@sgrif

This comment has been minimized.

Member

sgrif commented Jul 17, 2017

I'm a bit torn on what to do here. It's really unfortunate that SQLite requires the type name to be exactly INTEGER in this case. As @Eijebong mentioned, our inference on SQLite is really more just trying to deduce intent, as types are just suggestions more than anything in SQLite. Ultimately I'd prefer not to special case this, as the use cases for SQLite trend towards not needing 64 bit PKs, and you can override manually in the cases where it matters. Ultimately though I think keeping our inference rules simple and consistent here takes priority.

@sgrif sgrif closed this Jul 17, 2017

@yipdw yipdw referenced this issue Jan 14, 2018

Open

Add SQLite backend #12

7 of 9 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment