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

8daae60058e7022f2810d1059243abfd?d=identicon&s=25 Zeno Davatz (zeno_d)
on 2011-01-24 08:34
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
90a73d9875462aaa9fab2feffafbffe7?d=identicon&s=25 Ben Bleything (Guest)
on 2011-01-24 08:37
(Received via mailing list)
On Sun, Jan 23, 2011 at 11:34 PM, Zeno Davatz <zdavatz@gmail.com> wrote:
> the resulting error is:
>
> [snip]

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

Ben
8daae60058e7022f2810d1059243abfd?d=identicon&s=25 Zeno Davatz (zeno_d)
on 2011-01-24 09:11
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
8daae60058e7022f2810d1059243abfd?d=identicon&s=25 Zeno Davatz (zeno_d)
on 2011-01-24 09:33
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...

Best
Zeno
8daae60058e7022f2810d1059243abfd?d=identicon&s=25 Zeno Davatz (zeno_d)
on 2011-01-24 09:57
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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2011-01-24 13:42
(Received via mailing list)
On Mon, Jan 24, 2011 at 3:33 AM, Zeno Davatz <zdavatz@gmail.com> 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:
>
> http://dev.ywesee.com/wiki.php/Masa/20110124-setup...
>

Zeno,

Ben asked this:
On Mon, Jan 24, 2011 at 2:36 AM, Ben Bleything <ben@bleything.net>
wrote:
> On Sun, Jan 23, 2011 at 11:34 PM, Zeno Davatz <zdavatz@gmail.com> 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: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
8daae60058e7022f2810d1059243abfd?d=identicon&s=25 Zeno Davatz (zeno_d)
on 2011-01-24 14:02
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...

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
8daae60058e7022f2810d1059243abfd?d=identicon&s=25 Zeno Davatz (zeno_d)
on 2011-01-24 15:02
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...

may be related to this:

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

Best
Zeno
8daae60058e7022f2810d1059243abfd?d=identicon&s=25 Zeno Davatz (zeno_d)
on 2011-01-24 16:55
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
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.