If you create a field in a table like this
public uint Hash2 { get; set; }
In mysql you get a int(11) - which is a signed number
if you do this:
[CustomField(“INT UNSIGNED”)]
public uint Hash { get; set; }
you get a int(10) UNSIGNED
If you create a field in a table like this
public uint Hash2 { get; set; }
In mysql you get a int(11) - which is a signed number
if you do this:
[CustomField(“INT UNSIGNED”)]
public uint Hash { get; set; }
you get a int(10) UNSIGNED
Most RDBMS’s don’t have unsigned integers, so we just avoid using them all together.
I’ve ran into this issue as well. We’re looking at migrating a large project into Ormlite where unsigned integers are utilized frequently. Is there a way to mitigate the issue without adding the CustomField-attribute to every unsigned int in the code base? We’re using MySQL.
The CustomField only impacts creating the Table Schema, if you have an existing table you won’t need to create the Schema, so it’s not needed.
Otherwise you can register a Type Converter to override MySql’s existing uint type converters.
That worked like a charm, thank you!