[ANN] Apache::DBI 0.0.20041025b

ruby-talk
1

Apache::DBI - DBI persistent connection library

···

===============================================
It works together with mod_ruby.
It holds DBI connection for every process of Apache.
From application, it can use transparent.

Requires
--------

* mod_ruby
* ruby-dbi

Install
-------

    # ruby setup.rb

Configuration
-------------

    httpd.conf:
      <IfModule mod_ruby.c>
        RubyRequire apache/dbi
      </IfModule>

    foo.rbx:
      require 'dbi'
      dbh = DBI.connect('dbi:Pg:foo',...)
            # returns pooled DatabaseHandle

Download
--------
<http://raa.ruby-lang.org/project/apachedbi/>

2

I'm interested in this, but can you explain what extra functionality it
gives over

[foo.rbx]
  require 'dbi'
  $dbh ||= DBI.connect('dbi:Pg:foo',...)

Thanks,

Brian.

3

Brian Candler wrote:

I'm interested in this, but can you explain what extra functionality it
gives over

[foo.rbx]
  require 'dbi'
  $dbh ||= DBI.connect('dbi:Pg:foo',...)

  [foo.rbx]
    require 'dbi'
    $dbh ||= DBI.connect('dbi:Pg:foo',...)

  [bar.rbx]
    require 'dbi'
    $dbh ||= DBI.connect('dbi:Pg:bar',...)

`$dbh` conflicts. This is not cool way.
Apache::DBI's advantage is transparent & simple.

4

  [foo.rbx]
    require 'dbi'
    $dbh ||= DBI.connect('dbi:Pg:foo',...)

  [bar.rbx]
    require 'dbi'
    $dbh ||= DBI.connect('dbi:Pg:bar',...)

$dbh conflicts. This is not cool way.

Well OK, but if you can't choose a unique global variable name, you could
instead write

  module ::MyPrivateStuff
    def self.dbh
      @dbh ||= DBI.connect('dbi:Pg:foo',...)
    end
  end
  dbh = ::MyPrivateStuff.dbh

Apache::DBI's advantage is transparent & simple.

I'm guessing now. Does your module keep a separate database instance for
each unique value of the DBI string? Or each unique combination of all the
arguments inside DBI.connect(...) ?

In other words, does it do something like

  $dbh ||= {}
  $dbh['dbi:Pg:bar'] ||= DBI.connect('dbi:Pg:bar')

Help me out here :slight_smile: I'm just trying to understand what it's doing, so I can
see whether I can make use of it.

If my guess is correct, then perhaps the pattern can be abstracted: e.g.

  dbh = Persistent[DBI, :connect, 'dbi:Pg:bar', ...]

and the implementation would be:

  module Persistent
    @things = {}
    def self.(*args)
      @things[args] ||= args[0].send(*args[1..-1])
    end
  end

Regards,

Brian.

5

Brian Candler wrote:

I'm guessing now. Does your module keep a separate database instance for
each unique value of the DBI string? Or each unique combination of all the
arguments inside DBI.connect(...) ?

Apache::DBI has each unique combination of all the arguments.

In other words, does it do something like

  $dbh ||= {}
  $dbh['dbi:Pg:bar'] ||= DBI.connect('dbi:Pg:bar')

Help me out here :slight_smile: I'm just trying to understand what it's doing, so I can
see whether I can make use of it.

If my guess is correct, then perhaps the pattern can be abstracted: e.g.

  dbh = Persistent[DBI, :connect, 'dbi:Pg:bar', ...]

and the implementation would be:

  module Persistent
    @things = {}
    def self.(*args)
      @things[args] ||= args[0].send(*args[1..-1])
    end
  end

I think that it is necessary to take into consideration that it is also peculiar to DBI, such as disconnet.

in future release, disconnected DBI instance(at DBI exception) is automatically delete from Apache::DBI cache.

6

I think that it is necessary to take into consideration that it is also
peculiar to DBI, such as disconnet.

in future release, disconnected DBI instance(at DBI exception) is
automatically delete from Apache::DBI cache.

OK, that's a useful feature to have. Perhaps also when you do DBI.connect
you could 'ping' an existing connection to ensure it is still alive, and if
not, reconnect.

I don't think that all DBI exceptions should cause a disconnection - but an
explicit disconnect, or an exception which indicates that the database was
disconnected (DBI::OperationalError?)

Regards,

Brian.