amberframework
Type checking during compilation against Model defined types
Consider the following model:
class Book < Granite::Base
connection pg
table books
column id : Int64, primary: true
column name : String
column author: String
column year: String
end
If I write Book.create(name: "Programming Crystal", author: "Ivo Balaera", year: 2017) we know that 2017 is an Int of some type (perhaps it's an Int64 in this case, however the Granite model requires you to pass a String. These types of errors could be caught as standard Crystal typing errors and generate a compilation error rather than encountering an issue at runtime. Thoughts?
Possibly? I have some ideas on how object initialization could work better now that we're in the annotation world, but need to test/figure some more stuff out. Ideally I think we would be able to get rid of set_attributes in favor of an overloaded initializer for the DB::ResultSet case, and possibly just have the user define their own, or define one for them, for the normal flow of like book = Book.new xxx. Both of these would help with this.
In regards to what you asked me on Gitter
could granite just convert the int into a string knowing the datatype is varchar
IMO, Granite should not do any type conversions and this would fail since you're providing an Int32 and it's expecting a String. Although we are currently doing some implicit conversions (which I'm not a big fan of) here, because it was breaking how Amber works apparently. See #356 and #357.
Having it call #to_s on the value you pass if the type is set to String is doable, but I'd rather not do it (unless everyone decides its a good idea).
