Fixes to Migrator provided by Maiha

[drujensen]

Dry up codes about creating tables in specs, and put it production code as Granite::ORM.migrator.
This helps users

• to add tables in specs easily
• to create tables in experiment and deployment

class User < Granite::ORM::Base
  adapter mysql
  field name : String
end

User.migrator.create

mysql> describe users;
+-------+--------------+------+-----+---------+----------------+
| Field | Type         | Null | Key | Default | Extra          |
+-------+--------------+------+-----+---------+----------------+
| id    | bigint(20)   | NO   | PRI | NULL    | auto_increment |
| name  | varchar(255) | YES  |     | NULL    |                |
+-------+--------------+------+-----+---------+----------------+

implementation

• mapping rules from crystal class to database type is defined in adapters.
  • Granite::Adapter::Base::Schema::Types
  • Granite::Adapter::Mysql::Schema::Types
  • ...

I just defined rules about basic classes used in current specs.

• Bool, Float32, Float64, Int32, Int64, String, Time

If migrator is exected with undefined types, it raises a runtime error as below.

Migrator(Granite::Adapter::Mysql) doesn't support 'Time::Span' yet. (Exception)

Best regards,

[drujensen]

This PR was approved earlier but after several changes to master, the data structure changed for CONTENT_TYPE.

[faustinoaq]

Interesting, @drujensen would be possible to use this for amber db migrate ?

I still have some issues trying to fix amberframework/micrate#31 😅

WDYT?

[drujensen]

No. This doesn't handle migrations. For example, if you rename a field, you would need to migrate the data from one field to the other. micrate is better suited for this type of task.