Primary key on dependent side of relationship is BIGINT even if declared as Int32

[ghost]

Minimal test case:

Granite::Connections << Granite::Adapter::Pg.new(name: "db", url: "postgres://test@localhost/test")
require "granite/adapter/pg"

class Comment < Granite::Base
  connection db
  column id : Int32, primary: true
  column user_id : Int32
  belongs_to :user, primary_key: "user_id"
end

Comment.migrator.drop_and_create

The user_id column is created as BIGINT even though it's explicitly declared as Int32. With no belongs_to line, user_id is created as INT. (It's also not being given its NOT NULL either way.)

[Blacksmoke16]

I don't think there is anything to be done here. The current migrator implementation is more so used internally for testing. It would be worth testing this against #413; which is intended to be a more user facing migration feature.

The reasoning why it gets created as BIGINT is belongs_to macro basically redefines the user_id column as the foreign key, which defaults to Int64. If anything you should probably do belongs_to :user, foreign_key: user_id : Int32.

[ghost]

I see. Thanks for suggesting the alternate notation. foreign_key: user_id : Int32 created it as INT but still no NOT NULL.

I had looked at Micrate earlier but didn't go with it because it doesn't solve the only thing I was really looking for in it, which is a way around the need to define the schema in two places (in Crystal for ORM use and in SQL for setting up the DB). When I found out about Granite::Base.migrator, I got hopeful that it would provide that. I'm concerned about the DSL in #413 replacing this, since that DSL doesn't look like it offers this.