-
-
Notifications
You must be signed in to change notification settings - Fork 40
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
Determine SQLite type by following affinity rule #102
Comments
Hey @RipleyTom, thanks for the questions! From what I understand SQLite does not support unsigned integer. It will be treated as a normal integer column in SQLite. |
I'm aware of this, every integer type in sqlite is really an INTEGER behind the hood(note that it's still a valid type in sqlite) but that still doesn't explained how a UNSIGNED SMALLINT(ie an INTEGER really) ended up as Vec<u8> in codegen(at worst it should be an i32). |
It end up being
|
Hmm I'm even more confused now, why is there an UnsignedBigInt, Int2, Int8, etc types in there? |
All these types are on the list because they are mentioned on the page https://www.sqlite.org/datatype3.html#affinity_name_examples. |
I don't think there is a good way to parse arbitrary types, e.g. |
Yeah but like the table says, those are examples: |
Okay, I agree we can update the logic and search if |
Summary: right now the database to type mapping is word-by-word. |
I'm currently in the process of migrating a program from sqlite to sea-orm and used sea-orm-codegen to generate the entities from the existing database.
It seems it converted an
UNSIGNED SMALLINT NOT NULL
to aVec<u8>
The database table used to be created like this:
resulting users.rs:
I'd expect
pub flags: u16
The text was updated successfully, but these errors were encountered: