Friday, May 9, 2014

Why wouldn't you want to upgrade as soon as possible?

I can recall an IT director once asking me, "Why wouldn't you want to upgrade as soon as possible?"

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'


Here'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:

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 Comments

This is an appropriate place to insert a TODO comment.

    #TODO: Revert back to .size method after future Rails upgrade fixes bug
    # See
    #if successful_pings.size.eql?(0)   # << revert back to this later
    if successful_pings.count(:all).eql?(0)

Things Change

We 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.


No comments:

Post a Comment