Amber: Granite template creates wrong float type

[ZeroPointEnergy]

Description

When generating a model with amber all fields created with the type float are templated as Float32. However, if we do a find on the model we get a Float64 back.

Steps to Reproduce

$ amber new testapp
$ cd testapp
$ shards install
$ amber g model Something foo:float
$ amber db create migrate
$ amber exec 'Something.create(foo: 1.0)'
$ amber exec 'Something.find_by(foo: 1.0)'

Expected behavior: [What you expect to happen]

Lookup of the row succeeds.

Actual behavior: [What actually happens]

12:47:40 Granite    | (INFO) SELECT "somethings"."id", "somethings"."foo", "somethings"."created_at", "somethings"."updated_at" FROM "somethings" WHERE "somethings"."foo" = $1 LIMIT 1: [1.0]
Unhandled exception: PG::ResultSet#read returned a Float64. A (Float32 | Nil) was expected. (Exception)
  from lib/db/src/db/result_set.cr:0:9 in 'read'
  from src/models/something.cr:1:1 in 'set_attributes'
  from src/models/something.cr:1:1 in 'from_sql'
  from lib/granite/src/granite/querying.cr:38:17 in 'raw_all'
  from lib/granite/src/granite/querying.cr:53:30 in '->'
  from lib/granite/src/granite/collection.cr:255:3 in 'collection'
  from lib/granite/src/granite/collection.cr:6:5 in 'Granite::Collection(Something)'
  from lib/granite/src/granite/querying.cr:58:5 in 'first'
  from lib/granite/src/granite/querying.cr:77:5 in 'find_by:foo'
  from tmp/1531392458529_console.cr:2:3 in '__crystal_main'
  from /usr/lib64/crystal/crystal/main.cr:104:5 in 'main_user_code'
  from /usr/lib64/crystal/crystal/main.cr:93:7 in 'main'
  from /usr/lib64/crystal/crystal/main.cr:133:3 in 'main'
  from __libc_start_main
  from _start
  from ???
result = (
  Something.find_by(foo: 1.0)
)
puts result.inspect

Reproduces how often:

Alwais

Versions

Amber CLI (amberframework.org) - v0.8.0

Crystal 0.25.0 (2018-06-25)

LLVM: 6.0.0
Default target: x86_64-pc-linux-gnu

[Obversity]

I've just experienced this as well. Anyone know if there's an immediate in-project fix, or a bugfix on its way?

[drujensen]

@Obversity Did you try changing field my_float : Float64?

[Obversity]

@drujensen I didn't actually! I realised the data would be equally well stored as an integer so I changed it. If I have need of a float again I'll give that a shot, thanks!

[drujensen]

@Obversity ok, it looks like the MySql driver returns a Float32 where the Pg driver returns Float64. I updated the templates to address this. Thanks for reporting this.