[erlang-questions] [ANN] Asynchronous PostgreSQL driver

[Max Bourinov]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111102/4771090a/attachment.htm>