Stored procedure OUT params in JRuby using Sequel

Question

I'm trying to call a stored procedure in a DB2 database that has output params and also returns a cursor. I can get this done using JDBC through JRuby, but I'd like to extend Sequel to do it, because of the nicer interface. I've gotten this far:

Sequel::JDBC::Database.class_eval do

  def call_test
    sql = "{call ddd.mystoredproc(?)}"
    result = {}
    synchronize do |conn|
      cps = conn.prepare_call(sql)
      cps.register_out_parameter(1, Types::INTEGER)
      result[:success] = cps.execute
      result[:outparam_val] = cps.get_int(1)
      if result[:success]
        dataset.send(:process_result_set, cps.get_data_set) do |row|
          yield row
        end
      end
      # rescue block
    end
  end

end  

This gets me a ResultSet that I have to work with in a very Java-ish way, though, not a nice Sequel::Dataset object. I know this code doesn't make sense - I'm just using it to experiment with values, so at one point I was returning the result hash and seeing what it contained. If I can get something that works, I will clean it up and make it more flexible. It looks like the log_yield method just logs the sql and yields to the block, so I don't know how anything else is getting converted to a Sequel::Dataset. Doing something like DB[:ddd__sometable] will return a dataset that I can loop through, but I can't figure out how and at what point the underlying Java ResultSet is getting changed over, or how to do it myself.

edit: Since Sequel::Database can create a dummy Dataset, and the Sequel::JDBC::Dataset has a private method that converts a result set and yields it to a block, the above is what I have now. This works, but I'm absolutely positive that there has to be a better way.

Sequel seems like the best database library for Ruby, which is why I'm trying to work with it, but if there are alternatives that are nicer than using straight JDBC, I'd like to know about them, too.

Answer 1

Sequel doesn't currently support OUT params in stored procedures on JDBC, so what you are currently doing is probably best.