[Rails-core] #all changes in 4.0
Hi guys, I don't think that the changes made to the behavior of #all in 4.0 are a very good idea. I can see that you no longer need to call all in as many cases as you did before - that's fine, just don't call it if you don't want it. But that doesn't mean you never need it or that people who do need it should not have it available. 1. Yes you can use to_a in many cases, but it behaves differently - for example if you have an association, to_a will return the cached target if the association has already been loaded. You absolutely need a way to run an actual query when you want the latest results. to_a cannot be relied upon to do this in all cases. Note lack of a second query: irb(main):006:0 p = Project.first Project Load (0.2ms) SELECT projects.* FROM projects ORDER BY projects.id ASC LIMIT 1 = #Project id: 1, created_at: 2013-02-27 09:38:49, updated_at: 2013-02-27 09:38:49 irb(main):007:0 p.tasks.to_a Task Load (0.2ms) SELECT tasks.* FROM tasks WHERE tasks.project_id = ? [[project_id, 1]] = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):008:0 p.tasks.to_a = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):010:0 p.tasks.all DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load (e.g. `Post.where(published: true).load`). If you want to get an array of records from a relation, you can call #to_a (e.g. `Post.where(published: true).to_a`). (called from irb_binding at (irb):10) = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):011:0 p.tasks.all DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load (e.g. `Post.where(published: true).load`). If you want to get an array of records from a relation, you can call #to_a (e.g. `Post.where(published: true).to_a`). (called from irb_binding at (irb):11) = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] 2. It's very important that queries run at the point you think they do in any application that uses locks or concurrency. Again, if you don't use locks or concurrency, fine - don't call the query methods. But many people do and they need to be able to run the queries to make this work. 3. It's not true that you no longer need to care whether you have an array or a relation. For example, methods like sum with a block need arrays, as the deprecation makes clear: irb(main):009:0 p.tasks.sum(:id) DEPRECATION WARNING: Calling #sum with a block is deprecated and will be removed in Rails 4.1. If you want to perform sum calculation over the array of elements, use `to_a.sum(block)`. (called from irb_binding at (irb):9) Task Load (0.1ms) SELECT tasks.* FROM tasks WHERE tasks.project_id = ? [[project_id, 1]] = 3 4. It's true that making all basically useless means you can now call all on a model class itself and get a relation and then you can merge that or whatever, which was one of the other examples in the changelog. But you could do that already - using scoped. It is not necessary to break #all's behavior to get this functionality. Have I misunderstood the change? If not, can we please put back the query method? Running queries is a pretty core responsibility of ActiveRecord. Thanks, Will -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Rails-core] try and try! in Rails 4.0
Can we please call the new try something else, and leave try doing what it already does? The new behavior was discussed at the time #try originally went in, and, with some dissenters, it was agreed that it was less useful for most people because any typo now becomes an expression that returns nil rather than an error you can see and fix. More generally, changing the semantics in the way that has been described is really confusing two very different things, and makes for a huge amount of search-and-replacing for those of us who read the changelogs and a lot of broken apps for those who don't. Try isn't a great name anyway. We can just pick another. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] #all changes in 4.0
1. You are using the wrong method. If you want the query always you call it you should use #load 2. Using #load you will know exactly when the query is done 3. #sum with block is not recommended since it will load all the object in memory. This is why it was deprecated. The query method is there. It is called #load now. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Wed, Feb 27, 2013 at 6:42 AM, Will Bryant will.bry...@gmail.com wrote: Hi guys, I don't think that the changes made to the behavior of #all in 4.0 are a very good idea. I can see that you no longer need to call all in as many cases as you did before - that's fine, just don't call it if you don't want it. But that doesn't mean you never need it or that people who do need it should not have it available. 1. Yes you can use to_a in many cases, but it behaves differently - for example if you have an association, to_a will return the cached target if the association has already been loaded. You absolutely need a way to run an actual query when you want the latest results. to_a cannot be relied upon to do this in all cases. Note lack of a second query: irb(main):006:0 p = Project.first Project Load (0.2ms) SELECT projects.* FROM projects ORDER BY projects.id ASC LIMIT 1 = #Project id: 1, created_at: 2013-02-27 09:38:49, updated_at: 2013-02-27 09:38:49 irb(main):007:0 p.tasks.to_a Task Load (0.2ms) SELECT tasks.* FROM tasks WHERE tasks.project_id = ? [[project_id, 1]] = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):008:0 p.tasks.to_a = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):010:0 p.tasks.all DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load (e.g. `Post.where(published: true).load`). If you want to get an array of records from a relation, you can call #to_a (e.g. `Post.where(published: true).to_a`). (called from irb_binding at (irb):10) = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):011:0 p.tasks.all DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load (e.g. `Post.where(published: true).load`). If you want to get an array of records from a relation, you can call #to_a (e.g. `Post.where(published: true).to_a`). (called from irb_binding at (irb):11) = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] 2. It's very important that queries run at the point you think they do in any application that uses locks or concurrency. Again, if you don't use locks or concurrency, fine - don't call the query methods. But many people do and they need to be able to run the queries to make this work. 3. It's not true that you no longer need to care whether you have an array or a relation. For example, methods like sum with a block need arrays, as the deprecation makes clear: irb(main):009:0 p.tasks.sum(:id) DEPRECATION WARNING: Calling #sum with a block is deprecated and will be removed in Rails 4.1. If you want to perform sum calculation over the array of elements, use `to_a.sum(block)`. (called from irb_binding at (irb):9) Task Load (0.1ms) SELECT tasks.* FROM tasks WHERE tasks.project_id = ? [[project_id, 1]] = 3 4. It's true that making all basically useless means you can now call all on a model class itself and get a relation and then you can merge that or whatever, which was one of the other examples in the changelog. But you could do that already - using scoped. It is not necessary to break #all's behavior to get this functionality. Have I misunderstood the change? If not, can we please put back the query method? Running queries is a pretty core responsibility of ActiveRecord. Thanks, Will -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop
Re: [Rails-core] #all changes in 4.0
I did some review in the code and in a relation, `#load` checks for `loaded?` so if the relation is still loaded it will not do the query. The only way right now to reload a relation is using `#reload`. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Wed, Feb 27, 2013 at 10:13 AM, Rafael Mendonça França rafaelmfra...@gmail.com wrote: 1. You are using the wrong method. If you want the query always you call it you should use #load 2. Using #load you will know exactly when the query is done 3. #sum with block is not recommended since it will load all the object in memory. This is why it was deprecated. The query method is there. It is called #load now. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Wed, Feb 27, 2013 at 6:42 AM, Will Bryant will.bry...@gmail.comwrote: Hi guys, I don't think that the changes made to the behavior of #all in 4.0 are a very good idea. I can see that you no longer need to call all in as many cases as you did before - that's fine, just don't call it if you don't want it. But that doesn't mean you never need it or that people who do need it should not have it available. 1. Yes you can use to_a in many cases, but it behaves differently - for example if you have an association, to_a will return the cached target if the association has already been loaded. You absolutely need a way to run an actual query when you want the latest results. to_a cannot be relied upon to do this in all cases. Note lack of a second query: irb(main):006:0 p = Project.first Project Load (0.2ms) SELECT projects.* FROM projects ORDER BY projects.id ASC LIMIT 1 = #Project id: 1, created_at: 2013-02-27 09:38:49, updated_at: 2013-02-27 09:38:49 irb(main):007:0 p.tasks.to_a Task Load (0.2ms) SELECT tasks.* FROM tasks WHERE tasks.project_id = ? [[project_id, 1]] = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):008:0 p.tasks.to_a = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):010:0 p.tasks.all DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load (e.g. `Post.where(published: true).load`). If you want to get an array of records from a relation, you can call #to_a (e.g. `Post.where(published: true).to_a`). (called from irb_binding at (irb):10) = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):011:0 p.tasks.all DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load (e.g. `Post.where(published: true).load`). If you want to get an array of records from a relation, you can call #to_a (e.g. `Post.where(published: true).to_a`). (called from irb_binding at (irb):11) = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] 2. It's very important that queries run at the point you think they do in any application that uses locks or concurrency. Again, if you don't use locks or concurrency, fine - don't call the query methods. But many people do and they need to be able to run the queries to make this work. 3. It's not true that you no longer need to care whether you have an array or a relation. For example, methods like sum with a block need arrays, as the deprecation makes clear: irb(main):009:0 p.tasks.sum(:id) DEPRECATION WARNING: Calling #sum with a block is deprecated and will be removed in Rails 4.1. If you want to perform sum calculation over the array of elements, use `to_a.sum(block)`. (called from irb_binding at (irb):9) Task Load (0.1ms) SELECT tasks.* FROM tasks WHERE tasks.project_id = ? [[project_id, 1]] = 3 4. It's true that making all basically useless means you can now call all on a model class itself and get a relation and then you can merge that or whatever, which was one of the other examples in the changelog. But you could do that already - using scoped. It is not necessary to break #all's behavior to get this functionality. Have I misunderstood the change? If not, can we please put back the query method? Running queries is a pretty core responsibility of ActiveRecord. Thanks, Will -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to
[Rails-core] Re: try and try! in Rails 4.0
Can you show me some of the many places where your app now breaks because we don't raise an exception on #try? Also, this is why we do major releases, so we can break backwards compatibility in order to improve the API. Having #try! be the exception raising version of #try makes perfect sense to me. And I find the #try that doesn't raise exceptions much more useful in my work. Feel free to suggest a better name, but odds are low that it'll be accepted. Of course, the great thing about Ruby is that you can add your own alias. Enjoy! On Wednesday, February 27, 2013 3:43:17 AM UTC-6, will.bryant wrote: Can we please call the new try something else, and leave try doing what it already does? The new behavior was discussed at the time #try originally went in, and, with some dissenters, it was agreed that it was less useful for most people because any typo now becomes an expression that returns nil rather than an error you can see and fix. More generally, changing the semantics in the way that has been described is really confusing two very different things, and makes for a huge amount of search-and-replacing for those of us who read the changelogs and a lot of broken apps for those who don't. Try isn't a great name anyway. We can just pick another. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Re: My SCSS compiled CSS lacks /assets in the generated urls
I would create an issue if I could replicate the issue in a new application, but I couldn't yet. If I can isolate the problem I'll create a new issue. Em 27-02-2013 01:10, Andrew Kaspick escreveu: Open a github issue for the problem; it won't be addressed otherwise. On Tue, Feb 26, 2013 at 9:18 PM, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com mailto:rr.ro...@gmail.com wrote: I think I've narrowed down the problem. For some reason this block isn't executed when I run rake assets:precompile: https://github.com/rails/sprockets-rails/blob/master/lib/sprockets/railtie.rb#L86 ActiveSupport.on_load(:action_view) do... Maybe that's because I have a class under lib that relies on ActionView::Helpers::NumberHelper, and then I require 'action_view'. So, when the hook is registered 'action_view' might already be loaded and the event won't be triggered. Just guessing of course as I couldn't find any documentation about how that on_load method works. Then I've written something like this to fix the assets precompilation for my application: def fix_asset_precompiling config = Rails.application.config Rails.application.assets.context_class.tap do |c| c.assets_prefix = config.assets.prefix c.digest_assets = config.assets.digest c.config = config.action_controller end end I'm not sending a pull request because I'm not sure what is the proper way of fixing it. But I can tell you that if you replace the line above with begin it works. - ActiveSupport.on_load(:action_view) do + begin But I don't know what is the reason for the on_load hook, so I won't change anything. I'd just like to let you know about this problem. This is a new bug and doesn't exist on Rails 3. Best, Rodrigo. Em 26-02-2013 22:04, Rodrigo Rosenfeld Rosas escreveu: Running rake assets:clobber assets:precompile will generate files like application-xxx.css with incorrect urls after upgrading to Rails 4. For example url(/fields/xxx.png) when it should be url(/assets/fields/xxx.png). For some unknown reason it worked once in development mode, but after running rake assets:clobber I can't get it to work again... Any ideas why image-url(fields/sprite.gif) is generating url(/fields/sprite.gif) instead of url(/assets/fields/sprite.gif)? It happens both in my staging server (running 1.9.3) and in my dev machine (Ruby 2.0.0-p1). I'm stuck with this enigma. Any help is greatly appreciated. Thanks in advance, Rodrigo. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Re: My SCSS compiled CSS lacks /assets in the generated urls
Ok, I could finally replicate the issue in development mode for a new application when I disable the turbolinks gem. In my application it also happens in production and all other environments but at least if this is fixed for development mode it could also fix for my other environments. I've created this issue: https://github.com/rails/rails/issues/9461 Here is an application demonstrating the issue: https://github.com/rosenfeld/assetsbug Em 27-02-2013 10:54, Rodrigo Rosenfeld Rosas escreveu: I would create an issue if I could replicate the issue in a new application, but I couldn't yet. If I can isolate the problem I'll create a new issue. Em 27-02-2013 01:10, Andrew Kaspick escreveu: Open a github issue for the problem; it won't be addressed otherwise. On Tue, Feb 26, 2013 at 9:18 PM, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com mailto:rr.ro...@gmail.com wrote: I think I've narrowed down the problem. For some reason this block isn't executed when I run rake assets:precompile: https://github.com/rails/sprockets-rails/blob/master/lib/sprockets/railtie.rb#L86 ActiveSupport.on_load(:action_view) do... Maybe that's because I have a class under lib that relies on ActionView::Helpers::NumberHelper, and then I require 'action_view'. So, when the hook is registered 'action_view' might already be loaded and the event won't be triggered. Just guessing of course as I couldn't find any documentation about how that on_load method works. Then I've written something like this to fix the assets precompilation for my application: def fix_asset_precompiling config = Rails.application.config Rails.application.assets.context_class.tap do |c| c.assets_prefix = config.assets.prefix c.digest_assets = config.assets.digest c.config = config.action_controller end end I'm not sending a pull request because I'm not sure what is the proper way of fixing it. But I can tell you that if you replace the line above with begin it works. - ActiveSupport.on_load(:action_view) do + begin But I don't know what is the reason for the on_load hook, so I won't change anything. I'd just like to let you know about this problem. This is a new bug and doesn't exist on Rails 3. Best, Rodrigo. Em 26-02-2013 22:04, Rodrigo Rosenfeld Rosas escreveu: Running rake assets:clobber assets:precompile will generate files like application-xxx.css with incorrect urls after upgrading to Rails 4. For example url(/fields/xxx.png) when it should be url(/assets/fields/xxx.png). For some unknown reason it worked once in development mode, but after running rake assets:clobber I can't get it to work again... Any ideas why image-url(fields/sprite.gif) is generating url(/fields/sprite.gif) instead of url(/assets/fields/sprite.gif)? It happens both in my staging server (running 1.9.3) and in my dev machine (Ruby 2.0.0-p1). I'm stuck with this enigma. Any help is greatly appreciated. Thanks in advance, Rodrigo. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Correct Use or Naming of Migrations
Here's the task I alluded to if anyone is interested: https://gist.github.com/blatyo/5047690 Allen Madsen http://www.allenmadsen.com On Thu, Feb 21, 2013 at 3:26 PM, Allen Madsen allen.c.mad...@gmail.comwrote: At Gazelle, we essentially copy the migration rake tasks and call them iterations. So, as you'd imagine: rake iteration:migrate # like rake db:migrate We use it for data only changes. Allen Madsen http://www.allenmadsen.com On Thu, Feb 21, 2013 at 3:17 PM, Duncan Beevers duncanbeev...@gmail.comwrote: One small thing I'd like to point out is that running migrations serially is not the same as recreating the database from a schema dump. For example, the Rails migration `timestamp` directive has flip-flopped in its behavior (`created_at` was originally nullable, then not nullable, then nullable again) so the effect of running a migration is a combination of the migration's own code plus the underlying gems and application code in effect at the time it runs. I like the idea of a sister directory to migrations to synchronize deploys with the one-time tasks that accompany them. On Thu, Feb 21, 2013 at 2:08 PM, Jonathan Lozinski jonathan.lozin...@gmail.com wrote: I agree. Whilst there might be a number of different things people do, rails providing some guidance, or reusable hooks to support the following would be helpful: 1. Seeding stuff after you have a live product 2. Running one-time tasks on a deploy without changing your automated release processes. Both lend themselves to having a open framework which migrations is 'built' on, which lets you use a gem or whatever to provide another 'tracked' table such as a seeds table or a 'deployment_tasks' table which uses the same basic techniques as the migration system, that is: 1. it will have a rails generator to build a skeleton class to perform the 'task' which is named with a timestamp etc like migrations 2. a rake task to run the task which will execute any 'unrun' jobs in the folder This would allow Rails' migrations to be built on top of this (and thus support rollback or whatever), but allow plugins or to build a system for more app specific tasks which don't however have to reinvent the robust framework that migrations currently has. On 18 Feb 2013, at 13:44, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com wrote: Em 18-02-2013 08:05, mrloz escreveu: ... Additionally, rails doesn't (to my knowledge) provide a way to run db:seed after you have a live system which doesn't try and push prior seeds in too. What is the recommended way to add seeded values to new tables in a live system? I believe supporting a seeds table in addition to the migrations table would be a great idea. The same way we currently have migrations under db/migrations/ it would be great if we could have our seeds under db/seeds/. Then rake db:migrate would also run db:seed or whatever other task name you might prefer. When running rake db:reset the seed migration would be run after restoring the DB infra-structure. That sounds like a good tool to add to AR migrations. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com . Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en . For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] #all changes in 4.0
On Feb 27, 2013, at 4:42 AM, Will Bryant wrote: Hi guys, I don't think that the changes made to the behavior of #all in 4.0 are a very good idea. I can see that you no longer need to call all in as many cases as you did before - that's fine, just don't call it if you don't want it. But that doesn't mean you never need it or that people who do need it should not have it available. 1. Yes you can use to_a in many cases, but it behaves differently - for example if you have an association, to_a will return the cached target if the association has already been loaded. You absolutely need a way to run an actual query when you want the latest results. to_a cannot be relied upon to do this in all cases. p.tasks(true) will *always* reload the association. I haven't seen the equivalent for relations, though. --Matt Jones -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] #all changes in 4.0
I think Rafael has already answered your questions, but as the person who made the changes I'm happy to answer any further questions if you have them? On 27/02/13 13:31, Rafael Mendonça França wrote: I did some review in the code and in a relation, `#load` checks for `loaded?` so if the relation is still loaded it will not do the query. The only way right now to reload a relation is using `#reload`. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Wed, Feb 27, 2013 at 10:13 AM, Rafael Mendonça França rafaelmfra...@gmail.com mailto:rafaelmfra...@gmail.com wrote: 1. You are using the wrong method. If you want the query always you call it you should use |#load| 2. Using |#load| you will know exactly when the query is done 3. |#sum| with block is not recommended since it will load all the object in memory. This is why it was deprecated. The query method is there. It is called |#load| now. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Wed, Feb 27, 2013 at 6:42 AM, Will Bryant will.bry...@gmail.com mailto:will.bry...@gmail.com wrote: Hi guys, I don't think that the changes made to the behavior of #all in 4.0 are a very good idea. I can see that you no longer need to call all in as many cases as you did before - that's fine, just don't call it if you don't want it. But that doesn't mean you never need it or that people who do need it should not have it available. 1. Yes you can use to_a in many cases, but it behaves differently - for example if you have an association, to_a will return the cached target if the association has already been loaded. You absolutely need a way to run an actual query when you want the latest results. to_a cannot be relied upon to do this in all cases. Note lack of a second query: irb(main):006:0 p = Project.first Project Load (0.2ms) SELECT projects.* FROM projects ORDER BY projects.id ASC LIMIT 1 = #Project id: 1, created_at: 2013-02-27 09:38:49, updated_at: 2013-02-27 09:38:49 irb(main):007:0 p.tasks.to_a Task Load (0.2ms) SELECT tasks.* FROM tasks WHERE tasks.project_id = ? [[project_id, 1]] = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):008:0 p.tasks.to_a = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):010:0 p.tasks.all DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load (e.g. `Post.where(published: true).load`). If you want to get an array of records from a relation, you can call #to_a (e.g. `Post.where(published: true).to_a`). (called from irb_binding at (irb):10) = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):011:0 p.tasks.all DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load (e.g. `Post.where(published: true).load`). If you want to get an array of records from a relation, you can call #to_a (e.g. `Post.where(published: true).to_a`). (called from irb_binding at (irb):11) = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] 2. It's very important that queries run at the point you think they do in any application that uses locks or concurrency. Again, if you don't use locks or concurrency, fine - don't call the query methods. But many people do and they need to be able to run the queries to make this work. 3. It's not true that you no longer need to care whether you have an array or a relation. For example, methods like sum with a block need arrays, as the deprecation makes clear: irb(main):009:0 p.tasks.sum(:id) DEPRECATION WARNING: Calling #sum with a block is deprecated and will be removed in Rails 4.1. If you want to perform sum calculation over the array of
Re: [Rails-core] Correct Use or Naming of Migrations
This looks like pretty much what I think should be available, only difference being the ability to specify what table to record the running to keep db:migrate free from non db concerns Sent from my iPad On 27 Feb 2013, at 14:40, Allen Madsen allen.c.mad...@gmail.com wrote: Here's the task I alluded to if anyone is interested: https://gist.github.com/blatyo/5047690 Allen Madsen http://www.allenmadsen.com On Thu, Feb 21, 2013 at 3:26 PM, Allen Madsen allen.c.mad...@gmail.comwrote: At Gazelle, we essentially copy the migration rake tasks and call them iterations. So, as you'd imagine: rake iteration:migrate # like rake db:migrate We use it for data only changes. Allen Madsen http://www.allenmadsen.com On Thu, Feb 21, 2013 at 3:17 PM, Duncan Beevers duncanbeev...@gmail.comwrote: One small thing I'd like to point out is that running migrations serially is not the same as recreating the database from a schema dump. For example, the Rails migration `timestamp` directive has flip-flopped in its behavior (`created_at` was originally nullable, then not nullable, then nullable again) so the effect of running a migration is a combination of the migration's own code plus the underlying gems and application code in effect at the time it runs. I like the idea of a sister directory to migrations to synchronize deploys with the one-time tasks that accompany them. On Thu, Feb 21, 2013 at 2:08 PM, Jonathan Lozinski jonathan.lozin...@gmail.com wrote: I agree. Whilst there might be a number of different things people do, rails providing some guidance, or reusable hooks to support the following would be helpful: 1. Seeding stuff after you have a live product 2. Running one-time tasks on a deploy without changing your automated release processes. Both lend themselves to having a open framework which migrations is 'built' on, which lets you use a gem or whatever to provide another 'tracked' table such as a seeds table or a 'deployment_tasks' table which uses the same basic techniques as the migration system, that is: 1. it will have a rails generator to build a skeleton class to perform the 'task' which is named with a timestamp etc like migrations 2. a rake task to run the task which will execute any 'unrun' jobs in the folder This would allow Rails' migrations to be built on top of this (and thus support rollback or whatever), but allow plugins or to build a system for more app specific tasks which don't however have to reinvent the robust framework that migrations currently has. On 18 Feb 2013, at 13:44, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com wrote: Em 18-02-2013 08:05, mrloz escreveu: ... Additionally, rails doesn't (to my knowledge) provide a way to run db:seed after you have a live system which doesn't try and push prior seeds in too. What is the recommended way to add seeded values to new tables in a live system? I believe supporting a seeds table in addition to the migrations table would be a great idea. The same way we currently have migrations under db/migrations/ it would be great if we could have our seeds under db/seeds/. Then rake db:migrate would also run db:seed or whatever other task name you might prefer. When running rake db:reset the seed migration would be run after restoring the DB infra-structure. That sounds like a good tool to add to AR migrations. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com . Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en . For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to
[Rails-core] [ANN] Rails 3.2.13.rc1 has been released!
Hey everyone! I am pumped to announce that Rails 3.2.13.rc1 has been released!
If no regressions are found I will release 3.2.13 final in two weeks, on March
13, 2013. If you find one, please [Open an Issue on
GitHub](https://github.com/rails/rails/issues/new) so that I can fix it before
the final release.
This is a bugfix release, with 287 commits. There is one big thing that is
technically a fix but is sort of a feature: Ruby 2.0 support. Big thanks to
Prem Sichanugrist for putting that together! Please give your applications a
try on Ruby 2.0 and let me know how that goes.
## CHANGES since 3.2.12
*Action Mailer*
No changes.
*Action Pack*
* Determine the controller#action from only the matched path when using the
shorthand syntax. Previously the complete path was used, which led
to problems with nesting (scopes and namespaces).
Fixes #7554.
Backport #9361.
Example:
# this will route to questions#new
scope ':locale' do
get 'questions/new'
end
*Yves Senn*
* Fix `assert_template` with `render :stream = true`.
Fix #1743.
Backport #5288.
*Sergey Nartimov*
* Eagerly populate the http method loookup cache so local project
inflections do
not interfere with use of underscore method ( and we don't need locks )
*Aditya Sanghi*
* `BestStandardsSupport` no longer duplicates `X-UA-Compatible` values on
each request to prevent header size from blowing up.
*Edward Anderson*
* Fixed JSON params parsing regression for non-object JSON content.
*Dylan Smith*
* Prevent unnecessary asset compilation when using `javascript_include_tag` on
files with non-standard extensions.
*Noah Silas*
* Fixes issue where duplicate assets can be required with sprockets.
*Jeremy Jackson*
* Bump `rack` dependency to 1.4.3, eliminate `Rack::File` headers
deprecation warning.
*Sam Ruby + Carlos Antonio da Silva*
* Do not append second slash to `root_url` when using `trailing_slash: true`
Fix #8700.
Backport #8701.
Example:
# before
root_url # = http://test.host//
# after
root_url # = http://test.host/
*Yves Senn*
* Fix a bug in `content_tag_for` that prevents it for work without a block.
*Jasl*
* Clear url helper methods when routes are reloaded by removing the methods
explicitly rather than just clearing the module because it didn't work
properly and could be the source of a memory leak.
*Andrew White*
* Fix a bug in `ActionDispatch::Request#raw_post` that caused
`env['rack.input']`
to be read but not rewound.
*Matt Venables*
* More descriptive error messages when calling `render :partial` with
an invalid `:layout` argument.
Fixes #8376.
render :partial = 'partial', :layout = true
# results in ActionView::MissingTemplate: Missing partial /true
*Yves Senn*
* Accept symbols as `#send_data` :disposition value. [Backport
#8329] *Elia Schito*
* Add i18n scope to `distance_of_time_in_words`. [Backport #7997]
*Steve Klabnik*
* Fix side effect of `url_for` changing the `:controller` string
option. [Backport #6003]
Before:
controller = '/projects'
url_for :controller = controller, :action = 'status'
puts controller #= 'projects'
After
puts controller #= '/projects'
*Nikita Beloglazov + Andrew White*
* Introduce `ActionView::Template::Handlers::ERB.escape_whitelist`.
This is a list
of mime types where template text is not html escaped by default.
It prevents `Jack Joe`
from rendering as `Jack amp; Joe` for the whitelisted mime types.
The default whitelist
contains text/plain. Fix #7976 [Backport #8235]
*Joost Baaij*
* `BestStandardsSupport` middleware now appends it's
`X-UA-Compatible` value to app's
returned value if any. Fix #8086 [Backport #8093]
*Nikita Afanasenko*
* prevent double slashes in engine urls when
`Rails.application.default_url_options[:trailing_slash] = true` is set
Fix #7842
*Yves Senn*
* Fix input name when `:multiple = true` and `:index` are set.
Before:
check_box(post, comment_ids, { :multiple = true, :index
= foo }, 1)
#= input name=\post[foo][comment_ids]\ type=\hidden\
value=\0\ /input id=\post_foo_comment_ids_1\
name=\post[foo][comment_ids]\ type=\checkbox\ value=\1\ /
After:
check_box(post, comment_ids, { :multiple = true, :index
= foo }, 1)
#= input name=\post[foo][comment_ids][]\ type=\hidden\
value=\0\ /input id=\post_foo_comment_ids_1\
name=\post[foo][comment_ids][]\ type=\checkbox\ value=\1\ /
Fix #8108
*Daniel Fox, Grant Hutchins Trace Wax*
*Active Model*
* Specify type of singular association during serialization *Steve Klabnik*
*Active Record*
* Reverted 921a296a3390192a71abeec6d9a035cc6d1865c8, 'Quote numeric values
compared to string columns.' This caused several regressions.
Re: [Rails-core] #all changes in 4.0
On 28/02/2013, at 11:17 , Jon Leighton j...@jonathanleighton.com wrote: #reload will always run the query. If I'm misunderstanding the use case please provide some examples. Hmm. But you can't run reload on a scope to get an array - it returns a relation, which as per previous emails doesn't behave the same. So are you saying we should use .reload.to_a everywhere instead of #all? That really seems like a worse API than #all and this is a very common operation. Is it really worth changing #all to be nearly useless and have no direct to do that? Could we at least have a method that does this, say query? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] #all changes in 4.0
Or all(true) On Wed, Feb 27, 2013 at 4:25 PM, Will Bryant will.bry...@gmail.com wrote: On 28/02/2013, at 11:17 , Jon Leighton j...@jonathanleighton.com wrote: #reload will always run the query. If I'm misunderstanding the use case please provide some examples. Hmm. But you can't run reload on a scope to get an array - it returns a relation, which as per previous emails doesn't behave the same. So are you saying we should use .reload.to_a everywhere instead of #all? That really seems like a worse API than #all and this is a very common operation. Is it really worth changing #all to be nearly useless and have no direct to do that? Could we at least have a method that does this, say query? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] #all changes in 4.0
Most other enterprise-y languages (esp. Java+Hibernate, .NET+NHibernate, .NET+Entity Framework) reinforce deferred execution of queries: the query is not executed until it is enumerated. This is now the exact same behavior as those platforms. Calling .sum() on an association, before you've enumerated, will alter the query to perform a SELECT SUM(...). Obviously, this fails on anything that doesn't exist in the database. If you want to .sum() in memory, you must enumerate the collection first (calling .ToArray() in .NET will do this). I don't know if the author of this deferred execution has experience with these other ORM's, but the behavior is now identical. Employee.all vs. Employee.all.to_a is not that big of a deal. And you should expect breaking changes with a major version number. That's why your code is covered by tests, right? Signed, An-ex-.NET-developer-turned-Rubyist -- Jarrett Meyer Email: jarrettme...@gmail.com Web: JarrettMeyer.com http://jarrettmeyer.com Twitter: @jarrettmeyer http://twitter.com/jarrettmeyer On Wed, Feb 27, 2013 at 6:09 PM, Will Bryant will.bry...@gmail.com wrote: That's better than nothing, but #all returns a relation now, which is half the problem (like when you need to sum methods not columns, for eg.). On 28/02/2013, at 12:00 , Duncan Beevers duncanbeev...@gmail.com wrote: Or all(true) On Wed, Feb 27, 2013 at 4:25 PM, Will Bryant will.bry...@gmail.comwrote: On 28/02/2013, at 11:17 , Jon Leighton j...@jonathanleighton.com wrote: #reload will always run the query. If I'm misunderstanding the use case please provide some examples. Hmm. But you can't run reload on a scope to get an array - it returns a relation, which as per previous emails doesn't behave the same. So are you saying we should use .reload.to_a everywhere instead of #all? That really seems like a worse API than #all and this is a very common operation. Is it really worth changing #all to be nearly useless and have no direct to do that? Could we at least have a method that does this, say query? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en . For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] #all changes in 4.0
Hi Jarrett, As per previous emails, the problem is that you can't now force it to do a query using any particular method. Associations will cache if you enumerate them and so will not behave in that simple way. Yes we have tests and yes it does show that this kind of change breaks things. That's why I'm complaining. Cheers, Will On 28/02/2013, at 15:16 , Jarrett Meyer jarrettme...@gmail.com wrote: Most other enterprise-y languages (esp. Java+Hibernate, .NET+NHibernate, .NET+Entity Framework) reinforce deferred execution of queries: the query is not executed until it is enumerated. This is now the exact same behavior as those platforms. Calling .sum() on an association, before you've enumerated, will alter the query to perform a SELECT SUM(...). Obviously, this fails on anything that doesn't exist in the database. If you want to .sum() in memory, you must enumerate the collection first (calling .ToArray() in .NET will do this). I don't know if the author of this deferred execution has experience with these other ORM's, but the behavior is now identical. Employee.all vs. Employee.all.to_a is not that big of a deal. And you should expect breaking changes with a major version number. That's why your code is covered by tests, right? Signed, An-ex-.NET-developer-turned-Rubyist -- Jarrett Meyer Email: jarrettme...@gmail.com Web: JarrettMeyer.com Twitter: @jarrettmeyer On Wed, Feb 27, 2013 at 6:09 PM, Will Bryant will.bry...@gmail.com wrote: That's better than nothing, but #all returns a relation now, which is half the problem (like when you need to sum methods not columns, for eg.). On 28/02/2013, at 12:00 , Duncan Beevers duncanbeev...@gmail.com wrote: Or all(true) On Wed, Feb 27, 2013 at 4:25 PM, Will Bryant will.bry...@gmail.com wrote: On 28/02/2013, at 11:17 , Jon Leighton j...@jonathanleighton.com wrote: #reload will always run the query. If I'm misunderstanding the use case please provide some examples. Hmm. But you can't run reload on a scope to get an array - it returns a relation, which as per previous emails doesn't behave the same. So are you saying we should use .reload.to_a everywhere instead of #all? That really seems like a worse API than #all and this is a very common operation. Is it really worth changing #all to be nearly useless and have no direct to do that? Could we at least have a method that does this, say query? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] #all changes in 4.0
http://edgeguides.rubyonrails.org/association_basics.html#controlling-caching It looks like clearing the cache and going to the DB is quite easy. I don't believe your statement is accurate that you can't force a fresh, enumerated query. And the cache is reset per request, which is a very short time. The only thing I can think of that would require this kind of functionality is a database trigger or other out-of-sequence activity. On Feb 27, 2013, at 11:38 PM, Will Bryant will.bry...@gmail.com wrote: Hi Jarrett, As per previous emails, the problem is that you can't now force it to do a query using any particular method. Associations will cache if you enumerate them and so will not behave in that simple way. Yes we have tests and yes it does show that this kind of change breaks things. That's why I'm complaining. Cheers, Will On 28/02/2013, at 15:16 , Jarrett Meyer jarrettme...@gmail.com wrote: Most other enterprise-y languages (esp. Java+Hibernate, .NET+NHibernate, .NET+Entity Framework) reinforce deferred execution of queries: the query is not executed until it is enumerated. This is now the exact same behavior as those platforms. Calling .sum() on an association, before you've enumerated, will alter the query to perform a SELECT SUM(...). Obviously, this fails on anything that doesn't exist in the database. If you want to .sum() in memory, you must enumerate the collection first (calling .ToArray() in .NET will do this). I don't know if the author of this deferred execution has experience with these other ORM's, but the behavior is now identical. Employee.all vs. Employee.all.to_a is not that big of a deal. And you should expect breaking changes with a major version number. That's why your code is covered by tests, right? Signed, An-ex-.NET-developer-turned-Rubyist -- Jarrett Meyer Email: jarrettme...@gmail.com Web: JarrettMeyer.com Twitter: @jarrettmeyer On Wed, Feb 27, 2013 at 6:09 PM, Will Bryant will.bry...@gmail.com wrote: That's better than nothing, but #all returns a relation now, which is half the problem (like when you need to sum methods not columns, for eg.). On 28/02/2013, at 12:00 , Duncan Beevers duncanbeev...@gmail.com wrote: Or all(true) On Wed, Feb 27, 2013 at 4:25 PM, Will Bryant will.bry...@gmail.com wrote: On 28/02/2013, at 11:17 , Jon Leighton j...@jonathanleighton.com wrote: #reload will always run the query. If I'm misunderstanding the use case please provide some examples. Hmm. But you can't run reload on a scope to get an array - it returns a relation, which as per previous emails doesn't behave the same. So are you saying we should use .reload.to_a everywhere instead of #all? That really seems like a worse API than #all and this is a very common operation. Is it really worth changing #all to be nearly useless and have no direct to do that? Could we at least have a method that does this, say query? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from
Re: [Rails-core] #all changes in 4.0
The thing that's got worse is having to write different code for associations vs. relations. Currently #all will behave exactly the same way on both, which is very useful because you can write code on a model class that works the same way whether it's working on a global scope or just an association. BTW, the per-request caching mechanism is query caching, which is different to the loadedness caching that associations do, which is the reason to_a is not a consistent replacement for #all, and why I want at least a method that always does a query (#query, for example). The query caching mechanism has other effects but it always returns a fresh set of objects and is also only on when you expect it, so it is easier to control. On 28/02/2013, at 18:19 , Jarrett Meyer jarrettme...@gmail.com wrote: http://edgeguides.rubyonrails.org/association_basics.html#controlling-caching It looks like clearing the cache and going to the DB is quite easy. I don't believe your statement is accurate that you can't force a fresh, enumerated query. And the cache is reset per request, which is a very short time. The only thing I can think of that would require this kind of functionality is a database trigger or other out-of-sequence activity. On Feb 27, 2013, at 11:38 PM, Will Bryant will.bry...@gmail.com wrote: Hi Jarrett, As per previous emails, the problem is that you can't now force it to do a query using any particular method. Associations will cache if you enumerate them and so will not behave in that simple way. Yes we have tests and yes it does show that this kind of change breaks things. That's why I'm complaining. Cheers, Will On 28/02/2013, at 15:16 , Jarrett Meyer jarrettme...@gmail.com wrote: Most other enterprise-y languages (esp. Java+Hibernate, .NET+NHibernate, .NET+Entity Framework) reinforce deferred execution of queries: the query is not executed until it is enumerated. This is now the exact same behavior as those platforms. Calling .sum() on an association, before you've enumerated, will alter the query to perform a SELECT SUM(...). Obviously, this fails on anything that doesn't exist in the database. If you want to .sum() in memory, you must enumerate the collection first (calling .ToArray() in .NET will do this). I don't know if the author of this deferred execution has experience with these other ORM's, but the behavior is now identical. Employee.all vs. Employee.all.to_a is not that big of a deal. And you should expect breaking changes with a major version number. That's why your code is covered by tests, right? Signed, An-ex-.NET-developer-turned-Rubyist -- Jarrett Meyer Email: jarrettme...@gmail.com Web: JarrettMeyer.com Twitter: @jarrettmeyer On Wed, Feb 27, 2013 at 6:09 PM, Will Bryant will.bry...@gmail.com wrote: That's better than nothing, but #all returns a relation now, which is half the problem (like when you need to sum methods not columns, for eg.). On 28/02/2013, at 12:00 , Duncan Beevers duncanbeev...@gmail.com wrote: Or all(true) On Wed, Feb 27, 2013 at 4:25 PM, Will Bryant will.bry...@gmail.com wrote: On 28/02/2013, at 11:17 , Jon Leighton j...@jonathanleighton.com wrote: #reload will always run the query. If I'm misunderstanding the use case please provide some examples. Hmm. But you can't run reload on a scope to get an array - it returns a relation, which as per previous emails doesn't behave the same. So are you saying we should use .reload.to_a everywhere instead of #all? That really seems like a worse API than #all and this is a very common operation. Is it really worth changing #all to be nearly useless and have no direct to do that? Could we at least have a method that does this, say query? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: [Rails-core] try and try! in Rails 4.0
Only apps that have bugs. But that's the thing - currently you find out about the bugs, now you won't. Remember how great it was when we had to write ActionScript and it just silently swallowed all the errors and you couldn't find out where your code was breaking? No? It wasn't great, it was a PITA :). On 28/02/2013, at 02:39 , DHH da...@loudthinking.com wrote: Can you show me some of the many places where your app now breaks because we don't raise an exception on #try? Also, this is why we do major releases, so we can break backwards compatibility in order to improve the API. Having #try! be the exception raising version of #try makes perfect sense to me. And I find the #try that doesn't raise exceptions much more useful in my work. Feel free to suggest a better name, but odds are low that it'll be accepted. Of course, the great thing about Ruby is that you can add your own alias. Enjoy! On Wednesday, February 27, 2013 3:43:17 AM UTC-6, will.bryant wrote: Can we please call the new try something else, and leave try doing what it already does? The new behavior was discussed at the time #try originally went in, and, with some dissenters, it was agreed that it was less useful for most people because any typo now becomes an expression that returns nil rather than an error you can see and fix. More generally, changing the semantics in the way that has been described is really confusing two very different things, and makes for a huge amount of search-and-replacing for those of us who read the changelogs and a lot of broken apps for those who don't. Try isn't a great name anyway. We can just pick another. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
