This is mostly for when you are working with tables not created by Perfect-CRUD. Tables created with Perfect-CRUD are not affected by this pull request.
The scenario I am talking about is if another application created a database which, say, looked like this:
CREATE TABLE Example(
id TINYINT PRIMARY KEY
);
and you had a Swift class that looked like this:
struct Example {
let id: Int
}
Previously, this would error upon reading from the table as Perfect-MySQL required you to declare id as Int8. I have relaxed the restriction so that Int can be used on integer width used by the database. If you want stricter enforcement, you can still use the fixed-width Int8-Int64 types.
Why do this? There are many reasons:
Interoperability
Swift is strict about types - different width integers do not implicitly convert between each other. As such it is common practice to always use Int regardless of the width required in order to increase interoperability between code, so that you don't need type conversions everywhere when interacting with the standard library or some framework.
Unless you need to work with a specific size of integer, always use Int for integer values in your code. This aids code consistency and interoperability.
The change also means it is more likely to be compatible with existing data models without having to modify them.
Int is variable
Int is not exactly what you would describe as a "fixed-width integer". The width varies between platforms depending on the native word size.
Therefore enforcing it to match a database integer width (which is likely fixed-width) makes little sense.
Int can be 32-bit or 64-bit depending on the platform. There already had to be changes (#43) to support this. We might as well go further than something inbetween and make it cover all widths.
There's many more reasons I can go into if you want to discuss it further.
In summary:
Int has been relaxed to now cover all supported integer widths.
Fixed-with integers (Int8-Int64) remain untouched and are restricted to match the database field's integer width as before.
A test case is supplied.
Next Steps?
Add this to MariaDB
This is done (it's a straight-up copy-paste job) but I've not submitted it until I hear the outcome of this pull request.
Support interoperability between UInt and Int?
Another piece of guidance given by Swift is to prefer Int over UInt, so it is perhaps a good idea to allow conversions from UInt8-UInt64 to Int.
This is mostly for when you are working with tables not created by Perfect-CRUD. Tables created with Perfect-CRUD are not affected by this pull request.
The scenario I am talking about is if another application created a database which, say, looked like this:
and you had a Swift class that looked like this:
Previously, this would error upon reading from the table as Perfect-MySQL required you to declare
id
as Int8. I have relaxed the restriction so that Int can be used on integer width used by the database. If you want stricter enforcement, you can still use the fixed-width Int8-Int64 types.Why do this? There are many reasons:
There's many more reasons I can go into if you want to discuss it further.
In summary:
A test case is supplied.
Next Steps?
Int
overUInt
, so it is perhaps a good idea to allow conversions from UInt8-UInt64 to Int.