digg

ar-extensions, Rails 2.x followup
on July 18, 2008 @ 01:41 AM

First things first, ar-extensions moved to Lighthouse and Github. So please no more tickets or patches on rubyforge. I’ll close out or move over the ones on rubyforge that currently reside there.

Now, the fun stuff.

ar-extensions and Rails 2.x compability

For the most part ar-extensions 0.7.0 (and below) is not compatible with Rails 2.0.x and 2.1. The import functionality works, but ar-extensions will bork on some edge cases of using ActiveRecord::Base.find methods. It won’t return the wrong value, it will simply raise an exception. So if you’re using ar-extensions in your Rails 2.x app, the app itself will probably bork (and I realize that you probably already know this). If you’re using the import functionality in isolation then you should be fine.

Some of the loading issues with ar-extensions that people had are due to ar-extensions being loaded during the time that Rails goes through the loading process (if you put require ‘ar-extensions’ in config/environments/development.rb, test.rb or production.rb). You can get around this by moving if after the Rails::Initializer.run block in your config/environment.rb file.

Tonight I made several commits to get ar-extensions closer to Rails 2.1.0 compatibility. HEAD right now is Rails 2.0.1 compatible, but not 2.0.2 or 2.1.0 compatible. As soon as ar-extensions is compatible I will release 0.8.0. I am hoping for it to be released within the next few days. And by compatible I mean that ar-extensions not only passes its own tests, but it also doesn’t break any of ActiveRecord’s tests.

3 comments

Jump to comment form | comments rss [?]
  1. Derek Willis 07.24.08 / 19PM

    Zach,

    I don’t think this rises to the level of a ticket, but I wanted to let you know that a work-around for Rails 2 that I’ve been using is to require ar-extensions after I call ActiveRecord::Base.establish_connection() in my rake tasks. When I put it at the top of a rake file, the rake task borks, but after I load the environment and make the db connection (I’m using MySQL 5) it works fine. Thanks for a great tool!

    Derek

  2. Vijay N 07.25.08 / 02AM

    Zach,

    Thanks for this nifty plugin. Is there an incompatibility between ar-extensions and acts_as_paranoid that you know of?. I get a mysql error such as ‘table_name’.’column_name_in’ or ‘column_name_ne’ when I use the _in/_ne suffix in the custom finder hash. The stack trace seems to have the following(which is what made me suspect the acts_as_paranoid relationship): abstract_adapter.rb:150:in `log’ mysql_adapter.rb:281:in `execute’ mysql_adapter.rb:481:in `select’ database_statements.rb:7:in `select_all_without_query_cache’ query_cache.rb:55:in `select_all’ base.rb:532:in `find_by_sql’ base.rb:1233:in `find_every_with_deleted’ vendor/plugins/acts_as_paranoid/lib/caboose/acts/paranoid.rb:124:in `find_every’ base.rb:1693:in `with_scope’ paranoid.rb:116:in `with_deleted_scope’ active_record/associations/has_many_association.rb:66:in `find’

    I am on rails 2.0.2, and I tried the head version on GIT with no effect. Also, the custom finder does appear to work with models that don’t have acts_as_paranoid!

    Vijay

  3. Vijay N 07.25.08 / 05AM

    Sorry, Please ignore the previous post. The error was entirely a usage issue. I didn’t have the right usage.

    Vijay