[Rails-core] Rails 1.1 is coming
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
Re: [Rails-core] Rails 1.1 is coming
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 ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Rails 1.1 is coming
> 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. -- 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] Re: Rails 1.1 is coming
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
Re: [Rails-core] Re: Rails 1.1 is coming
> 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 ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Re: Rails 1.1 is coming
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
Re: [Rails-core] Rails 1.1 is coming
I am voting for tickets #3811To 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 <[EMAIL PROTECTED]> wrote: Hey guys,We're now beginning to finalise rails 1.1, and we need to make surethat we don't miss any heinous bugs. While we'll all be giving thelist 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 ofneeds_review. We're pretty keen on pushing out a 1.1 release prettysoon, but we also want to get all the nasty bugs. --CheersKoz___Rails-core mailing listRails-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
Re: [Rails-core] Rails 1.1 is coming
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Re: Rails 1.1 is coming
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 ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] ActionWebService targeted for unbundling by 1.1
The creator of ActionWebService, Leon Breedt, seems to be on a
long-term vacation from Rails work and no one else in the core group
is working with this framework. So its not a good fit to be in core
when none of core is deeply familiar with it. On top of that, it's not
one of those things that "most people need most of the time", so
that's another strike.
With those charges, we want to unbundle AWS from the core distribution
of Rails. That sounds dramatic, but it's really just a 1 line change
in the Rakefile of railties:
- s.add_dependency('actionwebservice', '= 1.0.0' + PKG_BUILD)
...and if you actually used AWS, it would be easy as pie to keep
installing it with:
gem install actionwebservice
So this is a very likely thing to happen for 1.1. If you have any
concerns as to why it shouldn't go down like that, please voice your
opinion. If you want to take the lead on maintaining AWS, please speak
up too (that won't stop our intentions to unbundle, though).
--
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] Namespaced actions in Rails 1.1?
So Rake 0.7 allows for namespaces in actions. It's mighty nice. rake db:schema:import and rake db:schema:export whips the llama's ass on db_schema_import/export. It makes it much to organize tasks. Yay, yay. But how does this relate to backwards compatibility? What would happen if the next release changed all the tasks over to be namespaced? Who and want would break? I'm coming up short with ideas on where it would be a problem, but I'd like to hear if others have some dependencies on the specific rake names. -- 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
Re: [Rails-core] Namespaced actions in Rails 1.1?
Include a backwards-compatability task library with the old names that just delegates to the new modularized ones? Might be overkill if it's not going to be a serious problem but it's relatively easy to do. On 2/27/06, David Heinemeier Hansson <[EMAIL PROTECTED]> wrote: > So Rake 0.7 allows for namespaces in actions. It's mighty nice. rake > db:schema:import and rake db:schema:export whips the llama's ass on > db_schema_import/export. It makes it much to organize tasks. Yay, yay. > > But how does this relate to backwards compatibility? What would happen > if the next release changed all the tasks over to be namespaced? Who > and want would break? I'm coming up short with ideas on where it would > be a problem, but I'd like to hear if others have some dependencies on > the specific rake names. > -- > 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
Re: [Rails-core] Namespaced actions in Rails 1.1?
> Include a backwards-compatability task library with the old names that > just delegates to the new modularized ones? Might be overkill if it's > not going to be a serious problem but it's relatively easy to do. The problem is what a mess that'll make of "rake -T". So before making such a mess, I want to have some good reasons for doing so ;) -- 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] Don't use "and" and "or" for boolean tests, instead always use "&&" and "||"
This is now Tha Law on all new patches. I documented this on the style guide at dev.rubyonrails.org. Reasoning: Everyone always forget the different binding rules of "and" and "or", which has resulted in bugs before. And it looks inconsistent with the rest of the code base. -- 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
Re: [Rails-core] Namespaced actions in Rails 1.1?
Hi, Anyone who has modified the flow of tasks when building rail apps or who have built their own tasks that rely on rails tasks is going to be bitten. For example, almost all of my rails apps have something similar to the example below. Also - almost all of my custom tasks will depend upon rails tasks by name and they will probably break. Adding a backwards portability layer layer will not really work in many circumstances (like example below) unless the new-style tasks invoke the old-style tasks to do the work which is just messy. However IMHO the benefit is worth the break as long as it is well documented in changelog. module Rake class Task def remove_prerequisite(task_name) name = task_name.to_s @prerequisites.delete(name) end end end Rake::Task.lookup(:test_units).remove_prerequisite(:prepare_test_database) Rake::Task.lookup(:test_functional).remove_prerequisite(:prepare_test_database) Rake::Task.lookup(:test_units).enhance([:environment]) Rake::Task.lookup(:test_functional).enhance([:environment]) On 2/27/06, David Heinemeier Hansson <[EMAIL PROTECTED]> wrote: > > Include a backwards-compatability task library with the old names that > > just delegates to the new modularized ones? Might be overkill if it's > > not going to be a serious problem but it's relatively easy to do. > > The problem is what a mess that'll make of "rake -T". So before making > such a mess, I want to have some good reasons for doing so ;) > -- > 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 > -- Cheers, Peter Donald Blog: http://www.RealityForge.org ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Namespaced actions in Rails 1.1?
On 2/26/06, David Heinemeier Hansson <[EMAIL PROTECTED]> wrote: > So Rake 0.7 allows for namespaces in actions. It's mighty nice. rake > db:schema:import and rake db:schema:export whips the llama's ass on > db_schema_import/export. It makes it much to organize tasks. Yay, yay. > > But how does this relate to backwards compatibility? What would happen > if the next release changed all the tasks over to be namespaced? Who > and want would break? I'm coming up short with ideas on where it would > be a problem, but I'd like to hear if others have some dependencies on > the specific rake names. Perhaps a better question might be: "Is this change likely to get easier or harder after Rails 1.1?" If it's going to happen, it should probably happen before too many more users reference the old task names. Presumably SwitchTower would break, but the fix shouldn't exactly be rocket science. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Namespaced actions in Rails 1.1?
> Include a backwards-compatability task library with the old names that > just delegates to the new modularized ones? Might be overkill if it's > not going to be a serious problem but it's relatively easy to do. This is the way we'll go since I can make the old tasks not show up in rake -T, but they'll still be there. -- 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
Re: [Rails-core] ActionWebService targeted for unbundling by 1.1
David Heinemeier Hansson wrote:
The creator of ActionWebService, Leon Breedt, seems to be on a
long-term vacation from Rails work
Is he alive? Does anyone know if he's OK?
and no one else in the core group
is working with this framework. So its not a good fit to be in core
when none of core is deeply familiar with it.
I agree that for something to be in core it must be maintainable by
known maintainers. I assume Leon fell into that category, without (I
guess) being in the core team.
> On top of that, it's not
one of those things that "most people need most of the time", so
that's another strike.
Do you know the figures here? Without daring to tread on the ground of
"is Rails enterprise-ready?" I would point out that being able to offer
functionality either through a Web UI or via a web service is a big
enterprise "tick in the box".
With those charges, we want to unbundle AWS from the core distribution
of Rails. That sounds dramatic, but it's really just a 1 line change
in the Rakefile of railties:
- s.add_dependency('actionwebservice', '= 1.0.0' + PKG_BUILD)
...and if you actually used AWS, it would be easy as pie to keep
installing it with:
gem install actionwebservice
So this is a very likely thing to happen for 1.1. If you have any
concerns as to why it shouldn't go down like that, please voice your
opinion. If you want to take the lead on maintaining AWS, please speak
up too (that won't stop our intentions to unbundle, though).
Personally, I believe that anything up to Rails 2.0 should respect the
commitment to "not break the Book (AWDR)". At the very least, there
should be a succession of versions that warn the user before something
actually breaks.
Perhaps you should go through the book and publish the "truck number"[1]
of each feature.
regards
Justin
[1] Truck Number - the number of people who would need to be run over by
a truck to render a given feature unviable.
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Namespaced actions in Rails 1.1?
On Feb 26, 2006, at 6:29 PM, David Heinemeier Hansson wrote: The problem is what a mess that'll make of "rake -T". So before making such a mess, I want to have some good reasons for doing so ;) I thought the Rails 1 series was supposed to maintain compatibility. Apart from being cool, what benefits to these changes bring to the _users_ of Rails? Dave ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Namespaced actions in Rails 1.1?
On 2/27/06, Dave Thomas <[EMAIL PROTECTED]> wrote: > Apart from being cool, what benefits to these changes bring to the > _users_ of Rails? So you're saying "cool" isn't a benefit in itself. ;-) (But of course, I agree, if it's not backwards compatible it shouldn't be done.) ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] ActionWebService targeted for unbundling by 1.1
> Is he alive? Does anyone know if he's OK? Leon's fine. He's just overworked at the dayjob. > I agree that for something to be in core it must be maintainable by > known maintainers. I assume Leon fell into that category, without (I > guess) being in the core team. Leon was in the core team, it's just that he hasn't had time to contribute in the meantime. > Do you know the figures here? Without daring to tread on the ground of > "is Rails enterprise-ready?" I would point out that being able to offer > functionality either through a Web UI or via a web service is a big > enterprise "tick in the box". Well ActionPack's REST support is pretty complete at present. But if someone's able to start fixing the show stoppers like these, then we can definitely continue to include it: http://dev.rubyonrails.org/ticket/2553 http://dev.rubyonrails.org/ticket/3567 etc. > Personally, I believe that anything up to Rails 2.0 should respect the > commitment to "not break the Book (AWDR)". At the very least, there > should be a succession of versions that warn the user before something > actually breaks. > > Perhaps you should go through the book and publish the "truck number"[1] > of each feature. It's not really a question of 'truck numbers' (nice phrase though), but rather that AWS is broken now, and noone has stepped up to the plate to take over maintenance. I'd definitely prefer to continue to include AWS in rails, at least until rails 2.0, but in it's current state, it's just too broken. If you're using AWS in production at present, please consider looking into the tickets and providing fixes. That's the best way to ensure that AWS stays in rails. > regards > >Justin > > [1] Truck Number - the number of people who would need to be run over by > a truck to render a given feature unviable. > ___ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > -- Cheers Koz ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Namespaced actions in Rails 1.1?
> So you're saying "cool" isn't a benefit in itself. ;-) > > > (But of course, I agree, if it's not backwards compatible it shouldn't be > done.) I agree too, and the change currently being proposed is backwards compatible for exactly this reason. David's rake -T concerns wouldn't be reason enough to break backwards compatibility, but it turns out that they can be satisfied anyway. -- Cheers Koz ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] ActionWebService targeted for unbundling by 1.1
On Sun, Feb 26, 2006 at 05:40:51PM -0600, David Heinemeier Hansson wrote:
> The creator of ActionWebService, Leon Breedt, seems to be on a
> long-term vacation from Rails work and no one else in the core group
> is working with this framework. So its not a good fit to be in core
> when none of core is deeply familiar with it. On top of that, it's not
> one of those things that "most people need most of the time", so
> that's another strike.
>
> With those charges, we want to unbundle AWS from the core distribution
> of Rails. That sounds dramatic, but it's really just a 1 line change
> in the Rakefile of railties:
>
> - s.add_dependency('actionwebservice', '= 1.0.0' + PKG_BUILD)
>
> ...and if you actually used AWS, it would be easy as pie to keep
> installing it with:
>
> gem install actionwebservice
>
> So this is a very likely thing to happen for 1.1. If you have any
> concerns as to why it shouldn't go down like that, please voice your
> opinion. If you want to take the lead on maintaining AWS, please speak
> up too (that won't stop our intentions to unbundle, though).
> --
> 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
We'd be happy to take on ActionWebServices, as we use it daily in
much of our business process. I had run into the issues in 1.8.4
but decided the benefits of AWS made 1.8.2 adequate for now. We
were unaware there was a maintainer vacancy. The 'we' i'm referring
to are myself, trey dempsey, and kevin berry (deathsyn).
--
TJ Vanderpoel GCIA,GCIH
[EMAIL PROTECTED]
pgpwvzeKViL5p.pgp
Description: PGP signature
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] ActionWebService targeted for unbundling by 1.1
> We'd be happy to take on ActionWebServices, as we use it daily in > much of our business process. I had run into the issues in 1.8.4 > but decided the benefits of AWS made 1.8.2 adequate for now. We > were unaware there was a maintainer vacancy. The 'we' i'm referring > to are myself, trey dempsey, and kevin berry (deathsyn). Awesome, if you have a look at http://dev.rubyonrails.org/report/1 you can see a few critical bugs which need fixing. If you can attach patches and let us know, we'll get them applied. -- Cheers Koz ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] ActionWebService targeted for unbundling by 1.1
On Mon, Feb 27, 2006 at 04:27:59PM +1300, Michael Koziarski wrote: > > We'd be happy to take on ActionWebServices, as we use it daily in > > much of our business process. I had run into the issues in 1.8.4 > > but decided the benefits of AWS made 1.8.2 adequate for now. We > > were unaware there was a maintainer vacancy. The 'we' i'm referring > > to are myself, trey dempsey, and kevin berry (deathsyn). > > Awesome, if you have a look at http://dev.rubyonrails.org/report/1 > you can see a few critical bugs which need fixing. If you can attach > patches and let us know, we'll get them applied. > > > -- > Cheers > > Koz > ___ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core We're on it -- TJ Vanderpoel GCIA,GCIH [EMAIL PROTECTED] pgpG1Hr5PTEsG.pgp Description: PGP signature ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Namespaced actions in Rails 1.1?
> I thought the Rails 1 series was supposed to maintain compatibility. See the decision from 1:30 minutes ago. The old tasks will still work, "rake -T" will just only show the new names. > Apart from being cool, what benefits to these changes bring to the > _users_ of Rails? Better coherence in the face of a larger number of tasks. This will allow SwitchTower to more easily populate the remote: namespace with all its tasks instead of just a cherry-pick and then remote_exec for the rest. So the same benefit that namespaces always bring: Order to the madness. -- 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
Re: [Rails-core] Re: Rails 1.1 is coming
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? ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] EdgeRails, rename_table doesn't change the sequence name
With regards to Rails 1.1, this may be a new or old error, I wasn't able to
find it in Trac.
Patch: http://dev.rubyonrails.org/ticket/3975
Basically, when I try to rename a table, the sequence names are not updated.
connection.rename_table('banannas', 'banannas_pies')
Table Name: bananna_pies
column | default value
--
id | nextval('public.banannas_id_seq'::text)
-Nb
~
Nathaniel S. H. Brown http://nshb.net
~
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] #3005 - Prevent duplicate names (needs review for 1.1)
Hi ! I was taking another look at http://dev.rubyonrails.org/ticket/3005 I reread the discussion we had here in late December: http://thread.gmane.org/gmane.comp.lang.ruby.rails.core/41 The patch still applies cleanly. After removing the exceptions we had talked about, now I have another problem: $ rake test_mysql (in D:/rails-trunk/activerecord) ... Using native MySQL ./test/../lib/active_record/reflection.rb:61:in `guard_against_already_used_method_name': `parent' is the name of an existing method in TreeMixin. You will have to rename your association. (ActiveRecord::Reflection::ReflectionNameAlreadyTaken) from ./test/../lib/active_record/reflection.rb:16:in `create_reflection' from ./test/../lib/active_record/associations.rb:917:in `create_belongs_to_reflection' from ./test/../lib/active_record/associations.rb:469:in `belongs_to' from ./test/../lib/active_record/acts/tree.rb:47:in `acts_as_tree' from ./test/fixtures/mixin.rb:6 from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require__' from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from ./test/../lib/../../activesupport/lib/active_support/dependencies.rb:149:in `require' from ./test/mixin_nested_set_test.rb:3 from C:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.0/lib/rake/rake_test_loader.rb:5:in `load' from C:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.0/lib/rake/rake_test_loader.rb:5 from C:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.0/lib/rake/rake_test_loader.rb:5:in `each' from C:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.0/lib/rake/rake_test_loader.rb:5 rake aborted! So now, we can't even create a parent method - it already exists: # activesupport/lib/active_support/dependencies.rb:81 class Module #:nodoc: # Rename the original handler so we can chain it to the new one alias :rails_original_const_missing :const_missing def parent ... end end Boohoo ! I updated the patch, and here's the list of methods I guard against: methods = active_record.instance_methods methods += ActiveRecord::Base.methods methods -= Object.methods methods.uniq! methods -= %w(name type) See the initial thread on why we need to keep ActiveRecord::Base class methods in the list. I think this would be a good patch to include in 1.1. Bye ! -- François Beausoleil http://blog.teksol.info/ ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Added tests to #3270 :group is incorrectly reported as being an unknown key
http://dev.rubyonrails.org/ticket/3270 I added a bunch of tests. Need someone to review and apply. Bye ! -- François Beausoleil http://blog.teksol.info/ ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Rails 1.1 is coming
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? ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Rails 1.1 is coming
> 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
Re: [Rails-core] ActionWebService targeted for unbundling by 1.1
TJ Vanderpoel wrote: We're on it Not that we're voting, but I'd really like to see AWS remain a core part of Rails. We're also about to roll out some significant production use. I haven't been the dev on that part of our app, but I know we've got a local patch applied to make it work for us. I'll be happy to help clear up the remaining issues, at the very least by testing any patches you 3 are able to provide. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
