Strange AR error ( column does not exist)

I’m trying to deploy a Rails app on a platform using Thin, after some
horrible sessions trying to make it work with fcgi. All is going well,
but my Application controller throws this error:

ActiveRecord::StatementInvalid (PGError: ERROR: column “firstpeer”
does not exist
LINE 1: SELECT * FROM “switches” WHERE (firstPeer = 15 OR
secondPeer…
^
: SELECT * FROM “switches” WHERE (firstPeer = 15 OR secondPeer =
15) ):

AR is complaining that there is no column “firstpeer”. I’m not sure if
the fact that it is all lower case has any significance. The actual
column is named “firstPeer”, as visible in the SQL log lines.

The source line that gives rise to the error:

switches = Switch.all(:conditions => [‘firstPeer = :myID OR secondPeer
= :myID’ , {:myID => @chatter.id}])

Nevertheless, the following line in an initializer does get executed w/
o problems:

switch = Switch.create(:firstPeer => chatter.id , :secondPeer =>
peer.id, :distance => dist)

and evaluating “Switch.all” in the console, I get:

[#<Switch id: 1, firstPeer: 1, secondPeer: 2, created_at: “2009-02-22
17:11:26”, updated_at: “2009-02-22 17:11:26”, distance:
1235986.83901638>, " etc

Locally I use Mongrel + MySQL, whereas the server I’m deploying to
runs Thin and PostgreSQL. I’m also using the Spawn plugin. None of
this seems likely to be the problem.

Any help or suggestions would be very much appreciated.

On Feb 22, 8:39 pm, Felixyz [email protected] wrote:

I’m trying to deploy a Rails app on a platform using Thin, after some
horrible sessions trying to make it work with fcgi. All is going well,
but my Application controller throws this error:

ActiveRecord::StatementInvalid (PGError: ERROR: column “firstpeer”
does not exist
LINE 1: SELECT * FROM “switches” WHERE (firstPeer = 15 OR
secondPeer…

Well I don’t know pg much, but

says that unquoted names are folded to lowercase.

Fred

Changing the column name from firstPeer to first_peer helped. Apparently
postgre, as you pointed out, couldn’t handle the camel case but
automatically lower cased it. This was not any fault of AR’s. On the
contrary, in the code where I let AR create the SELECT, the field name
was
handled correctly, in a way that postgresql could understand.

Thanks Fred!

2009/2/22 Frederick C. [email protected]