Type checking during compilation against Model defined types

[elaine-jackson]

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?

[Blacksmoke16]

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).