[erlang-questions] [ANN] Asynchronous PostgreSQL driver

Tim Watson watson.timothy@REDACTED
Wed Nov 2 04:31:59 CET 2011

On 1 November 2011 07:59, Dmitry Demeshchuk <demeshchuk@REDACTED> wrote:

> On Tue, Nov 1, 2011 at 10:16 AM, Max Lapshin <max.lapshin@REDACTED>
> wrote:
> > Anton, haven't you looked at modern mysql drivers? Maybe there is some
> > code to share, like connection pool.
> Just to mention, I have a small library that implements pools:
> https://github.com/doubleyou/gen_pool . Feel free to use it.
Are you using this in production Max? I'll take a look, for other purposes.
I've been looking at poolboy, which I think Riak uses - as well as the jobs
load regulation framework from Erlang Solutions, which is properly cool
although it takes some digging around in the code to figure out how to
extend it beyond the basic samplers that come OOTB.

> >
> > And also: I think it would be really very convenient to have something
> > like implicit connection:
> >
> >
> > epgsql:establish_connection(...)
> >
> > {ok, Result} = epgsql:query("SELECT * FROM articles ..");
> >
> >
> > Usually you are working with single database and perhaps it would be
> > good to have API for implicit singleton database connection.
> > Passing established connection to database through all levels of
> > business logic may be rather inconvenient sometimes and often
> > ends in having global variables.
> Or, rather, add an ability to use registered connections (or pools,
> which is even better):
> pgsql:connect(Name, Host, Port)
> and then
> pgsql:execute(Name, .....)
I do agree that it should be based on some kind of *named* access to the
database handle, rather than completely implicit. Doing a lookup isn't that
difficult and I suspect you could probably implement this functionality
easily using gproc to just store the pid.

Thinking about it from that point of view, doing this in a wrapper API
would be a bit better than implementing it for every database driver out
there, don't you think? Having started playing with OCI bindings (
https://github.com/hyperthunk/edbc_oci), I've been toying around with ideas
for building an Erlang DataBase Connectivity API, and I think things like
named connection handles (stored in gproc) would be well placed in
something like that so that individual drivers can remain simple (and take
the connection pid/handle in each call).

I think the secret to doing EDBC right is to build a very lightweight
application which does very little apart from starting up dependant apps
(like pgsql), resolving connection/statement handles and mapping the API
calls to the underlying implementation modules. All the other stuff
(caching, pooling, etc) needs to be application specific (albeit APIs for
that stuff would be nice too) and certainly shouldn't get implemented for
each and every driver implementation out there.

Just my 2 pennies anyway.


> ==========================================
> Here are some more thoughts:
> 1. It's kind of weird that you use such a sequence:
> {ok, C} = pgsql_sock:start_link(),
> pgsql_sock:connect(C, Host, Port, ...)
> It would be more consistent if you passed all the necessary parameters
> into pgsql_sock:start_link and initiated the connection in
> pgsql_sock:init/1, so it will look like:
> {ok, Pid} = pgsql_sock:start_link(Options)
> where Options is a proplist.
> 2. Using a proplist of options instead of listing these options (like
> host and port) as mandatory parameters may be reasonable.
> 3. It might be a good idea to use macros for default values (like
> timeouts, port number and so on).
> 4. I'd also consolidate pgsql_binary and pgsql_wire modules. Probably,
> also moved the functions with binary pattern matchings from pgsql_sock
> too. After all, the entire purpose is to describe the PostgreSQL
> protocol and it might be more convenient if it's handled by a single
> module.
> P.S. Sometimes I so hate that the 'query' atom is reserved...
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> --
> Best regards,
> Dmitry Demeshchuk
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111102/89f7dd93/attachment.htm>

More information about the erlang-questions mailing list