[erlang-questions] [ANN] Asynchronous PostgreSQL driver

[ypaqt2vte6jo8@REDACTED]

There is also epgsql_connpool which supports growing and shrinking the number of connections. We use it in production after we had some problems with epgsql_pool. 

https://github.com/tholschuh/epgsql_connpool

Cheers
- Tilman

On 2011-11-02, at 12:32 AM, Max Bourinov wrote:

> 2Tim:
> 
> yes, I do use it i production although it has in code one function call that doesn't exists in epgsql. End of next week I will find some time for fork it and clean it up a little bit. If you are interested in epgsql_pool - you can find some benchmarks and reviews over the web. I read them and they were quite positive, so I drop it in production and so far it works :-)
> 
> Best regards,
> Max
> 
> 
> On Wed, Nov 2, 2011 at 6:31 AM, Tim Watson <watson.timothy@REDACTED> wrote:
> 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.
> 
> Cheers
>  
> ==========================================
> 
> 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
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions