veader, the codemonky

Endless Pages

Having heard a blurb on an endless page plugin on the RailsEnvy podcast, I decided to check it out. I wasn’t happy with how the plugin worked, so I whipped up something similar.

(Original post mentioned on RailsEnvy: link)

I decided most of what was needed was a mix of the wonderful will_paginate plugin and some Javascript. Thus endlesspage.js was born.

After including endlesspage.js in your layout, you should be able to do follow along below on how to set it up.

In the Controller: pastie

In the Views: pastie

Here is the file: endlesspage.js

(Sorry, but I couldn’t get Tumblr to cooperate with dumping in code.)

Let me know if you find this helpful…

UPDATE: I was informed (and confirmed myself) that the gem version of will_paginate doesn’t have the page_count method. The substitute method is total_pages.

silencing deprecations

OK, so if you’re stuck in Rails 1.2.X land like I am, you’re probably tired of seeing all the deprecation warnings when you run your test suite. (Yes, I know pagination is going away but someone might severly punish me for will_paginate at the moment.)

 Add this to your test/test_helper.rb

 
 ActiveSupport::Deprecation.silenced= true 

Git on OSX

Hit a roadblock compiling git tonight. Thanks to jnewland for the last piece of the puzzle.

curl -O http://kernel.org/pub/software/scm/git/git-1.5.4.5.tar.bz2 
tar ixf git-1.5.4.5.tar.bz2 
cd git-1.5.4.5 
./configure --prefix=/usr/local 
make NO_MSGFMT=1 
sudo make install  

establish_connection may harm you

So I have a reporting Rails application that is looking at the databases of two other Rails apps. I import the models using an svn:external link. I then have initializers that do a bit of “magic” switching which databases the models use and what their table names are based on the schema. We use Postgres so the “databases” are actually schemas in the same physical database.

unless RAILS_ENV.downcase == 'test'
  # point all of the vanguard models to the champion_#{RAILS_ENV} database
  Dir[File.expand_path('app/models/vanguard/*.rb',RAILS_ROOT)].each do |file|
    model_str = $1.classify if file =~ /\/vanguard\/(.*?)\.rb$/

    next unless model_str
    # skip the models that aren't active record models
    next if %w(...).include?(model_str)

    eval("#{model_str}.instance_eval('establish_connection \"champion_#{RAILS_ENV}\"')")
    table_name = eval("#{model_str}.table_name")
    eval("#{model_str}.instance_eval('set_table_name \"vanguard.#{table_name}\"')") 
  end
end 

I kept running into a problem where the maximum number of connections to this database was being exceeded. After poking around some I believe establish_connection isn’t doing the smart thing. It seems to blindly establish a connection each time it is called disregarding the fact that the connection might already be open.

I switched the logic such that the “primary” database is now this external connection and sub-class all of my internal models to use an abstract ActiveRecord class that points to a different database. The number of connections has dropped significantly.

Ordering Matters

So I found another interesting gotcha in Rails today.

Some background: I have a reporting application that uses models from a running application that I can’t touch the code for for fear of the FDA overlords. In doing some of the reports, I want to “fix” things that were left out of the original application. For instance the office model should be associated with the patients that belong to it; however, this is not the case.

Knowing the fun of “monkey patching”, I can easily add this association in my action on the reporting app with something like:

Office.class_eval("has_many :patients")

Now office.patients works.

Then I wanted to have the count of patients for each office so I used the same trick to have a variable to stuff the count in, ala:

Office.class_eval("attr_accessor :patient_count")

Now office.patient_count = office.patients.count works like a charm.

Here’s where the gotcha occurred. I was actually putting a condition on the count.

offices.each do |o|
   o.patient_count = o.patients.count(1, :conditions => {:var => 'blah'})
end 

I noticed later that the conditions were being ignored. Odd…

Here was the problem. I had the attr_accessor class_eval statement before the has_many class_eval. For some reason the order matters. Switching the two made things happy.