Weirdness Problem Solved!!!

July 28, 2007 @ 3:12 pm · Filed under Uncategorized

When I posted at the Rails-Forum, I also emailed the internal DevChix list (sorry boys!) because I was totally at wits end about this problem. (got no response from Rails-Forum BTW) and at least I got some ideas...

Jen-Mei said to try this:

PLAIN TEXT
RUBY:
  1. Out of curiosity, when you run the Ruby console, what do you get when
  2. you type:
  3.  
  4. ActiveRecord::Base.connection.native_database_types[:string]
  5.  
  6. or just
  7.  
  8. ActiveRecord::Base.connection.native_database_types
  9.  
  10. ?
  11.  
  12. This is the array that ActiveRecord should be using to convert from
  13. the type you use in your migrations to database types.
  14.  
  15. I'm running MySQL 5. When I run it, I get:
  16.  
  17.                       >> ActiveRecord::Base.connection.native_database_types[:string]
  18.                        => {:name=>"varchar", :limit=>255}
  19.  
  20. Are you getting the same? The way it's running for you, it almost
  21. seems like it's returning nil or "string".

That worked as expected!! So that was not the problem...

Sandi M. had this idea:

PLAIN TEXT
RUBY:
  1. Looking in rails 1.2.3, I see that
  2.  
  3.     ActiveRecord::ConnectionAdapters::ColumnDefinition (1) has method
  4.       def sql_type
  5.         base.type_to_sql(type.to_sym, limit, precision, scale) rescue type
  6.       end
  7.  
  8. If this method raises an error, you'd get your original value back for the type.
  9.  
  10. It would be really interesting to go into this bit of code and change it to
  11.  
  12.       def sql_type
  13.         begin
  14.           base.type_to_sql(type.to_sym, limit, precision, scale)
  15.         rescue Exception => e
  16.           print e.backtrace.join("\n")   
  17.           raise "type_to_sql failed with #{e.class} #{e.message} for #{type}"
  18.         end
  19.       end
  20.  
  21. One would guess, looking at the type resolution code for various adaptors, that your install is missing, or didn't load, the adapter class which contains the type translation code for your database.  This backtrace should help locate the problem.

By this point, we had taken the conversation to instant messenger..

Hmm... so I saw it trying to work... I got an error saying argument error with expecting 4 params and only getting 2! Jen-Mei had me do a grep to see if type_to_sql is defined anywhere -- and AH HA.. there was a plugin -- mysql_bigint that was installed, and it had redefined the method and that was the culprit. This was a codebase that I inherited so I didn't even know what that plugin was used for or anything.

Here was the code in mysql-bigint plugin

PLAIN TEXT
RUBY:
  1. def type_to_sql(type, limit = nil) #:nodoc:
  2.           mysql_integer_types = %w{tinyint smallint mediumint intger bigint}
  3.         unless self.class.method_defined? :native_database_type
  4.           native = native_database_types[type]
  5.         else
  6.           native = native_database_type(type, limit)
  7.           limit = nil if mysql_integer_types.include? native[:name] # mysql doesn't use limit to indicate bytes of storage.
  8.                                           # Need to reassign native representation below.
  9.         end
  10.         limit ||= native[:limit]
  11.         column_type_sql = native[:name]
  12.         column_type_sql <<"(#{limit})" if limit
  13.         column_type_sql
  14.       end
  15.     end

Did a bit of research and found I had an old version installed:

http://www.northpub.com/articles/2006/10/29/new-version-of-mysql_bigint-rails-plugin
Quote from the site: "I received some feedback that edge Rails broke some things in the mysql_bigint plugin . I've checked in a new version that works correctly with edge rails. Thanks to Jamie Orchard-Hayes for a patch that fixed a few of these issues!"

So, I see there's a fix for it... but upon further investigation, the plugin is not use in the application at all! So I removed it for now.

Things I learned:

  • Check your plugins
  • Don't be afraid to dive into the rails code and print stuff to logs to see whats going on
  • Don't keep plugins laying around that are not in use
  • Probably a good idea to document what plugins are used and what for in the README
  • How to actually RUN the unit tests for rails (see the readme in the test dir), this way I knew for sure that my checkout of rails worked and it was something with my application code
  • DevChix ROCK!!

Leave a Comment