Rails core - Jun 2006 - migrations unit test and sqlite3 add_column

Hi all,

I submitted a patch the other day for an issue I ran into running an  
"add_column" migration on a sqlite3 database when there is existing  
data in the table, and the new column has ":null=>false".

Details at http://dev.rubyonrails.org/ticket/5215.

The issue I encountered was not picked due to the unit test not  
having any actual data in it before running the migration.  I later  
ran into an issue with postgresql when doing an "add_column"  
migration for a different reason.  I am wondering two things:

1) What''s the normal period from when a patch is submitted to when it  
is reviewed or committed?
2) if #1 happens, my patch to the unit test might reveal bugs in  
other adapters besides sqlite3, so how would that be handled?

I really like the idea of migrations and would love to see the  
stability of them improved.

Thanks,

Greg


_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

> 1) What''s the normal period from when a patch is submitted to when
it is
> reviewed or committed?
Depends. Some patches are well-tested, their motivation instantly
appeal to the reviewer, and their impact is small and well understood.
These patches are usually applied as soon as they''re discovered.
Patches that deviate in some form or another from those properties can
take all from a little while, to a long time, to never to get applied.
> 2) if #1 happens, my patch to the unit test might reveal bugs in other
> adapters besides sqlite3, so how would that be handled?
Usually people responsible for these adapters will either make a patch
of their own or raise the issue here.
> I really like the idea of migrations and would love to see the stability of
> them improved.
Excellent. Please do keep working. Your patch was applied, btw.
-- 
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

Good to hear the patch was applied.  I just submitted another patch,  
#5296 that improves the unit test more so as to not break on Oracle,  
and fixes the add_column on Postgresql 8 when there is data in the  
table and new column is non-null.

Greg

On Jun 4, 2006, at 11:42 PM, David Heinemeier Hansson wrote:
>> 1) What''s the normal period from when a patch is submitted to
when
>> it is
>> reviewed or committed?
>
> Depends. Some patches are well-tested, their motivation instantly
> appeal to the reviewer, and their impact is small and well understood.
> These patches are usually applied as soon as they''re discovered.
> Patches that deviate in some form or another from those properties can
> take all from a little while, to a long time, to never to get applied.
>
>> 2) if #1 happens, my patch to the unit test might reveal bugs in  
>> other
>> adapters besides sqlite3, so how would that be handled?
>
> Usually people responsible for these adapters will either make a patch
> of their own or raise the issue here.
>
>> I really like the idea of migrations and would love to see the  
>> stability of
>> them improved.
>
> Excellent. Please do keep working. Your patch was applied, btw.
> -- 
> 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-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
>


_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core