Pg gem 0.10.1 wth Ruby 1.9.2 does not work with method @pg_conn.exec_prepared(stmt_name, parameters)

dubstep · January 24, 2011, 8:34am

Hi

The pg gem 0.10.1 does not seem to work with Ruby 1.9.2 with the method
@pg_conn.exec_prepared(stmt_name, parameters)

This does work:

C:\Users\Luis\Projects_sandbox>irb
irb(main):001:0> require ‘rubygems’
=> true
irb(main):002:0> require ‘pg’
=> true
irb(main):003:0> conn = PGconn.open(:dbname => ‘test’, :user =>
‘postgres’, :password => ‘’)
=> #PGconn:0x2c9a198
irb(main):004:0> res = conn.exec(‘SELECT 1 + 2’)
=> #PGresult:0x2bc0698
irb(main):005:0> res.getvalue(0,0)
=> “3”

But this method does not work:

@pg_conn.exec_prepared(stmt_name, parameters)

the resulting error is:

from /usr/lib/ruby/gems/1.9.1/gems/dbd-pg-0.3.9/lib/dbd/pg/
statement.rb:37:in execute' from /usr/lib/ruby/gems/1.9.1/gems/dbi-0.4.2/lib/dbi/ base_classes/database.rb:96:inexecute’
from /usr/lib/ruby/gems/1.9.1/gems/dbi-0.4.2/lib/dbi/
base_classes/database.rb:114:in do' from /usr/lib/ruby/gems/1.9.1/gems/dbi-0.4.2/lib/dbi/handles/ database.rb:106:indo’
from /usr/lib/ruby/site_ruby/1.9.1/odba/storage.rb:176:in
create_index' from /usr/lib/ruby/site_ruby/1.9.1/odba/index.rb:226:ininitialize’
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:148:in new' from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:148:inblock
in create_index’
from /usr/lib/ruby/site_ruby/1.9.1/odba/storage.rb:558:in
call' from /usr/lib/ruby/site_ruby/1.9.1/odba/storage.rb:558:inblock in transaction’
from /usr/lib/ruby/gems/1.9.1/gems/dbi-0.4.2/lib/dbi/handles/
database.rb:209:in transaction' from /usr/lib/ruby/site_ruby/1.9.1/odba/connection_pool.rb: 36:inblock in method_missing’
from /usr/lib/ruby/site_ruby/1.9.1/odba/connection_pool.rb:
26:in next_connection' from /usr/lib/ruby/site_ruby/1.9.1/odba/connection_pool.rb: 35:inmethod_missing’
from /usr/lib/ruby/site_ruby/1.9.1/odba/storage.rb:554:in
transaction' from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:520:intransaction’
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:140:in
create_index' from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:131:inblock
in create_deferred_indices’
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:125:in each' from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:125:increate_deferred_indices’
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:437:in
setup' from /usr/lib/ruby/site_ruby/1.9.1/oddb/persistence/odba.rb: 35:inmodule:ODDB’
from /usr/lib/ruby/site_ruby/1.9.1/oddb/persistence/odba.rb:
28:in <top (required)>' from /var/www/ramaze.ch.oddb.org/model/init.rb:3:inrequire’
from /var/www/ramaze.ch.oddb.org/model/init.rb:3:in <top (required)>' from /var/www/ramaze.ch.oddb.org/app.rb:32:inrequire’
from /var/www/ramaze.ch.oddb.org/app.rb:32:in <top (required)>' from start.rb:7:inrequire’
from start.rb:7:in `’

Any Feedback is more then welcome.

This did work with Ruby 1.8.6 and Ruby 1.9.1

Best
Zeno

zeno_d · January 24, 2011, 8:37am

On Sun, Jan 23, 2011 at 11:34 PM, Zeno D. [email protected] wrote:

the resulting error is:

[snip]

You don’t actually show the exception, only the backtrace. What is the
actual error?

Ben

zeno_d · January 24, 2011, 9:11am

Dear Ben

Thank you for your reply.

That is what we are trying to find out ourself. ODBA our software - at
start up of our software - checks if the tables of the database are
there or not. When checking one such table we guess (our traceback) ODBA
fails at the method

@pg_conn.exec_prepared(stmt_name, parameters)

Normally ODBA would find all the tables and then load the data into the
cache. But since Ruby 1.9.2 ODBA stops at the above point.

What is the actual difference between dbd-pg and pg?

Best
Zeno

zeno_d · January 24, 2011, 9:33am

Dear Ben

We could trace the error down as far as to this file:

/usr/lib64/ruby/gems/1.9.1/gems/pg-0.10.1/ext/pg.c

and that files source is C. For a full list of steps, please see:

http://dev.ywesee.com/wiki.php/Masa/20110124-setup-ramaze#Result

Best
Zeno

zeno_d · January 24, 2011, 9:57am

Ok, it seems that this again is related to some subtle changes from Ruby
1.9.1 to Ruby 1.9.2. So we are now digging back into ODBA and comparing
both processes on Ruby 1.9.1 and Ruby 1.9.2 on Linux.

Freaks me out this inconsistency in Ruby 1.9 itself!

Best
Zeno

zeno_d · January 24, 2011, 2:02pm

Dear Rick

Thank you for your reply.

We are back-tracing now. It is not that simple.

It is due to a difference in Ruby 1.9.2 and Ruby 1.9.1 as we guess.

If you look at this:

http://dev.ywesee.com/wiki.php/Masa/20110124-setup-ramaze#fork

Then you see that Ruby 1.9.1 returns a “true” and Ruby 1.9.2 returns a
“false” so we need to know where that takes us.

Still working on it. Now we are looking into dbi.

Best
Zeno

zeno_d · January 24, 2011, 1:42pm

On Mon, Jan 24, 2011 at 3:33 AM, Zeno D. [email protected] wrote:

Dear Ben

We could trace the error down as far as to this file:

/usr/lib64/ruby/gems/1.9.1/gems/pg-0.10.1/ext/pg.c

and that files source is C. For a full list of steps, please see:

dev.ywesee.com - Masa/20110124-setup-ramaze

Zeno,

Ben asked this:
On Mon, Jan 24, 2011 at 2:36 AM, Ben B. [email protected]
wrote:

On Sun, Jan 23, 2011 at 11:34 PM, Zeno D. [email protected] wrote:

the resulting error is:

[snip]

You don’t actually show the exception, only the backtrace. What is the
actual error?

Not sure why you broke the threading by the way.

You seemed to miss his question, he was asking for the actual
exception which was raised, not just the backtrace.

From your link this would appear to be:

/usr/lib64/ruby/gems/1.9.1/gems/dbd-pg-0.3.9/lib/dbd/pg/statement.rb:71:in
`rescue in execute’: ERROR: relation “oddb_business_company_name”
already exists (DBI::ProgrammingError)

This doesn’t look like a bug in the pg gem or in Ruby 1.9.2, but with
the prepared statement you are executing or the state of the database
when you execute it.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

zeno_d · January 24, 2011, 3:02pm

Ok, it seems this is related to dbi (0.4.5) and the way Ruby 1.9.2
handles the block-Argument-scope vs Ruby 1.9.1. dbi uses this.

see the read read lines here:

http://dev.ywesee.com/wiki.php/Masa/20110124-setup-ramaze#dbi_while

may be related to this:

http://mng.iop.kcl.ac.uk/site/node/617

Best
Zeno

zeno_d · January 24, 2011, 4:55pm

Ok just FYI we solved the problem. It again (after the Hash-Iteration
problem - thank you Chuck R.) was in dbi. What we had to do is force
the Array in dbi, as so:

/usr/lib64/ruby/gems/1.9.1/gems/dbi-0.4.5/lib/dbi/handles/statement.rb

we changed

#fetched_rows.push(row)

to

fetched_rows.push(row.to_a)

This works for us in Ruby 1.9.1 and Ruby 1.9.2

We do not have a clue so far why this works in Ruby 1.9.2 and in Ruby
1.9.1 but it does work for us.

Thanks for all your help so far and let us know if you know why this
is needed for Ruby 1.9.2 to work.

We will also investigate further.

Best
Zeno