Custom Search
|
Date: December 31, 2006
From: "Michael Koziarski" <michael@xxxxxxxxxxxxx>
In-reply-to:
<4b430c8f0612310828n36b79269q286116c31c3f4b99@xxxxxxxxxxxxxx>
References:
<1167496474.441721.69240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <9258D900-2931-4BFF-A14E-CEFAB1D1B8EF@xxxxxxxxxxxxxx> <5CDE7C3D-F1E5-443E-B6ED-9578620D6F5B@xxxxxxxxxxxxxxxxxx> <4b430c8f0612302037x1fe5b636yc2c33fcbb804bd89@xxxxxxxxxxxxxx> <1167570617.568476.15260@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <4b430c8f0612310828n36b79269q286116c31c3f4b99@xxxxxxxxxxxxxx>
The forked process *does* have access to the whole rails environment, and it's instant, but you have to re-connect to the DB and re-open any files (like logs), if I recall correctly. (We were looking at this method as a fast way of spawning listeners, but it got too tricky) It would likely be trivial to move the time-intensive code to its own class and just call that in the fork.
I've found it much *much* easier to start a drb worker like background drb does, than try to deal with forking the rails process. If you use a work queue (rinda, or model based) and you can shift expensive processing into another process relatively smoothly. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 31, 2006
From: "DHH" <david.heinemeier@xxxxxxxxx>
In-reply-to:
<3cbaf1c80612300845r29ebacbegfa4e0ee4e2ad8f14@xxxxxxxxxxxxxx>
References:
<3cbaf1c80612300845r29ebacbegfa4e0ee4e2ad8f14@xxxxxxxxxxxxxx>
Has there been any recently published info about where the Rails core is headed after the release of Rails 1.2. At some point in the past I read that the next version will be Rails 2.0 and some current features will change from deprecated to obsolete and components and pagination will be removed. Any other major features that will disappear? Is Rails 2.0 all about cleanup or is there already another big change like RJS, migrations, or RESTful routes already in the works?
There has not been published anything, no. Mostly because it's not set in stone. Heck, it's not even draw in the sand. Our current intentions are to get 1.2 delivered. Once that has happened, we'll start thinking more seriously about 2.0. I'd expect the current fuzzy ideas will be presented in some form at RailsConf 07. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 31, 2006
From: Courtenay <court3nay@xxxxxxxxx>
In-reply-to:
<1167570617.568476.15260@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167496474.441721.69240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <9258D900-2931-4BFF-A14E-CEFAB1D1B8EF@xxxxxxxxxxxxxx> <5CDE7C3D-F1E5-443E-B6ED-9578620D6F5B@xxxxxxxxxxxxxxxxxx> <4b430c8f0612302037x1fe5b636yc2c33fcbb804bd89@xxxxxxxxxxxxxx> <1167570617.568476.15260@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
On 12/31/06, Mark Reginald James <mrj@xxxxxxxxxxxxxx> wrote:
> What you mean to say is, no, you shouldn't do it that way :) since > it'll tie up the controller. I just thought that for something that doesn't take too long, the simplicity of just adding a "yield" to the action code is attractive. > You could fork off a process and detach it if you're not interested in > the results. Take a look at the daemonize library. Thanks Courtenay. This would be easier to manage than a pipe to a DRb processor. Such a forked process would however have to have access to the whole Rails environment, so I would either have to fork a script/runner (too slow), or have the forked process make a local controller call, which would tie up the request handlers even more unless you could set the web-server to serve such requests with a lower priority.
The forked process *does* have access to the whole rails environment, and it's instant, but you have to re-connect to the DB and re-open any files (like logs), if I recall correctly. (We were looking at this method as a fast way of spawning listeners, but it got too tricky) It would likely be trivial to move the time-intensive code to its own class and just call that in the fork. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 31, 2006
From: "Mark Reginald James" <mrj@xxxxxxxxxxxxxx>
References:
<1167496474.441721.69240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <9258D900-2931-4BFF-A14E-CEFAB1D1B8EF@xxxxxxxxxxxxxx> <5CDE7C3D-F1E5-443E-B6ED-9578620D6F5B@xxxxxxxxxxxxxxxxxx> <4b430c8f0612302037x1fe5b636yc2c33fcbb804bd89@xxxxxxxxxxxxxx>
Courtenay wrote:
What you mean to say is, no, you shouldn't do it that way :) since it'll tie up the controller.
I just thought that for something that doesn't take too long, the simplicity of just adding a "yield" to the action code is attractive.
You could fork off a process and detach it if you're not interested in the results. Take a look at the daemonize library.
Thanks Courtenay. This would be easier to manage than a pipe to a DRb processor. Such a forked process would however have to have access to the whole Rails environment, so I would either have to fork a script/runner (too slow), or have the forked process make a local controller call, which would tie up the request handlers even more unless you could set the web-server to serve such requests with a lower priority. -- We develop, watch us RoR, in numbers too big to ignore. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 31, 2006
From: "Mislav Marohnić" <mislav.marohnic@xxxxxxxxx>
In-reply-to:
<1167496358.265402.117680@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167496358.265402.117680@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
This, it seems, is intended to pull non commented lines out of
environment.rb.
Although a trivial point, this regexp misses indented # and so still
includes most of the commented lines.
Date: December 31, 2006
From: Tim Lucas <t.lucas@xxxxxxxxxxxxxx>
In-reply-to:
<4b430c8f0612302037x1fe5b636yc2c33fcbb804bd89@xxxxxxxxxxxxxx>
References:
<1167496474.441721.69240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <9258D900-2931-4BFF-A14E-CEFAB1D1B8EF@xxxxxxxxxxxxxx> <5CDE7C3D-F1E5-443E-B6ED-9578620D6F5B@xxxxxxxxxxxxxxxxxx> <4b430c8f0612302037x1fe5b636yc2c33fcbb804bd89@xxxxxxxxxxxxxx>
On 31/12/2006, at 3:37 PM, Courtenay wrote:
What you mean to say is, no, you shouldn't do it that way :) since it'll tie up the controller. You could fork off a process and detach it if you're not interested in the results. Take a look at the daemonize library.
doh! I do this in multiple places already... silly me. Best to shut my trap until the new years detox.
Happy New Years all. A big thankyou to all those who have contributed to Rails in 2006!
-- tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 31, 2006
From: Courtenay <court3nay@xxxxxxxxx>
In-reply-to:
<5CDE7C3D-F1E5-443E-B6ED-9578620D6F5B@xxxxxxxxxxxxxxxxxx>
References:
<1167496474.441721.69240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <9258D900-2931-4BFF-A14E-CEFAB1D1B8EF@xxxxxxxxxxxxxx> <5CDE7C3D-F1E5-443E-B6ED-9578620D6F5B@xxxxxxxxxxxxxxxxxx>
On 12/30/06, Josh Susser <josh@xxxxxxxxxxxxxxxxxx> wrote:
>> Is there any interest in allowing controller methods to do >> post-response processing? > > I'm pretty sure you can just do the following: > > def show > # fetch me something to render > render > # do some long operation > end Yes, you can do that, but it won't render until the method returns. A pretty simple way to accomplish this is to use BackgrounDRb to do the work in another process.
What you mean to say is, no, you shouldn't do it that way :) since it'll tie up the controller. You could fork off a process and detach it if you're not interested in the results. Take a look at the daemonize library. Also check out this gratuitous self-link at http://blog.caboo.se/articles/2006/10/14/premcache-caching-and-precaching-with-memcached if that's the sort of thing that floats your boat. Courtenay http://blog.caboo.se --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 31, 2006
From: Josh Susser <josh@xxxxxxxxxxxxxxxxxx>
In-reply-to:
<9258D900-2931-4BFF-A14E-CEFAB1D1B8EF@xxxxxxxxxxxxxx>
References:
<1167496474.441721.69240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <9258D900-2931-4BFF-A14E-CEFAB1D1B8EF@xxxxxxxxxxxxxx>
On Dec 30, 2006, at 7:06 PM, Tim Lucas wrote:
On 31/12/2006, at 3:34 AM, Mark Reginald James wrote:Is there any interest in allowing controller methods to do post-response processing?I'm pretty sure you can just do the following: def show # fetch me something to render render # do some long operation end
Yes, you can do that, but it won't render until the method returns.A pretty simple way to accomplish this is to use BackgrounDRb to do the work in another process.
-- Josh Susser http://blog.hasmanythrough.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 31, 2006
From: Tim Lucas <t.lucas@xxxxxxxxxxxxxx>
In-reply-to:
<1167496474.441721.69240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167496474.441721.69240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On 31/12/2006, at 3:34 AM, Mark Reginald James wrote:
Is there any interest in allowing controller methods to do post-response processing?
I'm pretty sure you can just do the following: def show # fetch me something to render render # do some long operation end -- tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 31, 2006
From: Luke Redpath <contact@xxxxxxxxxxxxxxxxx>
In-reply-to:
<1167496358.265402.117680@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167496358.265402.117680@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Tonypm - good catch. Perhaps you should submit this as a tiny patch to the Rails trac with some unit tests.
Cheers Luke On 30 Dec 2006, at 16:32, tonypm wrote:
Whilst looking into some of the initialization code, I came across thisat line 20 in rails-1.1.6/environments/boot.rb environment_without_comments = IO.readlines(File.dirname(__FILE__) + '/environment.rb').reject { |l| l =~ /^#/ }.join This, it seems, is intended to pull non commented lines out of environment.rb. Although a trivial point, this regexp misses indented # and so still includes most of the commented lines. Would this be better as? .......reject { |l| l =~ /^\s*#/ }.joinAlso in the subsequent line, [^#] would seem to serve no purpose sincea line starting with # would have been rejected.. Tonypm >
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 31, 2006
From: Justin Forder <justin@xxxxxxxxxxxxxxxxx>
In-reply-to:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Esad Hajdarevic wrote:
Hi! As you probably know, every time you run the tests, the whole rails environment is loaded, which alone takes about 20 seconds on a empty rails project for me. I was thinking of running some kind of test server (using DRb) in the background that loads the environment once, and then just communicates with the rake task. It would basically reload the testcase files, run them and and output the results back to the rake task. No reload environment on every test run. Even webserver could be used, so we could have built-in controller at /test that would allow developers to run the tests in browser! Any ideas or thought why this shouldn't be posssible or why it isn't already done?
This interview with Ryan Davis, at InfoQ, suggests that ZenTest [1] will get this capability:
http://www.infoq.com/interviews/Ryan-Davis"Q: And you don't have the cost of starting the Ruby executable in the Rails environment every time you want to run a test?
A: No, you still do have that. What we didn't want to do at the time was we didn't want to have ourselves accidentally infect our results and so we're shelling out and invoking the right test files, sometimes with -n in order to name what particular test case we want, but we're still invoking that, we still get that cost. But we're working on tools to address that as well. We're building a tool that will actually be hooked-in automatically from autotest that will load up config/environment.rb, which is the bootstrap mechanism for Rails and incurs the most costs for loading much of anything. It will load all that stuff up, get everything initialized, set up the paths and everything and then open up a socket with an interface to interact with it, saying "I want you to run this class test with this test method and it will fork so that you've copied your cost of initializing and run just those things so you don't have that cost anymore. Basically we've seen a 10x improvement in speed."
regards Justin Forder [1] http://www.zenspider.com/ZSS/Products/ZenTest/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 31, 2006
From: Luke Redpath <contact@xxxxxxxxxxxxxxxxx>
In-reply-to:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
If you use RSpec, it has an rspec_rails runner that uses DRb to run load the environment one in the background.
I've not played around with it so I'm not certain how stable it is - but even if you aren't using RSpec it might be worth taking a look around the source as a starting point for something similar for Test::Unit (although I'd be surprised if something isn't already out there).
Cheers Luke On 30 Dec 2006, at 20:12, Esad Hajdarevic wrote:
Hi! As you probably know, every time you run the tests, the whole rails environment is loaded, which alone takes about 20 seconds on a empty rails project for me. I was thinking of running some kind of test server (using DRb) in the background that loads the environment once, and then just communicates with the rake task. It would basically reload the testcase files, run them and and output the results back to the rake task. No reload environment on every test run. Even webserver could be used, so we could have built-in controller at /test that would allow developers to run the tests in browser! Any ideas or thought why this shouldn't be posssible or why it isn't already done? Greetings, Esad >
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 30, 2006
From: "tonypm" <tonypmartin@xxxxxxxxxxx>
Whilst looking into some of the initialization code, I came across this
at line 20 in
rails-1.1.6/environments/boot.rb
environment_without_comments = IO.readlines(File.dirname(__FILE__) +
'/environment.rb').reject { |l| l =~ /^#/ }.join
This, it seems, is intended to pull non commented lines out of
environment.rb.
Although a trivial point, this regexp misses indented # and so still
includes most of the commented lines.
Would this be better as?
.......reject { |l| l =~ /^\s*#/ }.join
Also in the subsequent line, [^#] would seem to serve no purpose since
a line starting with # would have been rejected..
Tonypm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
Date: December 30, 2006
From: "Mark Reginald James" <mrj@xxxxxxxxxxxxxx>
Hi, Is there any interest in allowing controller methods to do post-response processing? This would be useful where some time-consuming statistic or index processing should be done after the response has been sent so as not to delay a response that does not depend on that processing. This could be implemented by allowing the action method to yield to the process method which in turn yields to a dispatcher CGI out call. The yield could either be called explicitly or done by a call to render. If there's a concern about tying up Web handlers, what sort of limit should be placed on the processing time before one should instead set up an asynchronous task to do such work? -- We develop, watch us RoR, in numbers too big to ignore. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 30, 2006
From: "abdul rahman" <abouihsaan@xxxxxxxxx>
Hi guys, I have a problem with counter cache on the rails trunk version. I have the following test case: doc = Document.new assert doc.bookmarks.create() assert doc.save! assert doc.reload assert_equal 1, doc.bookmarks_count But doc.save! sets the bookmarks_count column on document to 0 (after it has been raised by bookmarks.create) the following queries can be found in log: 1. SELECT * FROM documents WHERE (documents.id = 1) 2. UPDATE documents SET bookmarks_count = bookmarks_count + 1 WHERE (id= 1) 3. COMMIT
4. BEGIN 5. SELECT * FROM bookmarks WHERE (bookmarks.bookmarkable_id = 1 AND bookmarks.bookmarkable_type = 'Document') 6. UPDATE documents SET `content` = NULL, `bookmarks_count` = 0, `name` = NULL WHERE id = 1 7. COMMIT quite frustrating... :S My models: -- Document.rb: class Document < ActiveRecord::Base has_many :bookmarks, :as => :bookmarkable, :dependent => :destroy end -- Bookmark.rb: class Bookmark < ActiveRecord::Base # associations belongs_to :bookmarkable, :polymorphic => true, :counter_cache => "bookmarks_count" end --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 30, 2006
From: "Josh Peek" <josh@xxxxxxxxxxxx>
Continuing from http://groups.google.com/group/rubyonrails-core/browse_frm/thread/f6a655492e571aa2 This is the second time this plugin loading patch was committed and is still broken. I can only reproduce the error running in production mode. Can changeset #5738 please be revert (again). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 30, 2006
From: "Dan Manges" <daniel.manges@xxxxxxxxx>
In-reply-to:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Esad Hajdarevic wrote:
Any ideas or thought why this shouldn't be posssible or why it isn't already done?
RSpec does this with 'drbspec': http://rspec.rubyforge.org/documentation/rails/runners.html "To speed things up, RSpec on Rails installs a daemon that loads the local Rails app and listens for incoming connections via DRb." Dan Manges --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 30, 2006
From: "Mislav Marohnić" <mislav.marohnic@xxxxxxxxx>
In-reply-to:
<f53e6950612301223m17236377t2da33bc7d57a34f@xxxxxxxxxxxxxx>
References:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <f53e6950612301223m17236377t2da33bc7d57a34f@xxxxxxxxxxxxxx>
tddmate did something like this. I'm not sure if it works against the
latest versions of Rails, but it'd be worth a look:
http://www.artima.com/forums/flat.jsp?forum=123&thread=144337
Date: December 30, 2006
From: "Mislav Marohnić" <mislav.marohnic@xxxxxxxxx>
In-reply-to:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Any ideas or thought why this shouldn't be posssible or why it isn't
already done?
Date: December 30, 2006
From: "Kevin Clark" <kevin.clark@xxxxxxxxx>
In-reply-to:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167509546.175784.206510@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
tddmate did something like this. I'm not sure if it works against the latest versions of Rails, but it'd be worth a look: http://www.artima.com/forums/flat.jsp?forum=123&thread=144337 On 12/30/06, Esad Hajdarevic <esad@xxxxxxx> wrote:
Hi! As you probably know, every time you run the tests, the whole rails environment is loaded, which alone takes about 20 seconds on a empty rails project for me. I was thinking of running some kind of test server (using DRb) in the background that loads the environment once, and then just communicates with the rake task. It would basically reload the testcase files, run them and and output the results back to the rake task. No reload environment on every test run. Even webserver could be used, so we could have built-in controller at /test that would allow developers to run the tests in browser! Any ideas or thought why this shouldn't be posssible or why it isn't already done? Greetings, Esad >
-- Kevin Clark http://glu.ttono.us --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 30, 2006
From: "Esad Hajdarevic" <esad@xxxxxxx>
Hi! As you probably know, every time you run the tests, the whole rails environment is loaded, which alone takes about 20 seconds on a empty rails project for me. I was thinking of running some kind of test server (using DRb) in the background that loads the environment once, and then just communicates with the rake task. It would basically reload the testcase files, run them and and output the results back to the rake task. No reload environment on every test run. Even webserver could be used, so we could have built-in controller at /test that would allow developers to run the tests in browser! Any ideas or thought why this shouldn't be posssible or why it isn't already done? Greetings, Esad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 30, 2006
From: "Peter Michaux" <petermichaux@xxxxxxxxx>
Hi, Has there been any recently published info about where the Rails core is headed after the release of Rails 1.2. At some point in the past I read that the next version will be Rails 2.0 and some current features will change from deprecated to obsolete and components and pagination will be removed. Any other major features that will disappear? Is Rails 2.0 all about cleanup or is there already another big change like RJS, migrations, or RESTful routes already in the works? Thanks, Peter -- JavaScript for Rails: http://forkjavascript.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 29, 2006
From: Michael Schoen <schoenm@xxxxxxxxxxxxx>
"minam" made AR/Oracle happy again, thank you! http://dev.rubyonrails.org/changeset/5808 ------------------------------------------------------------------------ r5808 | minam | 2006-12-29 11:05:53 -0800 (Fri, 29 Dec 2006) | 2 lines try to appease the angry Oracle ------------------------------------------------------------------------ U activerecord/test/base_test.rb U activerecord/lib/active_record/base.rb Updated to revision 5808. Unit tests successful, 130 seconds. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 29, 2006
From: Michael Schoen <schoenm@xxxxxxxxxxxxx>
"minam" made AR/Oracle cry... http://dev.rubyonrails.org/changeset/5807 ------------------------------------------------------------------------ r5807 | minam | 2006-12-29 09:24:35 -0800 (Fri, 29 Dec 2006) | 2 lines make sure query attributes on custom fields works as it used to ------------------------------------------------------------------------ U activerecord/test/base_test.rb U activerecord/lib/active_record/base.rb Updated to revision 5807. 1) Failure: test_query_attribute_with_custom_fields(BasicsTest) [./test/base_test.rb:317]: <"1"> expected but was <1>. 1013 tests, 3886 assertions, 1 failures, 0 errors rake aborted! Command failed with status (1): [/usr/pkg/ruby184/bin/ruby -Ilib:test:test/...] (See full trace by running task with --trace) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: Julian Tarkhanov <listbox@xxxxxxxx>
In-reply-to:
<f4657cab0612280040r627a5664yac6925509e909e01@xxxxxxxxxxxxxx>
References:
<1167249273.626503.126730@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <f4657cab0612280040r627a5664yac6925509e909e01@xxxxxxxxxxxxxx>
On 12/28/06, DHH <david.heinemeier@xxxxxxxxx> wrote: We're inches away from pulling the trigger on RC2, which is the fast track (a few days, tops) to the final release. Please examine the latest from the branch and check if any of your pet blockers are still there. If so, shoot us a link to a ticket.
I would really appreciate http://dev.rubyonrails.org/ticket/4947 to be taken care of
it's been so long out -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: "James Adam" <james.adam@xxxxxxxxx>
In-reply-to:
<48fe25b0612271430n3a0ef67fscc5102c8949dfdfb@xxxxxxxxxxxxxx>
References:
<9ec5d0aa0612140349t2e12063etd4e5b28582792da7@xxxxxxxxxxxxxx> <ef46c93e0612141705y18c6f1f7l4c26c9635f1af74a@xxxxxxxxxxxxxx> <9ec5d0aa0612150326y40d1e895m57ea5c4efb6ffccd@xxxxxxxxxxxxxx> <1166208427.230439.76060@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <9ec5d0aa0612151232u7d322d0bicc35882fe81273c1@xxxxxxxxxxxxxx> <ef46c93e0612151552x63f33aeeod0c8a97e2e5deee7@xxxxxxxxxxxxxx> <48fe25b0612271430n3a0ef67fscc5102c8949dfdfb@xxxxxxxxxxxxxx>
Sounds good to me Rick. On 12/27/06, Rick Olson <technoweenie@xxxxxxxxx> wrote:
Hey guys, I thought we were all ready for a new Rails 1.2 RC, but I just realized I had cache_classes=true in one of my apps, and it started bombing as soon as I changed it back. So here's the changeset: http://dev.rubyonrails.org/changeset/5801 Nicholas' load_once_path changes were working, but none of the plugin paths were ever being added to it. #default_load_once_paths in Rails::Initializer wasn't working because it runs before plugins are initialized (and plugin lib paths aren't in default_load_paths). So, I just forced an addition to Dependencies.load_once_paths in #load_plugin. This change seems to work, but it makes it so no plugins reload at all (which has been the current behavior of plugins since the beginning). However, if you do want your plugins to reload, you can just add this to the top of init.rb: Dependencies.load_once_paths.delete(lib_path) Any problems with this approach? I just don't think all these plugins have been written to deal with reloading, so I don't want to force folks to restructure them. Maybe this can be changed for Rails 2.0 though... >
-- * J * ~ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: Trevor Squires <trevor@xxxxxxxxxxxxx>
In-reply-to:
<48fe25b0612281057q410d2acfj44589577f023f662@xxxxxxxxxxxxxx>
References:
<50C3EC58-9F24-44DA-8667-C8F896347AA4@xxxxxxxxxxxxx> <48fe25b0612280934j2e91e195k8bafe138ddb5de2d@xxxxxxxxxxxxxx> <C305B79F-09D5-4428-B2CC-F6ED6F848F8C@xxxxxxxxxxxxx> <48fe25b0612281057q410d2acfj44589577f023f662@xxxxxxxxxxxxxx>
Hey, On 28-Dec-06, at 10:57 AM, Rick Olson wrote:
You know what, I'm going to comment in whatever order I please.... so here we go...without *any* code changes (unless you had ActiveResource clients, in which case you'd have to change the name of your param for the resource entity in your controllers etc - a small change compared to the current alternatives).Changing your own code involves a quick search/replace. Changing client code requires API breakage or deprecation. I'd rather have to change my own code.
Absolutely - I too would rather change my own code... I just want to change less of it than I have to now. Unfortunately we're discussing hypothetical API changes - entirely my fault, I brought it up :-P
So there's hypothetical changes which would be made easier by :opaque_name (less search-and-replace) and others, perhaps more far-reaching, where it wouldn't make a blind bit of difference. The only concrete example I've got is the one I've given which you've correctly pointed out can be achieved without :opaque_name, albeit with a bit more effort.
Scroll down, there's more :-)
However, map.resources is currently tightly coupling the interface (the URL elements) to the guts of my code and I want a more painless way to exert control over that. With this one-line change to resources.rb I can divorce the resource name in my code from the resource name in the URL.I see your point in keeping the resource route that matches the resource/model name. I'm thinking something a little more clear than opaque_name would work better though: map.resources :quotes, :controller => 'quote_requests', :named_route => 'quote_requests'
There's two reasons I avoided approaching from this direction:1 - At first glance it would require more changes to resources.rb - all usage of resource.singular and resource.plural in the map_X_actions methods would need checks for :named_route being present - or (more correctly) some refactoring would need to be applied. But my laziness helped me realize point #2:
2 - I view map.resources' first argument as the name of the resource as *I* know it. The name of the resource as *clients* know it can be altered using :opaque_name, vaguely analogous to ARes' collection_name attribute. So I want to say "map my resource called X and by the way, clients know it as Y". As such, your :named_route argument is not the same thing.
That said, if the argument name of :opaque_name is the major stumbling block I'll gladly change it to something more palatable - perhaps :resource_url_name or similar.
And thanks for taking the time to hash this out :-) Trev
-- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: "Rick Olson" <technoweenie@xxxxxxxxx>
In-reply-to:
<C305B79F-09D5-4428-B2CC-F6ED6F848F8C@xxxxxxxxxxxxx>
References:
<50C3EC58-9F24-44DA-8667-C8F896347AA4@xxxxxxxxxxxxx> <48fe25b0612280934j2e91e195k8bafe138ddb5de2d@xxxxxxxxxxxxxx> <C305B79F-09D5-4428-B2CC-F6ED6F848F8C@xxxxxxxxxxxxx>
You know what, I'm going to comment in whatever order I please.... so here we go...
without *any* code changes (unless you had ActiveResource clients, in which case you'd have to change the name of your param for the resource entity in your controllers etc - a small change compared to the current alternatives).
Changing your own code involves a quick search/replace. Changing client code requires API breakage or deprecation. I'd rather have to change my own code.
However, map.resources is currently tightly coupling the interface (the URL elements) to the guts of my code and I want a more painless way to exert control over that. With this one-line change to resources.rb I can divorce the resource name in my code from the resource name in the URL.
I see your point in keeping the resource route that matches the resource/model name. I'm thinking something a little more clear than opaque_name would work better though: map.resources :quotes, :controller => 'quote_requests', :named_route => 'quote_requests' -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: Trevor Squires <trevor@xxxxxxxxxxxxx>
In-reply-to:
<48fe25b0612280934j2e91e195k8bafe138ddb5de2d@xxxxxxxxxxxxxx>
References:
<50C3EC58-9F24-44DA-8667-C8F896347AA4@xxxxxxxxxxxxx> <48fe25b0612280934j2e91e195k8bafe138ddb5de2d@xxxxxxxxxxxxxx>
Hey, comments inline: On 28-Dec-06, at 9:34 AM, Rick Olson wrote:
On 12/20/06, Trevor Squires <trevor@xxxxxxxxxxxxx> wrote:Hi, in my current project I've got a couple of map.resources as such: map.resources :quote_requests do |quote_request| quote_request.resources :request_items endmap.resources :quotes, :controller => 'quote_requests' Or just call the controller QuotesController instead of QuoteRequestsController. Is this really so bad? I'd think having the shorter url and routes would be a plus.
Rick, you're absolutely right insofar as there's more than one way to skin this cat.
However, your suggestion to use the controller as a way to make the URL opaque will still leave the URL helpers as quote_path etc, which is not what I want - I want them to remain as quote_request_path etc.
And taking my example, I've also got quote_responses with response_items, and I want to have /responses/9/items/3 - which under your scheme would leave me with a clash between request_items and response_items URL helpers.
Of course, I could use name prefixes for my helpers and/or I can manually build my named routes, leaving map.resources behind.
However, map.resources is currently tightly coupling the interface (the URL elements) to the guts of my code and I want a more painless way to exert control over that. With this one-line change to resources.rb I can divorce the resource name in my code from the resource name in the URL.
Adding this option to two map.resources calls in my routes.rb I can change a url like:
/quotes/9/items/3 to /anything/9/at_all/3without *any* code changes (unless you had ActiveResource clients, in which case you'd have to change the name of your param for the resource entity in your controllers etc - a small change compared to the current alternatives).
I'm not saying anything is going to 'flop' without being able to easily make resource urls more opaque :-) but being able to do so has eased my pain and I think that others may benefit.
Trev
-- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: Trevor Squires <trevor@xxxxxxxxxxxxx>
In-reply-to:
<1167300473.281230.70700@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<50C3EC58-9F24-44DA-8667-C8F896347AA4@xxxxxxxxxxxxx> <1167300473.281230.70700@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Hey,it's something that I did in edge rails - the 1.2 pre-releases don't have SingletonResource which is why you had to comment out that module_eval.
I think I'm going to have to release this as a plugin that I test against various rails versions because I'm pretty sure it's not a change that will appear in rails itself.
Trev On 28-Dec-06, at 2:07 AM, corvo wrote:
Hi, this seem to be exactly what I need : I develop my controllers in english, but I want to display URL in french and keep my mappings in routes.rb as simple as possible. Only one problem. I tried it and had to comment the last lines (SingletonResource module eval) : it's not working with the 1.2RC1 version. or maybe it's me : where did you put your code ? do you have to require some gem ? Thanks for this patch
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: "Rick Olson" <technoweenie@xxxxxxxxx>
In-reply-to:
<50C3EC58-9F24-44DA-8667-C8F896347AA4@xxxxxxxxxxxxx>
References:
<50C3EC58-9F24-44DA-8667-C8F896347AA4@xxxxxxxxxxxxx>
On 12/20/06, Trevor Squires <trevor@xxxxxxxxxxxxx> wrote:
Hi, in my current project I've got a couple of map.resources as such: map.resources :quote_requests do |quote_request| quote_request.resources :request_items end
map.resources :quotes, :controller => 'quote_requests' Or just call the controller QuotesController instead of QuoteRequestsController. Is this really so bad? I'd think having the shorter url and routes would be a plus. -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: "corvo" <rv_giraud@xxxxxxxxx>
In-reply-to:
<50C3EC58-9F24-44DA-8667-C8F896347AA4@xxxxxxxxxxxxx>
References:
<50C3EC58-9F24-44DA-8667-C8F896347AA4@xxxxxxxxxxxxx>
Hi, this seem to be exactly what I need : I develop my controllers in english, but I want to display URL in french and keep my mappings in routes.rb as simple as possible. Only one problem. I tried it and had to comment the last lines (SingletonResource module eval) : it's not working with the 1.2RC1 version. or maybe it's me : where did you put your code ? do you have to require some gem ? Thanks for this patch --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: "Mike Volodarsky" <mvolo@xxxxxxxxxxxxx>
In-reply-to:
<20061227203858.GF5152@xxxxxxxxxxx>
References:
<1167180542.215495.128490@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <48fe25b0612261751p2790aef7i55e26db8184b6248@xxxxxxxxxxxxxx> <1167214114.956933.156510@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <ef46c93e0612271118o7ee99fd1w7de6324499ab0ab@xxxxxxxxxxxxxx> <1167249585.071581.23200@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20061227203858.GF5152@xxxxxxxxxxx>
Thanks guys. I finally got it work, so we can unblock our progress with IIS FastCGI support for RoR ... If you are interested, watch for announcements on http://forums.iis.net/1103/ShowForum.aspx. Thanks, Mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: "Jonathan Viney" <jonathan.viney@xxxxxxxxx>
In-reply-to:
<1167249273.626503.126730@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167249273.626503.126730@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
We're inches away from pulling the trigger on RC2, which is the fast
track (a few days, tops) to the final release. Please examine the
latest from the branch and check if any of your pet blockers are still
there. If so, shoot us a link to a ticket.
So close now, so close.
Date: December 28, 2006
From: Jonathan Tron <jonathan.tron.mailings@xxxxxxxxx>
In-reply-to:
<1167249273.626503.126730@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167249273.626503.126730@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Le 27 déc. 06 à 20:54, DHH a écrit :
We're inches away from pulling the trigger on RC2, which is the fast track (a few days, tops) to the final release. Please examine the latest from the branch and check if any of your pet blockers are still there. If so, shoot us a link to a ticket. So close now, so close.
Hi, http://dev.rubyonrails.org/ticket/4668 is a big blocker to me. Jonathan Tron http://jonathan.tron.name --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: "Dan Manges" <daniel.manges@xxxxxxxxx>
In-reply-to:
<1167279370.415159.25440@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<459179E1.2030708@xxxxxxxxxx> <ef46c93e0612261152t56a407fdudfadc3f418cdca89@xxxxxxxxxxxxxx> <45919E4F.7070302@xxxxxxxxxx> <4591AE90.3070107@xxxxxxxxxx> <45928A6D.6020900@xxxxxxxxxx> <1167279370.415159.25440@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Dan Manges wrote:
I created a new ticket http://dev.rubyonrails.org/ticket/6807
That was the wrong link, here is the correct one: http://dev.rubyonrails.org/ticket/6896 Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 28, 2006
From: "Dan Manges" <daniel.manges@xxxxxxxxx>
In-reply-to:
<45928A6D.6020900@xxxxxxxxxx>
References:
<459179E1.2030708@xxxxxxxxxx> <ef46c93e0612261152t56a407fdudfadc3f418cdca89@xxxxxxxxxxxxxx> <45919E4F.7070302@xxxxxxxxxx> <4591AE90.3070107@xxxxxxxxxx> <45928A6D.6020900@xxxxxxxxxx>
Abdur-Rahman Advany wrote:
provided fix wouldn't work as you can specify the counter_cache column (and it doesn't have to end on _count),
I created a new ticket http://dev.rubyonrails.org/ticket/6807 with a patch that solves the problem. It may need some tweaks, or there may be a better way to solve the problem, but the patch works and includes tests. Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 27, 2006
From: Dee Zsombor <dee.zsombor@xxxxxxxxx>
In-reply-to:
<1167249273.626503.126730@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1167249273.626503.126730@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Would be most happy to see fragment caching work with non-erb templates. http://dev.rubyonrails.org/ticket/6642 Tests are included. Thanks, Zsombor --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Date: December 27, 2006
From: "Rick Olson" <technoweenie@xxxxxxxxx>
In-reply-to:
<ef46c93e0612151552x63f33aeeod0c8a97e2e5deee7@xxxxxxxxxxxxxx>
References:
<9ec5d0aa0612140349t2e12063etd4e5b28582792da7@xxxxxxxxxxxxxx> <ef46c93e0612141705y18c6f1f7l4c26c9635f1af74a@xxxxxxxxxxxxxx> <9ec5d0aa0612150326y40d1e895m57ea5c4efb6ffccd@xxxxxxxxxxxxxx> <1166208427.230439.76060@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <