DSL for migrations

[drujensen]

This adds a new DSL for migrations. It uses the same syntax as Rails migrations.

require "granite/migration"

class CreatePost < Granite::Migration
  connection :pg

  def up
    create_table :post do |t|
      t.primary :id
      t.reference :user_id
      t.string :title
      t.text :body
      t.boolean :published
      t.integer :age
      t.timestamp :published_at
      t.custom "json_field JSON"
      t.custom "uuid_field UUID"

      t.timestamps
    end

    rename_table :post, :posts

    create_index :posts, :user_id

    add_column :posts, :test, :string
    rename_column :posts, :test, :new_test
    remove_column :posts, :new_test

    execute <<-SQL
      ALTER TABLE posts ADD CONSTRAINT posts-user_id-fk FOREIGN KEY (user_id) REFERENCES users(id)
    SQL
  end

  def down
    drop_table :posts
    drop_index :posts, :user_id
  end
end

To execute:

require "granite/adapter/pg"

Granite::Connections << Granite::Adapter::Pg.new(name: "pg", url: "postgres://url")

create_post = CreatePost.new
puts create_post.generate_sql(:up)
puts create_post.generate_sql(:down)

[Blacksmoke16]

Given the result of #182, is this something we actually want to include?

If so, I think I would rather remove, or at least deprecate, the current internal migrator so we don't end up with just another way to do the same thing, as this would be the third way of doing migrations.

[drujensen]

@Blacksmoke16 Over the years, I have collected feedback on why developers prefer other ORM's over granite and the lack of a DSL for DDL rises to the top.

This is not a full featured DSL yet. There are several options that still need to be built into it. Also, there are some missing types yet to be added.

Currently this is a self contained class with little changes to existing code. I could see merging or having Migrator use Migration to avoid duplicate code.

Let me know your thoughts. I can close this if you think its not worth the effort.

[robacarp]

@drujensen I think this is a great start, and a good set of footsteps to follow in. Granite's dependence on Micrate has frustrated me many times and my experience with Rails has been that an abstracted DDL is helpful because the "Right Choices" can be made once in the abstraction layer and down the line nobody has to think about it.

Reading the current implementation leaves me with some thoughts:

• Support for multiple adapters is minimal. There's a steady stream of people asking for Postgres specific data types and I'd be surprised if that didn't happen here too. However the escape mechanism of "use the execute with raw sql" is helpful in the short term. I'm not sure what a good solution to that is -- the only thing that comes to mind is loading a different DSL class for a different adapter. With inheritance that might not be too bad.
• I don't see any support given for default values, and I think I'd consider this important enough to have before rolling it out.

[Blacksmoke16]

@drujensen Personally I'm fine with raw SQL migrations but if this is a commonly requested feature I don't have a problem with the addition. That is, assuming you/someone will be maintaining it.

[drujensen]

@Blacksmoke16 @robacarp thanks for spending the time looking at this.

@robacarp I agree about the default and there are 4 other options that rails supports. I will look at adding them.

Regarding the specific data types per db, I agree with this as well. I will look into refactoring out the Fields class to be a base class and inherit for each database. That makes more sense.

[eliasjpr]

I really like the dsl, how can we specify other column parameters, such as size, not null, index etc?

In the same format it can provide a t.constraint, t.unique, t.belongs_to etc

[drujensen]

Thinking about this more, this should be included in the micrate project instead of here. Closing this PR.