[erlang-questions] PostgreSQL driver

[Christian S]

2007/12/2, YC <yinso.chen@REDACTED>:
> My point of a generic database interface is that there should be an effort
> to unify the interface ( i.e. methods, usages, etc) for the native drivers
> so the cost of moving between databases is minimized.  Not to say there
> can't be innovations and driver-specific methods, but having a common
> denominator is imperative from users' perspective.

You always get heavy dependencies on the db you pick, and you dont want to
have an api that is too least-common-denominator. It's more that the
basic things
should smell the same so you can reuse your knowledge of accessing
pgsql the day you
implement something that accesses mysql.

Anyway, to steer the thread elsewhere. Connection pooling:

Has someone implemented something like the following? I want feedback
and improvement ideas.

http://paste.lisp.org/display/51804 (in case the ascii art below
doesnt look good for you)

== Summary ==

When you have something that is expensive to set up you want to re-use
it. SQL db connections are typically expensive (slow) to set up.

SQL databases tend to have some form of concurrency, so you can gain
from having multiple connections to them.

So how do you solve the problem of having finite resources scheduled
on a first-come-first-use basis?

== Resource pool supervisor tree ==

|------------|
| Supervisor |
|-----+------|
      +------------------+
|-----+-------|  |-------+---------|
| Pool Master |  | Pool supervisor |
|-------------|  |-------+---------|
                         +--------------+
                 |-------+--|     |-----+----|
                 | Worker 1 | ... | Worker N |
                 |----------|     |----------|

== Example ==

When you want to do_stuff you stand in line for one of the N workers
by calling:

gen_pool:transaction(database, fun(Db) -> do_stuff(Db) end).

== How it would work ==

The Pool master populates the pool supervisor (simple one for one)
with dynamic workers, and workers register themself with the Pool
Master once they're started and ready to take jobs. The pool master
monitor workers so it can forget dead workers.

Perhaps the pool master should inform a worker about it being checked
out, and after it has been returned.