Forum: Rails-core (closed, excessive spam) add change_table block to migrations?

C84807bb5457755ec17ba32ff713a9b2?d=identicon&s=25 zilkey (Guest)
on 2008-04-29 17:53
(Received via mailing list)
[for those of you who already got a pull request about the
change_table block I apologize for the double post - I'm still
figuring out github / mailing list etiquette]

I just created a fork of rails in which I added the ability to define
change_table blocks like so:

    change_table :videos do |t|
      t.add_belongs_to :goat
      t.add_string :name, :email, :limit => 20
      t.remove_column :name, :email # => takes an array
      t.string :some_string # => executes against the renamed table

The change involved lots of docs and a 1:2.6 code:test ratio so it
looks like a lot of code, but at the heart of it it's about 90 lines
of methods that wrap standard migration actions but pass the table
name in.  It's almost purely a syntax update - the only real change is
that remove_column now takes an array.

The need it fills

This is a very blue-collar developer kind of fork.  It's or people
that work with lots of small projects, who work with legacy databases
or databases that are being denormalized, who integrate other apps
like Beast often etc...  It also adds some sugar for people who are
developing plugin apps that would benefit from having migrations that
don't always create tables.

Basically I find myself writing change statements more often than
writing create blocks, and this dries all of that up.

Strong points

It's well tested and documented and for the most part very consistent
with other migration syntax - with one naming issue which I'll mention
below.  It's analogous to the form helpers where they stand alone with
a type, or can be built as part of a block.

As far as naming goes it mimics both the create_table and the change

* t.column => t.add_column
* t.timestamps =>  t.add_timestamps
* t.string => t.add_string

If the method ended in _table, I took off _table, so there are also
these 2 methods:

* t.rename
* t.drop

stephencelis brought up to me the fact that "rename" could be a bit
confusing at first, since it's no longer unambiguous - so the three
options seem to be.  I've got 2 apps going now where I create a table,
dump a bunch of data into it from various sources and then drop it,
all in the up method, and I've used "drop" in a block in a real app,
which is why I included it.

Would anyone else find these shortcuts helpful?  That is, would you
pull it into your git repo, or install it as a gem?

I sent out a pull request to the people who were watching the github
rails repo, but from the response I gather that pull requests are not
the way to go, so as a second question - how should I go about
submitting patches now?  Are people still doing the +1 on tickets?

Sorry again for those of you who are getting this for the second time.

Jeff Dean
8f93a872e399bc1353cc8d4e791d5401?d=identicon&s=25 Mislav MarohniÄ? (mislav)
on 2008-04-29 18:43
(Received via mailing list)
Don't send pull requests to "rails" user, it's a black hole.

I like change_table. But I don't like t.rename/t.drop.
I would rather stick with rename_table/drop_table.

Also, does change_table support adding column with sexy migrations

  change_table :videos do |t|
    t.string :foo, :bar

Because create_table does, change_table should too.
C84807bb5457755ec17ba32ff713a9b2?d=identicon&s=25 zilkey (Guest)
on 2008-04-30 04:29
(Received via mailing list)
Yes - 100% of the migrations methods, including all of the sexy
migration syntax is included, including the lesser known belongs_to/
references, timestamps etc...

Although it's inconsistent with the existing API, I suppose something
like t.rename_table_to :new_name would be the nicest to look at, but I
could also just leave them out entirely.  It would be confusing to
have rename_table take a single argument in some places, and 2 in

Thanks for the feedback.

On Apr 29, 12:41 pm, "Mislav Marohniæ" <>
This topic is locked and can not be replied to.