[erlang-questions] [ANN] Asynchronous PostgreSQL driver

[Dmitry Demeshchuk]

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.

The answer it "yes" and "no". It's almost the same code that we use in
production for Riak pools, but I abstracted it as a pool for
everything. And instead of simple_riak_pool, we use a more
sophisticated one, with some use of our internal framework.


>
>>
>> >
>> > 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
>
>



-- 
Best regards,
Dmitry Demeshchuk