And responding, "Because it's frequently time consuming to find work arounds for the new bugs introduced in the latest version."
Sure, there are improvements and bug fixes with more recent releases, but when you have a major release of a product, there are frequently more bugs, sometimes obscure ones.
I'd be willing to bet that there are fewer bugs in Rails version 3.2.18 than in Rails version 4.1.0.
So, when do you upgrade?
As usual... "It depends."
Are the benefits of the new enhancements greater than the cost of upgrading?
Error on Size Method...Really?Yes. Really.
Here's an example of one of a work-arounds that I found necessary when upgrading to Rails 4.1.0.
The following error popped up in the logs:
E, [2014-05-09T01:42:38.962399 #85483] ERROR -- : Exception ActiveRecord::StatementInvalid -> PG::UndefinedFunction: ERROR: function count(integer, character varying) does not exist LINE 1: SELECT COUNT(id, default_language_code) FROM "table_name_here... ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. : SELECT COUNT(id, default_language_code) FROM "table_name_heres" WHERE (default_language_code is not null) vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/connection_adapters/postgresql_adapter.rb:815:in `async_exec' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/connection_adapters/postgresql_adapter.rb:815:in `block in exec_no_cache' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/connection_adapters/abstract_adapter.rb:373:in `block in log' vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.0/lib/active_support/notifications/instrumenter.rb:20:in `instrument' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/connection_adapters/abstract_adapter.rb:367:in `log' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/connection_adapters/postgresql_adapter.rb:815:in `exec_no_cache' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/connection_adapters/postgresql/database_statements.rb:137:in `exec_query' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/connection_adapters/postgresql_adapter.rb:947:in `select' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/connection_adapters/abstract/database_statements.rb:31:in `select_all' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/connection_adapters/abstract/query_cache.rb:69:in `select_all' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/relation/calculations.rb:254:in `execute_simple_calculation' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/relation/calculations.rb:216:in `perform_calculation' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/relation/calculations.rb:111:in `calculate' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/relation/calculations.rb:26:in `count' vendor/bundle/ruby/2.1.0/gems/activerecord-4.1.0/lib/active_record/relation.rb:241:in `size'
Work-AroundHere's a discussion Aggregate methods (empty?, any?, count) generate invalid SQL #13648 from less than a month ago where someone else is seeing the same problem: https://github.com/rails/rails/issues/13648
It's worth noting that the error does not occur when testing in the rails console. Apparently, the runtime environment has an effect on the size method.
The work-around suggested seems to work fine: successful_pings.count(:all) ... rather than successful_pings.size
Inline CommentsThis is an appropriate place to insert a TODO comment.
#TODO: Revert back to .size method after future Rails upgrade fixes bug # See https://github.com/rails/rails/issues/13648 #if successful_pings.size.eql?(0) # << revert back to this later if successful_pings.count(:all).eql?(0)
Things ChangeWe used to be able count on using the size method (no pun intended) to determine how many elements/rows were in an ActiveRecord collection.
Looks like size is not as reliable as count when it comes to ActiveRecord::Relations.