[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_timestamps
t.add_belongs_to :goat
t.add_string :name, :email, :limit => 20
t.remove_column :name, :email # => takes an array
t.rename
t.string :some_string # => executes against the renamed table
end
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
methods:
* 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
http://github.com/zilkey/rails/commit/674e950c820f6171288f12cf8ba59b5d3eb698f0
http://github.com/zilkey/rails/wikis
http://ar.zilkey.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
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 syntax?
change_table :videos do |t|
t.string :foo, :bar
end
Because create_table does, change_table should too.
On Tue, Apr 29, 2008 at 5:52 PM, zilkey <jeff@zilkey.com> wrote:
>
> [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_timestamps
> t.add_belongs_to :goat
> t.add_string :name, :email, :limit => 20
> t.remove_column :name, :email # => takes an array
> t.rename
> t.string :some_string # => executes against the renamed table
> end
>
> 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
> methods:
>
> * 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
>
>
>
http://github.com/zilkey/rails/commit/674e950c820f6171288f12cf8ba59b5d3eb698f0
> http://github.com/zilkey/rails/wikis
> http://ar.zilkey.com/
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
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 another. Thanks for the feedback. On Apr 29, 12:41 pm, "Mislav Marohnić" <mislav.maroh...@gmail.com> wrote:> 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 syntax? > > change_table :videos do |t| > t.string :foo, :bar > end > > Because create_table does, change_table should too. > > On Tue, Apr 29, 2008 at 5:52 PM, zilkey <j...@zilkey.com> wrote: > > > [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_timestamps > > t.add_belongs_to :goat > > t.add_string :name, :email, :limit => 20 > > t.remove_column :name, :email # => takes an array > > t.rename > > t.string :some_string # => executes against the renamed table > > end > > > 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 > > methods: > > > * 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 > > >http://github.com/zilkey/rails/commit/674e950c820f6171288f12cf8ba59b5... > >http://github.com/zilkey/rails/wikis > >http://ar.zilkey.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---