Sexier migrations

[amatsuda]

Let me propose a new Rails-3-ish cooler syntax for the database migrations.
This pull request enables you to remove the block parameter and t. t. t. t. t. t. t. ... from your migration code.

This is actually the same thing with what I posted here in January, so please refer to this ticket for details.
https://rails.lighthouseapp.com/projects/8994/tickets/6339

The reasons why I made another pull request today are:

• The attached patch on the ticket does not apply anymore to the current master
• The proposal got many +1s from people
• The ticket is in "wontfix" state (by mistake?), and maybe because of that, was not copied to GH issues
• I think 3.1 is the best timing for including another change on the migration syntax
• I guess @tenderlove have not looked at it yet

So, @tenderlove, can you please take a look at the former ticket and this pull request, then give me your thoughts?
Thanks in advance!

[fxn]

If this pull request is applied I think this idiom should become the recommended one, and thus all example code in documentation would need to be updated to reflect that. Only the API docs of create_table would mention the block may receive a argument.

[amatsuda]

Yes, agree. And of course I'm willing to work on that when I'm sure the syntax will be accepted.
I mean, I just wanted to know first whether you like it or not, before updating the whole documentation.

[asanghi]

+1, looks sweet. Lets do this if we can.
We've got instance evals in routes already as a pre-cursor.
Migrations aren't run very frequently so there would be negligible net performance impact.
We're already updating the migration syntax in Rails 3.1 so why not go a step further.
It's backward compatible as far as i can see.

[joeljunstrom]

+1 for simplified api, definitely have a more "Rails 3 feel"

[Fonsan]

asanghi what he says +1

[jonleighton]

I also give this a 👍, but it is too late for it to go into 3.1 so we should return to this once 3.1 is out the door.

[josevalim]

I am in general -1 for instance eval. instance eval has its set of gotchas that does not make it worth imo.

[tenderlove]

I'm OK with this change, but I want to see what methods we would expose by doing instance_eval before I full agree with this change. Doing the instance eval will allow private methods to be exposed on the table_definition object, and that kind of worries me.

In any case, I agree with @jonleighton that this should be considered for 3.2. I wish somebody would branch for 3.1 so we can start merging in 3.2 features. :-P

[myronmarston]

Given the instance_eval gotchas that @josevalim mentioned, and the fact that there are tons of migrations out in the wild with the old syntax, I think both ways should be supported. That way, old migrations do not break, and people who prefer the non-instance_eval syntax and still choose to avoid it. Here's a simple way to accomplish that:

if blk.arity == 1
  blk.call(td)
else
  td.instance_eval(&blk)
end

[plentz]

+1

[asanghi]

We ❤️ this already. The only stuff that really would later are a few blog posts as far as dissemination of information is concerned. Why wait til 3.2 to introduce yet more changes in migrations. If we're going to have this might as well make the changes now, still not too late. 👍 on @myronmarston's changes.

[spastorino]

3.1 is feature complete. I have the same concern that @tenderlove has, it could be nice to see what are we going to expose to the table_definition objects.

[radar]

-1, I'd prefer we weren't adding extra code for the sake of making this two characters shorter per line

[dasch]

+1, this seems in line with the direction Rails has taken, e.g. in the routing DSL.

[TheEmpty]

@radar please compare the time that it takes for a machine to interpret these lines, what three or four lines, and the time for a human to write those two characters. You'll find that this is +1

+1 :)

[elomarns]

+1.

Cleaner interfaces is always best.

[jeremy]

This is a good candidate for 3.2, let's merge to master and update documentation.

[jeremy]

This is green for 3.2, we just need docs/guides updates.

[soulnafein]

+1
There isn't really much extra code, and the migrations look nicer.

[vijaydev]

FTR this doesn't have documentation. @tenderlove what about this suggestion?#1163 (comment)

[tenderlove]

@vijaydev the suggestion seems good. Can you put together a pull request with tests? Thanks!