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

Z

Zeno Davatz

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:in `execute'
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:in `do'
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:in
`initialize'
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:in `block
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:in
`block 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:in `block 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:in `method_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:in
`transaction'
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:in `block
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:in
`create_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:in `<module: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:in `require'
from /var/www/ramaze.ch.oddb.org/model/init.rb:3:in `<top
(required)>'
from /var/www/ramaze.ch.oddb.org/app.rb:32:in `require'
from /var/www/ramaze.ch.oddb.org/app.rb:32:in `<top
(required)>'
from start.rb:7:in `require'
from start.rb:7:in `<main>'

Any Feedback is more then welcome.

This did work with Ruby 1.8.6 and Ruby 1.9.1

Best
Zeno
 
Z

Zeno Davatz

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
 
Z

Zeno Davatz

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
 
R

Rick DeNatale

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

Zeno,

Ben asked this:
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: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
 
Z

Zeno Davatz

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
 
Z

Zeno Davatz

Ok just FYI we solved the problem. It again (after the Hash-Iteration
problem - thank you Chuck Remes) 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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,767
Messages
2,569,570
Members
45,045
Latest member
DRCM

Latest Threads

Top