Hey guys, We''re now beginning to finalise rails 1.1, and we need to make sure that we don''t miss any heinous bugs. While we''ll all be giving the list a once over, we''re only human and we''re likely to miss things. So, if you have any tickets which you think need to be addressed, please bring them up in this thread, or add a keyword of needs_review. We''re pretty keen on pushing out a 1.1 release pretty soon, but we also want to get all the nasty bugs. -- Cheers Koz
On Feb 26, 2006, at 1:13 PM, Michael Koziarski wrote:> Hey guys, > > We''re now beginning to finalise rails 1.1, and we need to make sure > that we don''t miss any heinous bugs. While we''ll all be giving the > list a once over, we''re only human and we''re likely to miss things. > > So, if you have any tickets which you think need to be addressed, > please bring them up in this thread, or add a keyword of > needs_review. We''re pretty keen on pushing out a 1.1 release pretty > soon, but we also want to get all the nasty bugs.How about the Sybase connection adapter? Any chance of getting that into 1.1? I can update the patch against the latest trunk and resubmit if that''ll help. The patch only touches test code and adds a single new application source file, sybase_adapter.rb. http://dev.rubyonrails.org/ticket/3765 John -- John R. Sheets http://umber.sourceforge.net http://writersforge.sourceforge.net
> How about the Sybase connection adapter? Any chance of getting that > into 1.1? I can update the patch against the latest trunk and > resubmit if that''ll help. The patch only touches test code and adds > a single new application source file, sybase_adapter.rb. > > http://dev.rubyonrails.org/ticket/3765Please do polish against trunk and ensure that the adapter has all the documentation for connection and any potential caveats. Ping here when done and I''ll apply. -- 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
Michael Koziarski schrieb:> Hey guys, > > We''re now beginning to finalise rails 1.1, and we need to make sure > that we don''t miss any heinous bugs. While we''ll all be giving the > list a once over, we''re only human and we''re likely to miss things.This is neither a bug nor very important, but http://dev.rubyonrails.org/ticket/3461 is trivial, useful and 100% backwards compatible, so I don''t think there is any reason for not including it in 1.1.
> This is neither a bug nor very important, but > http://dev.rubyonrails.org/ticket/3461 is trivial, useful and 100% > backwards compatible, so I don''t think there is any reason for not > including it in 1.1.Applied. -- 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
Hi, This patch: http://dev.rubyonrails.org/ticket/3530 would be nice to include... greets, Abdur-Rahman Andreas Schwarz wrote:> Michael Koziarski schrieb: > >> Hey guys, >> >> We''re now beginning to finalise rails 1.1, and we need to make sure >> that we don''t miss any heinous bugs. While we''ll all be giving the >> list a once over, we''re only human and we''re likely to miss things. >> > > This is neither a bug nor very important, but > http://dev.rubyonrails.org/ticket/3461 is trivial, useful and 100% > backwards compatible, so I don''t think there is any reason for not > including it in 1.1. > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > >
I am voting for tickets #3811 To be precise I am voting for fixing problem with :index in datetime select. In http://dev.rubyonrails.org/ticket/3811 Bob made great job by consolidation all ticket related to date helper. I am using patch from this ticket on stage server and it works as expected (:index param in datetime_select). On 2/26/06, Michael Koziarski <michael@koziarski.com> wrote:> > Hey guys, > > We''re now beginning to finalise rails 1.1, and we need to make sure > that we don''t miss any heinous bugs. While we''ll all be giving the > list a once over, we''re only human and we''re likely to miss things. > > So, if you have any tickets which you think need to be addressed, > please bring them up in this thread, or add a keyword of > needs_review. We''re pretty keen on pushing out a 1.1 release pretty > soon, but we also want to get all the nasty bugs. > > -- > Cheers > > Koz > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >-- anatol (http://pomozov.info) _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Ruby 1.8.4 comes with soap4r 1.5.5. With this version of soap4r actionwebservice is completely broken. Any soap rpc call which returns a value results with ''can''t modify frozen object'' exception. There is a ticket open for this problem http://dev.rubyonrails.org/ticket/2553 There are several proposed fixes for this problem. I''ve attached my own solution which doesn''t require patching of soap4r classes. This is stop-ship problem I think. Can somebody take a look? Thanks, Kent. On 2/26/06, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:> I am voting for tickets #3811 > To be precise I am voting for fixing problem with :index in datetime select. > > In http://dev.rubyonrails.org/ticket/3811 Bob made great > job by consolidation all ticket related to date helper. I am using patch > from this ticket on stage server and it works as expected (:index param in > datetime_select). > > > On 2/26/06, Michael Koziarski <michael@koziarski.com> wrote: > > Hey guys, > > > > We''re now beginning to finalise rails 1.1, and we need to make sure > > that we don''t miss any heinous bugs. While we''ll all be giving the > > list a once over, we''re only human and we''re likely to miss things. > > > > So, if you have any tickets which you think need to be addressed, > > please bring them up in this thread, or add a keyword of > > needs_review. We''re pretty keen on pushing out a 1.1 release pretty > > soon, but we also want to get all the nasty bugs. > > > > -- > > Cheers > > > > Koz > > _______________________________________________ > > Rails-core mailing list > > Rails-core@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > > > > > -- > anatol (http://pomozov.info) > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > >-- Kent --- http://www.datanoise.com
On Mon, Feb 27, 2006 at 08:13:39AM +1300, Michael Koziarski wrote:> So, if you have any tickets which you think need to be addressed, > please bring them up in this thread, or add a keyword of > needs_review. We''re pretty keen on pushing out a 1.1 release pretty > soon, but we also want to get all the nasty bugs.http://dev.rubyonrails.org/ticket/3819 has_many changes it''s arguments unexpectedly. Impact is probably rare, but causes *really* weird bugs when it bites you. Patch is minor and unintrusive, and includes a full test case. Complicated by the fact that the other association types probably have to be audited for equivalent problems. I''ve also tagged the bug appropriately. Thanks, - Matt
Anyone have comments on ticket 3935 (http://dev.rubyonrails.org/ticket/3935) ? I think it should be in 1.1. It allows for a set_fixture_class method in unit tests so table accessor methods still work if your model uses a set_table_name call. So for example (and from the unit tests): model: class Joke < ActiveRecord::Base set_table_name ''funny_jokes'' end The fixture would be at test/fixtures/funny_jokes.yml In the unit test, you would need to supply: set_fixture_class :funny_jokes => ''Joke'' Additionally, I had in mind a later patch which would allow for: fixtures :funny_jokes => ''Joke'', :more_things => ''Thing'' and would call set_fixture_class and then fixtures if passed a hash instead of of an array. The one thing that may need thought is that in order to make this change, I had to change the prototypes of Fixture#initialize, Fixtures#initialize and Fixtures#create_fixtures, which are not backwards compatable, but the only code in rails which uses these is in the fixtures code and the test code. I think making fixtures work for models with set_table_name is more important. Thoughts?
> So, if you have any tickets which you think need to be addressed, > please bring them up in this thread, or add a keyword of > needs_review. We''re pretty keen on pushing out a 1.1 release pretty > soon, but we also want to get all the nasty bugs.It''s always kind of bugged me that the Oracle adapter is named "oci", seems odd relative to all the other adapters. Would the core group be open to a patch that renamed this "oracle", w/ the required stubs to maintain backwards compatibility? Or am I being too nit-picky?
> It''s always kind of bugged me that the Oracle adapter is named "oci", > seems odd relative to all the other adapters. > > Would the core group be open to a patch that renamed this "oracle", w/ > the required stubs to maintain backwards compatibility? > > Or am I being too nit-picky?It''s legacy from when we had two adapters. I think a rename with stubs would be good. Do patch. -- 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
Applied (with some refactoring). -Thomas Am 26.02.2006 um 21:31 schrieb Abdur-Rahman Advany:> Hi, > > This patch: http://dev.rubyonrails.org/ticket/3530 would be nice to > include... > > greets, > > Abdur-Rahman > > Andreas Schwarz wrote: >> Michael Koziarski schrieb: >> >>> Hey guys, >>> >>> We''re now beginning to finalise rails 1.1, and we need to make sure >>> that we don''t miss any heinous bugs. While we''ll all be giving the >>> list a once over, we''re only human and we''re likely to miss things. >>> >> >> This is neither a bug nor very important, but >> http://dev.rubyonrails.org/ticket/3461 is trivial, useful and 100% >> backwards compatible, so I don''t think there is any reason for not >> including it in 1.1. >> >> _______________________________________________ >> 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
Please remember that almost everyone that uses Oracle knows exactly what "oci" is. Also, "oci" isn''t quite the best way of integrating with Oracle anymore (although it does certainly work!), so I would suggest having a stub named "oracle" and keeping the "oci" one as it is until someone gets around to implementing the preferred "thin" approach. On 2/27/06, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:> > It''s always kind of bugged me that the Oracle adapter is named "oci", > > seems odd relative to all the other adapters. > > > > Would the core group be open to a patch that renamed this "oracle", w/ > > the required stubs to maintain backwards compatibility? > > > > Or am I being too nit-picky? > > It''s legacy from when we had two adapters. I think a rename with stubs > would be good. Do patch. > -- > 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 >
Thnx, now I can include it in the tutorial... Thomas Fuchs wrote:> Applied (with some refactoring). > > -Thomas > > Am 26.02.2006 um 21:31 schrieb Abdur-Rahman Advany: > >> Hi, >> >> This patch: http://dev.rubyonrails.org/ticket/3530 would be nice to >> include... >> >> greets, >> >> Abdur-Rahman >> >> Andreas Schwarz wrote: >>> Michael Koziarski schrieb: >>> >>>> Hey guys, >>>> >>>> We''re now beginning to finalise rails 1.1, and we need to make sure >>>> that we don''t miss any heinous bugs. While we''ll all be giving the >>>> list a once over, we''re only human and we''re likely to miss things. >>>> >>> >>> This is neither a bug nor very important, but >>> http://dev.rubyonrails.org/ticket/3461 is trivial, useful and 100% >>> backwards compatible, so I don''t think there is any reason for not >>> including it in 1.1. >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
I''m probably one of two people using Rails who really cares about the little annoyances that come with choosing to use primary key field names of tablename_id. :) I don''t know if it''s 1.1 worthy, but I would like some feedback on http://dev.rubyonrails.org/ticket/3373 -- specifically, what would the preferred location be for a globally- accessible way to get the primary key field name based on ActiveRecord::Base.primary_key_prefix_type. This comes up not only when generating fixtures (the subject of that patch), but also with schema dump and migrations. I have other patches that I use for schema dumping and migrations that improve the support for ActiveRecord::Base.primary_key_prefix_type, so it wouldn''t take me long to add some tests and submit a patch if I had a pointer on where that case statement would best reside. On Feb 26, 2006, at 11:13 AM, Michael Koziarski wrote:> Hey guys, > > We''re now beginning to finalise rails 1.1, and we need to make sure > that we don''t miss any heinous bugs. While we''ll all be giving the > list a once over, we''re only human and we''re likely to miss things. > > So, if you have any tickets which you think need to be addressed, > please bring them up in this thread, or add a keyword of > needs_review. We''re pretty keen on pushing out a 1.1 release pretty > soon, but we also want to get all the nasty bugs. > > -- > Cheers > > Koz > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core
Hi Benjamin, On Feb 27, 2006, at 5:59 AM, Benjamin Curtis wrote:> I''m probably one of two people using Rails who really cares about > the little annoyances that come with choosing to use primary key > field names of tablename_id. :) I don''t know if it''s 1.1 worthy, > but I would like some feedback on http://dev.rubyonrails.org/ticket/ > 3373 -- specifically, what would the preferred location be for a > globally-accessible way to get the primary key field name based on > ActiveRecord::Base.primary_key_prefix_type. This comes up not only > when generating fixtures (the subject of that patch), but also with > schema dump and migrations. > > I have other patches that I use for schema dumping and migrations > that improve the support for > ActiveRecord::Base.primary_key_prefix_type, so it wouldn''t take me > long to add some tests and submit a patch if I had a pointer on > where that case statement would best reside.I guess I''m the other one. :-) I run into SQLite databases that use that convention, so I''d use this fix if it were available... -- Ernie P.
Something else to consider for 1.1, currently, when using Polymorphic associations, the code doesn''t properly build the primary key. Currently, you can work around this by providing :foreign_key. http://dev.rubyonrails.org/ticket/3820 -----Original Message----- From: rails-core-bounces@lists.rubyonrails.org [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf Of Dr.Ernie Prabhakar Sent: Monday, February 27, 2006 9:43 AM To: rails-core@lists.rubyonrails.org Subject: Re: [Rails-core] Rails 1.1 is coming Hi Benjamin, On Feb 27, 2006, at 5:59 AM, Benjamin Curtis wrote:> I''m probably one of two people using Rails who really cares about > the little annoyances that come with choosing to use primary key > field names of tablename_id. :) I don''t know if it''s 1.1 worthy, > but I would like some feedback on http://dev.rubyonrails.org/ticket/ > 3373 -- specifically, what would the preferred location be for a > globally-accessible way to get the primary key field name based on > ActiveRecord::Base.primary_key_prefix_type. This comes up not only > when generating fixtures (the subject of that patch), but also with > schema dump and migrations. > > I have other patches that I use for schema dumping and migrations > that improve the support for > ActiveRecord::Base.primary_key_prefix_type, so it wouldn''t take me > long to add some tests and submit a patch if I had a pointer on > where that case statement would best reside.I guess I''m the other one. :-) I run into SQLite databases that use that convention, so I''d use this fix if it were available... -- Ernie P. _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Here''s a few more trivial patches that I run in a few apps without issues: http://dev.rubyonrails.org/ticket/3952 - Adds additional contraints to validates_numericality_of. Updated as per DHH''s request to use long names instead of abbreviations. http://dev.rubyonrails.org/ticket/3506 - I just added a new patch following DHH''s last recommendation. http://dev.rubyonrails.org/ticket/3691 - Adds :after_update_element to text_field_with_auto_complete to hook into the afterUpdateElement event, also adds :frequency for polling info. http://dev.rubyonrails.org/ticket/3353 - Adds unique ids to radio elements http://dev.rubyonrails.org/ticket/3313 - Modifies the regex to not nuke the - on a negative value (keeps IDs unique) http://dev.rubyonrails.org/ticket/3136 - Extends country_select to optionally include the country codes. I''ll also have the date_helper patch updated to trunk tonight. Not sure what''s wrong with it yet but bitsweat asked for updated tests against trunk so... Bob Silva http://www.railtie.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 27, 2006, at 6:24 PM, Bob Silva wrote:> I''ll also have the date_helper patch updated to trunk tonight. Not > sure > what''s wrong with it yet but bitsweat asked for updated tests > against trunk > so...Hey, it simply doesn''t apply cleanly to trunk. The patch looks great. Thanks, jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFEA7YgAQHALep9HFYRAoeGAJ9E/L8qwYC9kpMxAjtHzIAoje8w4wCgwIQR Nsqt66FFvOVbWucAlhVvHAI=uu2L -----END PGP SIGNATURE-----
Roger...like I said, I hadn''t looked yet, I''ll get it fixed up shortly. Bob Silva http://www.railtie.net/> -----Original Message----- > From: rails-core-bounces@lists.rubyonrails.org [mailto:rails-core- > bounces@lists.rubyonrails.org] On Behalf Of Jeremy Kemper > Sent: Monday, February 27, 2006 6:32 PM > To: rails-core@lists.rubyonrails.org > Subject: Re: [Rails-core] Rails 1.1 is coming > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Feb 27, 2006, at 6:24 PM, Bob Silva wrote: > > I''ll also have the date_helper patch updated to trunk tonight. Not > > sure > > what''s wrong with it yet but bitsweat asked for updated tests > > against trunk > > so... > > Hey, it simply doesn''t apply cleanly to trunk. The patch looks great. > > Thanks, > jeremy > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (Darwin) > > iD8DBQFEA7YgAQHALep9HFYRAoeGAJ9E/L8qwYC9kpMxAjtHzIAoje8w4wCgwIQR > Nsqt66FFvOVbWucAlhVvHAI> =uu2L > -----END PGP SIGNATURE----- > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core
By date_helper you are referring to your time_select tag? If not, I
recommend getting that into the core. It is a requirement for anyone who is
using the :time column type. Currently when using the
field(''object'',
''method''), for a time column, it returns nothing but an empty
string.
I have made enhancements to make this so, but am unsure if you have already
submitted this?
-Nb
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nathaniel S. H. Brown http://nshb.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> -----Original Message-----
> From: rails-core-bounces@lists.rubyonrails.org
> [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf
> Of Bob Silva
> Sent: February 27, 2006 6:25 PM
> To: rails-core@lists.rubyonrails.org
> Subject: RE: [Rails-core] Rails 1.1 is coming
>
> Here''s a few more trivial patches that I run in a few apps
> without issues:
>
>
> http://dev.rubyonrails.org/ticket/3952 - Adds additional
> contraints to validates_numericality_of. Updated as per DHH''s
> request to use long names instead of abbreviations.
>
> http://dev.rubyonrails.org/ticket/3506 - I just added a new
> patch following DHH''s last recommendation.
>
> http://dev.rubyonrails.org/ticket/3691 - Adds
> :after_update_element to text_field_with_auto_complete to
> hook into the afterUpdateElement event, also adds :frequency
> for polling info.
>
> http://dev.rubyonrails.org/ticket/3353 - Adds unique ids to
> radio elements
>
> http://dev.rubyonrails.org/ticket/3313 - Modifies the regex
> to not nuke the
> - on a negative value (keeps IDs unique)
>
> http://dev.rubyonrails.org/ticket/3136 - Extends
> country_select to optionally include the country codes.
>
>
>
> I''ll also have the date_helper patch updated to trunk
> tonight. Not sure what''s wrong with it yet but bitsweat asked
> for updated tests against trunk so...
>
>
> Bob Silva
> http://www.railtie.net/
>
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
Hi Nathaniel, http://dev.rubyonrails.org/ticket/3811 Which includes time_select. If you want to send me your enhancements, I''ll add them (if they aren''t already in the patch, which is different from my plugin). Bob Silva http://www.railtie.net/> -----Original Message----- > From: rails-core-bounces@lists.rubyonrails.org [mailto:rails-core- > bounces@lists.rubyonrails.org] On Behalf Of Nathaniel S. H. Brown > Sent: Monday, February 27, 2006 8:12 PM > To: rails-core@lists.rubyonrails.org > Subject: RE: [Rails-core] Rails 1.1 is coming > > By date_helper you are referring to your time_select tag? If not, I > recommend getting that into the core. It is a requirement for anyone who > is > using the :time column type. Currently when using the field(''object'', > ''method''), for a time column, it returns nothing but an empty string. > > I have made enhancements to make this so, but am unsure if you have > already > submitted this? > > -Nb > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Nathaniel S. H. Brown http://nshb.net > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > -----Original Message----- > > From: rails-core-bounces@lists.rubyonrails.org > > [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf > > Of Bob Silva > > Sent: February 27, 2006 6:25 PM > > To: rails-core@lists.rubyonrails.org > > Subject: RE: [Rails-core] Rails 1.1 is coming > > > > Here''s a few more trivial patches that I run in a few apps > > without issues: > > > > > > http://dev.rubyonrails.org/ticket/3952 - Adds additional > > contraints to validates_numericality_of. Updated as per DHH''s > > request to use long names instead of abbreviations. > > > > http://dev.rubyonrails.org/ticket/3506 - I just added a new > > patch following DHH''s last recommendation. > > > > http://dev.rubyonrails.org/ticket/3691 - Adds > > :after_update_element to text_field_with_auto_complete to > > hook into the afterUpdateElement event, also adds :frequency > > for polling info. > > > > http://dev.rubyonrails.org/ticket/3353 - Adds unique ids to > > radio elements > > > > http://dev.rubyonrails.org/ticket/3313 - Modifies the regex > > to not nuke the > > - on a negative value (keeps IDs unique) > > > > http://dev.rubyonrails.org/ticket/3136 - Extends > > country_select to optionally include the country codes. > > > > > > > > I''ll also have the date_helper patch updated to trunk > > tonight. Not sure what''s wrong with it yet but bitsweat asked > > for updated tests against trunk so... > > > > > > Bob Silva > > http://www.railtie.net/ > > > > > > _______________________________________________ > > 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
Hi Jeremy, http://dev.rubyonrails.org/ticket/3811 By chance did you use the last patch listed on that page? Someone else added a patch against the 1.0 branch after mine which doesn''t apply cleanly to trunk. I repatched my linux and windows servers and Kevin Clark helped out on OS X and everything applied and tested fine. Can you send me the output of your test suite, shouldn''t be any platform issues but you never know. Not sure how to proceed. Thanks Bob On Monday, February 27, 2006, at 6:41 PM, Bob Silva wrote:>Roger...like I said, I hadn''t looked yet, I''ll get it fixed up shortly. > >Bob Silva >http://www.railtie.net/ > >> -----Original Message----- >> From: rails-core-bounces@lists.rubyonrails.org [mailto:rails-core- >> bounces@lists.rubyonrails.org] On Behalf Of Jeremy Kemper >> Sent: Monday, February 27, 2006 6:32 PM >> To: rails-core@lists.rubyonrails.org >> Subject: Re: [Rails-core] Rails 1.1 is coming >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Feb 27, 2006, at 6:24 PM, Bob Silva wrote: >> > I''ll also have the date_helper patch updated to trunk tonight. Not >> > sure >> > what''s wrong with it yet but bitsweat asked for updated tests >> > against trunk >> > so... >> >> Hey, it simply doesn''t apply cleanly to trunk. The patch looks great. >> >> Thanks, >> jeremy >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.2 (Darwin) >> >> iD8DBQFEA7YgAQHALep9HFYRAoeGAJ9E/L8qwYC9kpMxAjtHzIAoje8w4wCgwIQR >> Nsqt66FFvOVbWucAlhVvHAI>> =uu2L >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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-- Posted with http://DevLists.com. Sign up and save your time!
Yep looks like you got it in that change. There are some hardcore tests in
there :)
My addition had the def to_tag(options = {}) case for :time.
-Nb
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nathaniel S. H. Brown http://nshb.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> -----Original Message-----
> From: rails-core-bounces@lists.rubyonrails.org
> [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf
> Of Bob Silva
> Sent: February 27, 2006 8:22 PM
> To: rails-core@lists.rubyonrails.org
> Subject: RE: [Rails-core] Rails 1.1 is coming
>
> Hi Nathaniel,
>
> http://dev.rubyonrails.org/ticket/3811
>
> Which includes time_select. If you want to send me your
> enhancements, I''ll add them (if they aren''t already in
the
> patch, which is different from my plugin).
>
>
> Bob Silva
> http://www.railtie.net/
>
> > -----Original Message-----
> > From: rails-core-bounces@lists.rubyonrails.org [mailto:rails-core-
> > bounces@lists.rubyonrails.org] On Behalf Of Nathaniel S. H. Brown
> > Sent: Monday, February 27, 2006 8:12 PM
> > To: rails-core@lists.rubyonrails.org
> > Subject: RE: [Rails-core] Rails 1.1 is coming
> >
> > By date_helper you are referring to your time_select tag? If not, I
> > recommend getting that into the core. It is a requirement
> for anyone
> > who is using the :time column type. Currently when using the
> > field(''object'', ''method''), for a
time column, it returns
> nothing but
> > an empty string.
> >
> > I have made enhancements to make this so, but am unsure if you have
> > already submitted this?
> >
> > -Nb
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Nathaniel S. H. Brown http://nshb.net
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> > > -----Original Message-----
> > > From: rails-core-bounces@lists.rubyonrails.org
> > > [mailto:rails-core-bounces@lists.rubyonrails.org] On
> Behalf Of Bob
> > > Silva
> > > Sent: February 27, 2006 6:25 PM
> > > To: rails-core@lists.rubyonrails.org
> > > Subject: RE: [Rails-core] Rails 1.1 is coming
> > >
> > > Here''s a few more trivial patches that I run in a few
> apps without
> > > issues:
> > >
> > >
> > > http://dev.rubyonrails.org/ticket/3952 - Adds additional
> contraints
> > > to validates_numericality_of. Updated as per DHH''s
request to use
> > > long names instead of abbreviations.
> > >
> > > http://dev.rubyonrails.org/ticket/3506 - I just added a new patch
> > > following DHH''s last recommendation.
> > >
> > > http://dev.rubyonrails.org/ticket/3691 - Adds
> :after_update_element
> > > to text_field_with_auto_complete to hook into the
> afterUpdateElement
> > > event, also adds :frequency for polling info.
> > >
> > > http://dev.rubyonrails.org/ticket/3353 - Adds unique ids to radio
> > > elements
> > >
> > > http://dev.rubyonrails.org/ticket/3313 - Modifies the
> regex to not
> > > nuke the
> > > - on a negative value (keeps IDs unique)
> > >
> > > http://dev.rubyonrails.org/ticket/3136 - Extends
> country_select to
> > > optionally include the country codes.
> > >
> > >
> > >
> > > I''ll also have the date_helper patch updated to trunk
> tonight. Not
> > > sure what''s wrong with it yet but bitsweat asked for
> updated tests
> > > against trunk so...
> > >
> > >
> > > Bob Silva
> > > http://www.railtie.net/
> > >
> > >
> > > _______________________________________________
> > > 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
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
David Heinemeier Hansson wrote:>> It''s always kind of bugged me that the Oracle adapter is named "oci", >> seems odd relative to all the other adapters. >> >> Would the core group be open to a patch that renamed this "oracle", w/ >> the required stubs to maintain backwards compatibility? > > It''s legacy from when we had two adapters. I think a rename with stubs > would be good. Do patch.Patch submitted at: http://dev.rubyonrails.org/ticket/4017 Supports use as either "oci" or "oracle".
> Supports use as either "oci" or "oracle".Applied. -- 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
On Feb 26, 2006, at 2:08 PM, David Heinemeier Hansson wrote:>> How about the Sybase connection adapter? Any chance of getting that >> into 1.1? I can update the patch against the latest trunk and >> resubmit if that''ll help. The patch only touches test code and adds >> a single new application source file, sybase_adapter.rb. >> >> http://dev.rubyonrails.org/ticket/3765 > > Please do polish against trunk and ensure that the adapter has all the > documentation for connection and any potential caveats. Ping here when > done and I''ll apply.Okay, finally got it cleaned up and working against recent trunk. The patch is at http://dev.rubyonrails.org/attachment/ticket/3765/ sybase_ctlib_adapter_trunk_r3727.diff Thanks, John -- John R. Sheets http://umber.sourceforge.net http://writersforge.sourceforge.net _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
> Okay, finally got it cleaned up and working against recent trunk. The patchGreat work, John! It has been applied. If at all possible, please do setup some form of automated testing for this adapter. Say a script that checks out Active Record once a day/week, runs the tests, and emails you if something is b0rked. That''d give us the confidence that this adapter is always operational even if the core team can''t test it themselves. -- 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
On Mar 1, 2006, at 7:17 PM, David Heinemeier Hansson wrote:> If at all possible, please do > setup some form of automated testing for this adapter. Say a script > that checks out Active Record once a day/week, runs the tests, and > emails you if something is b0rked. That''d give us the confidence that > this adapter is always operational even if the core team can''t test it > themselves.I don''t personally have the resources to set up an automated system with access to a Sybase database, but I''ll certainly keep up to date with trunk and frequently run those unit tests manually. Perhaps there''s a good Samaritan out there somewhere...? Regarding those unit test caveats, I can probably get those cleaned up too, with a little advice. The date problem is a single bug regarding "decorated" (?) dates on a HABTM join table always coming back in String form. I''m guessing that should be a Date or Time object, right? I haven''t been able to track down where the conversion is failing. Also, I''m getting four errors on :polymorphic joins, with INSERT tag_id of NULL. I assume the other adapters aren''t seeing this, so gotta be some subtle problem with the Sybase adapter. See my email from yesterday for details. And finally, there''s the binary support, which with the ctlib bindings seems to require a separate loading method. I can probably track that one down on my end, but the other two problems have me baffled. Any suggestions? John -- John R. Sheets http://umber.sourceforge.net http://writersforge.sourceforge.net
This may have gotten lost at the bottom of my email re: another topic so I''m repeating it again..... How about that connection pooling adaptor for Rails 1.1? There is a patch attached to http://dev.rubyonrails.org/ticket/2162 that''s been hanging out for a while, we''d love to see it make it into the core at some point. Many thanks, Greg
On Wed, Mar 01, 2006 at 10:35:14PM -0600, John Sheets wrote:> I don''t personally have the resources to set up an automated system > with access to a Sybase database, but I''ll certainly keep up to date > with trunk and frequently run those unit tests manually. Perhaps > there''s a good Samaritan out there somewhere...?I was just looking into setting something like this up, but it appears that Sybase is very much not open source, and it''s not at all obvious to me after a little bit of research which of their "demo" products I would want to download to just run a database, or whether a "demo" product would even allow me to accomplish this. Any suggestions? -- Keegan Quinn <keegan@thebasement.org> CEO, Producer the basement productions http://www.thebasement.org _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
On Mar 4, 2006, at 3:58 PM, Keegan Quinn wrote:> On Wed, Mar 01, 2006 at 10:35:14PM -0600, John Sheets wrote: >> I don''t personally have the resources to set up an automated system >> with access to a Sybase database, but I''ll certainly keep up to date >> with trunk and frequently run those unit tests manually. Perhaps >> there''s a good Samaritan out there somewhere...? > > I was just looking into setting something like this up, but it > appears that Sybase is very much not open source, and it''s not at all > obvious to me after a little bit of research which of their "demo" > products I would want to download to just run a database, or whether > a "demo" product would even allow me to accomplish this. > > Any suggestions?Sure. The version I''ve used for all my Rails testing so far is at: http://www.sybase.com/ase_1252devel Free to download and use for development, not hobbled at all, and no sunset clause. I''m sure it''d have to be for personal use only. AFAIK, you couldn''t expose it through a public website -- that''s when they start charging the big $$$. The license agreement should spell it out concretely. John -- John R. Sheets http://umber.sourceforge.net http://writersforge.sourceforge.net
On 3/3/06, Greg Lappen <greg@lapcominc.com> wrote:> This may have gotten lost at the bottom of my email re: another topic > so I'm repeating it again..... > > How about that connection pooling adaptor for Rails 1.1? > > There is a patch attached to http://dev.rubyonrails.org/ticket/2162 > that's been hanging out for a while, we'd love to see it make it into > the core at some point. > > Many thanks, > > GregI've never really tested it with the new connection keep-alive changes made in 1.0 (or the additional changes in 1.1). I think it would be best to adapt into a plugin that works against 1.1, then think about integrating into the core for 1.2 (which would give us time to refactor the ActiveRecord connection management code). I've got a few days off work at the end of the week, and a number of enhancements/plugins that need work on. I'll add this to the list. Tom _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
I had the same thought after I requested this to be in Rails 1.1, but its not clear how plugins would work if we were using ActiveRecord outside of a Rails application. I guess this may not be an issue as most folks are not using ActiveRecord outside of Rails, but until there''s a better ORM for Ruby I think more and more people will want to do so. Let me know if there''s anything I can do to assist. Greg On Mar 6, 2006, at 6:30 AM, Tom Ward wrote:> On 3/3/06, Greg Lappen <greg@lapcominc.com> wrote: >> This may have gotten lost at the bottom of my email re: another topic >> so I''m repeating it again..... >> >> How about that connection pooling adaptor for Rails 1.1? >> >> There is a patch attached to http://dev.rubyonrails.org/ticket/2162 >> that''s been hanging out for a while, we''d love to see it make it into >> the core at some point. >> >> Many thanks, >> >> Greg > > I''ve never really tested it with the new connection keep-alive changes > made in 1.0 (or the additional changes in 1.1). I think it would be > best to adapt into a plugin that works against 1.1, then think about > integrating into the core for 1.2 (which would give us time to > refactor the ActiveRecord connection management code). I''ve got a few > days off work at the end of the week, and a number of > enhancements/plugins that need work on. I''ll add this to the list. > > Tom > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core
On 3/6/06, Greg Lappen <greg@lapcominc.com> wrote:> I had the same thought after I requested this to be in Rails 1.1, but > its not clear how plugins would work if we were using ActiveRecord > outside of a Rails application.You can create rails applications that don't use certain components (such as ActionPack, etc) but still run environment.rb, in which case plugins still work. It's an approach I've used successfully for a distributed job queue. I'm not sure it's how other people do things though.> Let me know if there's anything I can do to assist.Thanks. My plan is to look through the code, try and run it against trunk (fixing issues along the way, obviously) and then turn it into a plugin. If I have any problems I'll let you know. Also, when I've finished it'd be good to have another pair of eyes review and test it. Tom _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
How about http://dev.rubyonrails.org/ticket/3837 Add :dependent => :protect to has_many association (like ON DELETE RESTRICT). It''s really simple and I think it completes :dependent features to be like the FOREIGN KEY Constraints of the DBMS. Patch is minor and simple, and includes a test case. I''ve also tagged the bug appropriately. Thank you, Diego 2006/2/26, Michael Koziarski <michael@koziarski.com>:> Hey guys, > > We''re now beginning to finalise rails 1.1, and we need to make sure > that we don''t miss any heinous bugs. While we''ll all be giving the > list a once over, we''re only human and we''re likely to miss things. > > So, if you have any tickets which you think need to be addressed, > please bring them up in this thread, or add a keyword of > needs_review. We''re pretty keen on pushing out a 1.1 release pretty > soon, but we also want to get all the nasty bugs. > > -- > Cheers > > Koz > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
Am Sonntag, den 26.02.2006, 16:16 -0500 schrieb Kent Sibilev:> Ruby 1.8.4 comes with soap4r 1.5.5. With this version of soap4r > actionwebservice is completely broken. Any soap rpc call which returns > a value results with ''can''t modify frozen object'' exception. > > There is a ticket open for this problem http://dev.rubyonrails.org/ticket/2553 > > There are several proposed fixes for this problem. I''ve attached my > own solution which doesn''t require patching of soap4r classes. > > This is stop-ship problem I think. Can somebody take a look?Kents solution works fine for me. +1 for this bugfix. -- Norman Timmler http://blog.inlet-media.de
The patch has been applied to the trunk already. -- Kent On 3/8/06, Norman Timmler <lists@inlet-media.de> wrote:> Am Sonntag, den 26.02.2006, 16:16 -0500 schrieb Kent Sibilev: > > Ruby 1.8.4 comes with soap4r 1.5.5. With this version of soap4r > > actionwebservice is completely broken. Any soap rpc call which returns > > a value results with ''can''t modify frozen object'' exception. > > > > There is a ticket open for this problem http://dev.rubyonrails.org/ticket/2553 > > > > There are several proposed fixes for this problem. I''ve attached my > > own solution which doesn''t require patching of soap4r classes. > > > > This is stop-ship problem I think. Can somebody take a look? > > Kents solution works fine for me. +1 for this bugfix. > > -- > Norman Timmler > > http://blog.inlet-media.de >
Here''s a few patches I''d like to see make it in: http://dev.rubyonrails.org/ticket/3782 - Stop the MysqlAdapter crashing when views are present (ignoring is better than crashing). http://dev.rubyonrails.org/ticket/4108 - Alias the STI table to the name of the association. Say Nationality uses sti (class Nationality < NamedItem), you can do Person.find(:all, :include => :nationality, :order => ''nationality.name''), rather than Person.find(:all, :include => :nationality, :order => ''named_items.name''). Especially useful if you''re including multiple STIs that share the same table. http://dev.rubyonrails.org/ticket/3677 - Should definitely be fixed for 1.1. Currently, any <attribute>? methods the user writes will be overridden by the AR default. -Jonathan.
> So, if you have any tickets which you think need to be addressed, > please bring them up in this thread, or add a keyword of > needs_review. We''re pretty keen on pushing out a 1.1 release pretty > soon, but we also want to get all the nasty bugs.Today I started developing a new app from the trunk to get a feel of the new stuff. I''ve run into some really really trivial issues (documentation basically) and patched them. It wouldn''t hurt to have these in 1.1 and they are pretty safe to apply: [PATCH] use cleanpath of config file in lighttpd server script http://dev.rubyonrails.org/ticket/4203 [PATCH] Change file name in example in USAGE for migration generators http://dev.rubyonrails.org/ticket/4209 [PATCH] update name of sessions table rake task in environment.rb comments http://dev.rubyonrails.org/ticket/4210 I also have this old pet peeve which I see has not been patched yet. I updated my patch against the current trunk. Here''s to hoping that it gets in: [PATCH] HashWithIndifferentAccess fails to .delete(:sym) http://dev.rubyonrails.org/ticket/2176 And lastly there''s this. I haven''t tested it against the current trunk. I wonder if maybe this should be made into a plugin or if it belongs in rails. [PATCH] Stylesheet auto linker http://dev.rubyonrails.org/ticket/1859
On 2/26/06, Michael Koziarski <michael@koziarski.com> wrote:> We''re now beginning to finalise rails 1.1, and we need to make sure > that we don''t miss any heinous bugs. While we''ll all be giving the > list a once over, we''re only human and we''re likely to miss things. > > So, if you have any tickets which you think need to be addressed, > please bring them up in this thread, or add a keyword of > needs_review. We''re pretty keen on pushing out a 1.1 release pretty > soon, but we also want to get all the nasty bugs.#4125 is simple and somewhat important, as it pushes all the PostgreSQL tests (as of a few days ago) to green and adds a check for a regression that happens with the ruby-postgres snapshot gem. Thanks, -- Nathaniel Talbott <:((><
Ticket #3692. Major bug with has_and_belongs_to_many relations. Michael Koziarski wrote:> Hey guys, > > We''re now beginning to finalise rails 1.1, and we need to make sure > that we don''t miss any heinous bugs. While we''ll all be giving the > list a once over, we''re only human and we''re likely to miss things. > > So, if you have any tickets which you think need to be addressed, > please bring them up in this thread, or add a keyword of > needs_review. We''re pretty keen on pushing out a 1.1 release pretty > soon, but we also want to get all the nasty bugs. > > -- > Cheers > > Koz > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >-- Charles Dupont Computer System Analyst School of Medicine Department of Biostatistics Vanderbilt University
I'd like one (1) moon, and at least three to four stars, depending on density and luminosity. Oh, and a bagel. -Kyle _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
The tickets currently ''highlighted'' for extra review by the core team are in the following report: http://dev.rubyonrails.org/report/19 If your favourite ticket isn''t on that list, please add the needs_review keyword so we can have a look. If one of the core team removes the keyword, don''t take it personally. I realise I said you could raise the tickets in this thread, but it got really big, really quickly. -- Cheers Koz
On Sat, Mar 04, 2006 at 04:12:53PM -0600, John Sheets wrote:> On Mar 4, 2006, at 3:58 PM, Keegan Quinn wrote: > >On Wed, Mar 01, 2006 at 10:35:14PM -0600, John Sheets wrote: > >>I don''t personally have the resources to set up an automated system > >>with access to a Sybase database, but I''ll certainly keep up to date > >>with trunk and frequently run those unit tests manually. Perhaps > >>there''s a good Samaritan out there somewhere...? > > > >I was just looking into setting something like this up, but it > >appears that Sybase is very much not open source, and it''s not at all > >obvious to me after a little bit of research which of their "demo" > >products I would want to download to just run a database, or whether > >a "demo" product would even allow me to accomplish this. > > > >Any suggestions? > > Sure. The version I''ve used for all my Rails testing so far is at: > > http://www.sybase.com/ase_1252devel > > Free to download and use for development, not hobbled at all, and no > sunset clause. I''m sure it''d have to be for personal use only.Well, I downloaded it and have attempted to get it installed twice now. It just isn''t working for me. I''m not able to spend any more time on trying to figure out why, unfortunately. Hopefully someone else can help out with this. Good luck. -- Keegan Quinn <keegan@thebasement.org> CEO, Producer the basement productions http://www.thebasement.org _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
> If your favourite ticket isn''t on that list, please add the > needs_review keyword so we can have a look. If one of the core team > removes the keyword, don''t take it personally.If the keyword is removed by anonymous do we just assume it''s a core member?