是否有一种数据库独立的方法来获取Ruby中的Db2 SQL结果？

Question

I have Rake code which I've cobbled together from some sample code in my shop, and the advice of another programmer. It looks more or less as follows:

class Ticket666StupidDb2Test < ActiveRecord::Migration
    def up
        lookup('WXYZ3529300')
    end

    def down
        puts "down, boy!"
    end

    def lookup(xiskid)
       qresult = exec_query("SELECT DISTINCT SNARK, GLOOPEE FROM VITA_XISK WHERE XISKID = '#{xiskid}'")
       while row = IBM_DB.fetch_array(qresult) do
           snark = row[0]
           gloopee = row[1]
           puts "snark = #{snark}; gloopee = #{gloopee}"
       end
    end
end

• Is there a way to use the result set column names in getting the data, instead of integer indices? I looked at http://rubyibm.rubyforge.org/docs/adapter/2.5.9/doc/ActiveRecord/ConnectionAdapters/IBM_DBAdapter.html and found at least one method, fetch_data , which seemed as though it would allow one to reference column names, but every attempt to try to use it produced an error such as:

   rake aborted! undefined method `fetch_data' for #<ActiveRecord::ConnectionAdapters::IBM_DBAdapter:0x38c16c0> 

• What is wrong with this code, which was my first attempt:

   x = exec_query("Select ... blah blah blah...") x.each do |row| puts row['SNARK'] end 

  This was modeled on stuff documented at http://api.rubyonrails.org/classes/ActiveRecord/Result.html , but it failed with a similar exception that x.each is undefined.

• Regardless, the notion that I have to resort to anything like IBM_DB.whathaveyou strikes me as obscene. Either IBM doesn't believe in making a standards conforming driver (not my experience using the Db2 driver for Java JDBC), or I just don't know what the supported, straightforward approach to this is.

Can someone tell me?

ruby -v returns ruby 1.9.3p545 (2014-02-24) [i386-mingw32] .

Answer 1

What is wrong with x = exec_query("Select ... blah blah blah...") ? If your query is not SQL compliant then you've tied yourself to the DBM and will have a lot more work when you need to migrate to some other DBM. That's the whole point of using an ORM, to separate the code from the query. It also means you'll need to stand up an instance of DB2 for development, test and production because your code can't adjust for scenarios like using SQLite for development locally, MySQL or PostgreSQL in test and DB2 in production. That's really easy with a good ORM.

Using or renaming IBM_DB isn't a significant issue in my experience. If you don't like calling it IBM_DB , assign that constant to another that is more visually pleasing. Sequel code typically uses DB but it's up to us what we want to call it. It's just a constant holding the connection information.

Having to index into an array is the result of using fetch_array . Typically, instead of using integers to identify fields, I'd define constants that are more symbolic/mnemonic and use them in place of the numbers. But, again, a good ORM makes it easy to use classes/models based on the table schema, adding layers of convenience and readability to isolate you from the uglier lower level driver's API.

Look at using Active Record or Sequel . Sequel supports DB2 nicely and is easily as powerful as Active Record and works with Rails. Both also work well in a non-Rails script; Sequel is my favorite for that but YMMV.