What's New in Edge Rails: Bringin' Sexy Back

Posted by ryan
at 5:36 PM on Sunday, May 06, 2007

You know those sexy migrations you’ve been lusting over? Yeah, well they’re mainstream now. I won’t unnecessarily duplicate here what’s already been written about them – but the gist is that a sexy migrations inspired syntax is now part of Rails.

You can now do:

1
2
3
4
5
create_table "users", :force => true do |t| 
  t.integer :group_id, :employer_id
  t.string :first, :last
  t.timestamps
end

To get integer columns in group_id and employer_id and string columns in first and last. timestamps gets you the magic columns created_at and updated_at.

The list of supported column types are:

  • string
  • text
  • integer
  • float
  • decimal
  • datetime
  • timestamp
  • time
  • date
  • binary
  • boolean

So spin that Barry White record and lay it down right, sexy’s back.

tags: ruby, rubyonrails

Comments

Leave a response

  1. Stephen TousetMay 07, 2007 @ 01:21 AM

    I hope they’ve managed to fix the problem I had in sexy_migrations with the float datatype on PostgreSQL. I filed a bug last night on Lighthouse. :)

  2. Stephen TousetMay 07, 2007 @ 01:37 AM

    Hmm, seems they don’t have all the features of err’s plugin. Namely, foreign_key and inheritable! don’t work. Bleh.

  3. RyanMay 07, 2007 @ 07:50 AM

    Stephen – yeah, it’s not a direct port of the plugin. It’s only a “sexy migrations inspired syntax”.

  4. Stephen TousetMay 07, 2007 @ 09:00 AM

    Like how some movies are inspired by a true story? I’m honestly confused why they decided to mess with a good thing. The plugin by Err was nice, clean, got rid of the forced repetition of the “t” object within the block, and had extra features in the form of foreign_key, timestamps with a few useful aliases, and helpers for polymorphic/inheritable classes.

    I can understand why DHH wouldn’t have included the :ref => true parameter for foreign_key, since he’s quite opinionated about the software enforcing database constraints (still not entirely with him on that one, but reasonable people can disagree on that point), but the others seem quite useful. I don’t quite see the point of leaving them out and not just porting the whole thing over as is.

    NIH, maybe?

  5. DHHMay 07, 2007 @ 11:10 AM

    I’m not a fan of using instance_eval for these types of interfaces. It quickly becomes unclear how regular method calls will work and what they’ll do when the magic ones are not scoped. You’ll see the same deal in routes.rb, which also COULD have been done without map., but we choose not to.

    Further more, I didn’t like inheritable! as it didn’t really save any keystrokes and just made it less obvious what was really going on. We did take timestamps over, though, since that actually saved something and the same was easier to indicate what was going on.

    Patches are changed all the time to fit the rest of Rails better. It has nothing to do with NIH, but with maintaining the overall design integrity of the framework.

  6. Oleg AndreevMay 07, 2007 @ 11:45 AM

    I hate type declaration appear before actual name goes. That’s what i’d like to see in core instead:

    create_table “users”, :force => true do |t| t.group_id :integer t.employer_id :integer t.first :string t.last :string t.timestamps end

  7. Stephen TousetMay 08, 2007 @ 03:09 PM

    Thanks for the reply, DHH. Fair enough, about the use of instance_eval. I still would have liked some better aliasing of timestamps similar to the original plugin, plus extra sugar like inheritable!. It might not really save all that much typing, but it does make it a little clearer what’s going on.

  8. topfunkyMay 30, 2007 @ 06:29 PM

    I’m just glad to know that my suggestion of implementing inheritable! was sexy enough for Err, who implemented it in a matter of minutes.

    The fact that it wasn’t sexy enough for DHH is understandable.

    The Rails plugin framework leaves plenty of room for Dr. Nic, Wanstrath/Hyett, and the rest of us to continue to be magically sexy in our own apps.