Rails - Jul 2005 - Rails 0.13: 225+ features/fixes in 75 days!

Rumors of our inability to release ever again was surely false. It has
happened. A new Rails release for the first time in so long that I had
to view the source of my release.rb script again to remember its
parameters.

But boy was it worth the wait. We got so much new stuff in here it''s
not even funny. And the massive influx of new users over the past few
months has meant a flood of fixes for every edge case on the planet.
We''re reaching rapid Maturity on the Scalability with Enterprise
goodness scale. Really.

So the big words for this release is Ajax, Migrations, Ajax,
Performance, Ajax,  Named Routes, and oh, yeah, we got some sweet Ajax
in there, too.

It''s all backwards compatible too. Upgrading will undoubtful force you
to increase the sex-appeal of both your application and your code. Be
warned!

We got a slightly longer detail on the whole affair up at the Rails weblog:
http://weblog.rubyonrails.com/archives/2005/07/06/rails-013-225-featuresfixes-in-75-days/

This of course also means that we''re expecting. Yup, that little new
one-oh is now slated for laser sharp attention. Just in time for the
Rails show they call OSCON. (Yes, delusions of grandeur has been tuned
by 37% with this release.)

Enjoy.
-- 
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

David Heinemeier Hansson <david.heinemeier@...> writes:
> 
> Rumors of our inability to release ever again was surely false. It has
> happened. A new Rails release for the first time in so long that I had
> to view the source of my release.rb script again to remember its
> parameters.

This is the start of my step into a larger world.  I''m serious.

Thanks for all the hard work to everyone involved. I know some of  
these changes are already valuable to me.

On Jul 6, 2005, at 3:25 PM, David Heinemeier Hansson wrote:
> Rumors of our inability to release ever again was surely false. It has
> happened. A new Rails release for the first time in so long that I had
> to view the source of my release.rb script again to remember its
> parameters.
>
> But boy was it worth the wait. We got so much new stuff in here
it''s
> not even funny. And the massive influx of new users over the past few
> months has meant a flood of fixes for every edge case on the planet.
> We''re reaching rapid Maturity on the Scalability with Enterprise
> goodness scale. Really.
>
> So the big words for this release is Ajax, Migrations, Ajax,
> Performance, Ajax,  Named Routes, and oh, yeah, we got some sweet Ajax
> in there, too.
>
> It''s all backwards compatible too. Upgrading will undoubtful force
you
> to increase the sex-appeal of both your application and your code. Be
> warned!
>
> We got a slightly longer detail on the whole affair up at the Rails  
> weblog:
> http://weblog.rubyonrails.com/archives/2005/07/06/rails-013-225- 
> featuresfixes-in-75-days/
>
> This of course also means that we''re expecting. Yup, that little
new
> one-oh is now slated for laser sharp attention. Just in time for the
> Rails show they call OSCON. (Yes, delusions of grandeur has been tuned
> by 37% with this release.)
>
> Enjoy.
> -- 
> David Heinemeier Hansson
> http://www.loudthinking.com -- Broadcasting Brain
> http://www.basecamphq.com   -- Online project management
> http://www.backpackit.com   -- Personal information manager
> http://www.rubyonrails.com  -- Web-application framework
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
Joseph Hosteny
jhosteny-ee4meeAH724@public.gmane.org
H: 412.362.8672
C: 412.418.6023

> So the big words for this release is Ajax, Migrations, Ajax,
> Performance, Ajax,  Named Routes, and oh, yeah, we got some sweet Ajax
> in there, too.
Congratulations to everybody involved in this release, especially
people whose first patch has just been released.

-- 
Cheers

Koz

In the words of my colleague napolen:

flippin awesome!

Now go back and get that 1.0 out! :)

thanks alot guys!

On 7/6/05, Michael Koziarski
<koziarski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > So the big words for this release is Ajax, Migrations, Ajax,
> > Performance, Ajax,  Named Routes, and oh, yeah, we got some sweet Ajax
> > in there, too.
> 
> Congratulations to everybody involved in this release, especially
> people whose first patch has just been released.
> 
> --
> Cheers
> 
> Koz
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Congrats guys!

Kent.

On 7/6/05, David Heinemeier Hansson
<david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Rumors of our inability to release ever again was surely false. It has
> happened. A new Rails release for the first time in so long that I had
> to view the source of my release.rb script again to remember its
> parameters.
> 
> But boy was it worth the wait. We got so much new stuff in here
it''s
> not even funny. And the massive influx of new users over the past few
> months has meant a flood of fixes for every edge case on the planet.
> We''re reaching rapid Maturity on the Scalability with Enterprise
> goodness scale. Really.
> 
> So the big words for this release is Ajax, Migrations, Ajax,
> Performance, Ajax,  Named Routes, and oh, yeah, we got some sweet Ajax
> in there, too.
> 
> It''s all backwards compatible too. Upgrading will undoubtful force
you
> to increase the sex-appeal of both your application and your code. Be
> warned!
> 
> We got a slightly longer detail on the whole affair up at the Rails weblog:
>
http://weblog.rubyonrails.com/archives/2005/07/06/rails-013-225-featuresfixes-in-75-days/
> 
> This of course also means that we''re expecting. Yup, that little
new
> one-oh is now slated for laser sharp attention. Just in time for the
> Rails show they call OSCON. (Yes, delusions of grandeur has been tuned
> by 37% with this release.)
> 
> Enjoy.
> --
> David Heinemeier Hansson
> http://www.loudthinking.com -- Broadcasting Brain
> http://www.basecamphq.com   -- Online project management
> http://www.backpackit.com   -- Personal information manager
> http://www.rubyonrails.com  -- Web-application framework
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

David Heinemeier Hansson
<david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> So the big words for this release is Ajax, Migrations, Ajax,
> Performance, Ajax,  Named Routes, and oh, yeah, we got some sweet Ajax
> in there, too.
OK, I''m very excited about Migrations; but still not sure how to use
them.

The announcement on the weblog says:

   With migrations, you can describe the transformations in
   self-contained classes that can be checked into version control
   systems and executed against another database that might be one,
   two, or five versions behind.

The documentation says:

   The Rails package has support for migrations with the
   script/generate migration my_new_migration command and with the
   rake migrate command that''ll run all the pending migrations.
It''ll
   even create the needed schema_info table automatically if it''s
   missing.

What I don''t understand is how the ''rake migrate''
target knows which
migrations to apply and in what order.  Also, what''s this
''schema_info'' table?  I''m sure that''s the
key, but it''s still
undocumented.

Finally, since migrations supports create_table, should we quit using
the create_scheme.sql files and just use migrations from the start of
an app?  Seems like the weakness of this approach would be that there
isn''t a single file that has the complete picture of what the database
scheme is.
-- 
doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org

On Jul 7, 2005, at 7:26 AM, Doug Alcorn wrote:
> OK, I''m very excited about Migrations; but still not sure how to
use
> them.
>
Thanks, Doug... I was about to ask the same thing.

<snip>
> Finally, since migrations supports create_table, should we quit using
> the create_scheme.sql files and just use migrations from the start of
> an app?  Seems like the weakness of this approach would be that there
> isn''t a single file that has the complete picture of what the
database
> scheme is.
I think the point of using migrations is that during development  
there is no stability in the database scheme so there''s no point in  
trying to export it all of the time.  Rather, use incremental steps  
during development and then export the final product for  
documentation or transportation of the app.

I''m very excited about this new feature!  Thanks to DHH for pushing  
it through (I heard he was almost alone on this feature for a while).

Duane Johnson
(canadaduane)




_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

> I think the point of using migrations is that during development there is
no
> stability in the database scheme so there''s no point in trying to
export it
> all of the time.  Rather, use incremental steps during development and then
> export the final product for documentation or transportation of the app.
Sounds good.  If you need to export a schema, you can always do ''rake
db_structure_dump'' (the same task that gets called when you run
tests).

-- 
rick
http://techno-weenie.net

On 7/7/05, Doug Alcorn <doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org>
wrote:
> OK, I''m very excited about Migrations; but still not sure how to
use
> them.
> 
> What I don''t understand is how the ''rake
migrate'' target knows which
> migrations to apply and in what order.  Also, what''s this
> ''schema_info'' table?  I''m sure that''s
the key, but it''s still
> undocumented.
> 
> Finally, since migrations supports create_table, should we quit using
> the create_scheme.sql files and just use migrations from the start of
> an app?  Seems like the weakness of this approach would be that there
> isn''t a single file that has the complete picture of what the
database
> scheme is.
+1

-- 
Regards,
John Wilger

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don''t know," Alice answered.
"Then," said the cat, "it doesn''t matter."
- Lewis Carrol, Alice in Wonderland

On Jul 7, 2005, at 8:21 AM, John Wilger wrote:
> On 7/7/05, Doug Alcorn <doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org>
wrote:
>
>> OK, I''m very excited about Migrations; but still not sure how
to use
>> them.
>>
>> What I don''t understand is how the ''rake
migrate'' target knows which
>> migrations to apply and in what order.  Also, what''s this
>> ''schema_info'' table?  I''m sure
that''s the key, but it''s still
>> undocumented.
Each migration is stored in a file with a number at the front. The  
number determines how the migrations are ordered. The number is  
automatically detected and incremented if you use the migrations  
generator:

   ruby script/generate migration AddIndexOnFoo

That would create a file:

   db/migrate/1_add_index_on_foo.rb

(assuming you didn''t have any migrations initially).

As for the schema_info table, all it is right now is a single row  
with a single column: "version". The version column is used to  
determine the number of the last applied migration, so Rails knows  
what subsequent migrations to apply.
>>
>> Finally, since migrations supports create_table, should we quit using
>> the create_scheme.sql files and just use migrations from the start of
>> an app?  Seems like the weakness of this approach would be that there
>> isn''t a single file that has the complete picture of what the
>> database
>> scheme is.
>>
> +1
You could stop using a create_schema.sql file. Remember, your current  
schema is always dumped to db/development_structure.sql when you run  
rake without any parameters (or when you run ''rake  
db_structure_dump''). Thus, you can always capture the current  
structure of your database that way.

- Jamis

>> Finally, since migrations supports create_table, should we quit using
>> the create_scheme.sql files and just use migrations from the start of
>> an app?  Seems like the weakness of this approach would be that there
I think migrations are mainly useful for pushing db changes into
production applicaions. I''d stick with a create sql script for your
development branch. Migration scripts are, IMHO, a necessary evil for
systems that are in production. This does look very promising,
however, for making such migrations a little less evil. :)
>From the documentation: ''push that change to other developers and
to
the production server''. The way to push it to other developers is to
check in your changes to create.sql/drop.sql/alter.sql and they can
run those. If you are testing under a huge load of test data, then I
could see using migrations, maybe, but it really doesn''t look like the
way to manage your database development. Imagine a bunch of classes
like this:

class AddSsl < ActiveRecord::Migration
    def self.up
      add_column :accounts, :ssl_enabled, :boolean, :default => 1
    end

    def self.down
      remove_column :accounts, :ssl_enabled
    end
  end

for every column of every table in your database that changes. Ew. :)
I think this is better:

ssl_enabled TINYINT(1) UNSIGNED NOT NULL DEFAULT 0,

-Tom

-- 
Tom Wilcoxen
http://convergentarts.com

Jamis Buck <jamis-uHoyYlH2B+GakBO8gow8eQ@public.gmane.org> writes:
>>> What I don''t understand is how the ''rake
migrate'' target knows which
>>> migrations to apply and in what order.  Also, what''s this
>>> ''schema_info'' table?  I''m sure
that''s the key, but it''s still
>>> undocumented.
>
> Each migration is stored in a file with a number at the front. The  
> number determines how the migrations are ordered. The number is  
> automatically detected and incremented if you use the migrations  
> generator:
>
>   ruby script/generate migration AddIndexOnFoo
>
> That would create a file:
>
>   db/migrate/1_add_index_on_foo.rb
>
> (assuming you didn''t have any migrations initially).
>
> As for the schema_info table, all it is right now is a single row  
> with a single column: "version". The version column is used to  
> determine the number of the last applied migration, so Rails knows  
> what subsequent migrations to apply.
This is exactly the missing piece.  Thanks.
-- 
doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org