<div class="gmail_quote">On 1 November 2011 07:59, Dmitry Demeshchuk <span dir="ltr"><<a href="mailto:demeshchuk@gmail.com">demeshchuk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Nov 1, 2011 at 10:16 AM, Max Lapshin <<a href="mailto:max.lapshin@gmail.com">max.lapshin@gmail.com</a>> wrote:<br>
> Anton, haven't you looked at modern mysql drivers? Maybe there is some<br>
> code to share, like connection pool.<br>
<br>
</div>Just to mention, I have a small library that implements pools:<br>
<a href="https://github.com/doubleyou/gen_pool" target="_blank">https://github.com/doubleyou/gen_pool</a> . Feel free to use it.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
><br>
> And also: I think it would be really very convenient to have something<br>
> like implicit connection:<br>
><br>
><br>
> epgsql:establish_connection(...)<br>
><br>
> {ok, Result} = epgsql:query("SELECT * FROM articles ..");<br>
><br>
><br>
> Usually you are working with single database and perhaps it would be<br>
> good to have API for implicit singleton database connection.<br>
> Passing established connection to database through all levels of<br>
> business logic may be rather inconvenient sometimes and often<br>
> ends in having global variables.<br>
<br>
</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Or, rather, add an ability to use registered connections (or pools,<br>
which is even better):<br>
<br>
pgsql:connect(Name, Host, Port)<br>
<br>
and then<br>
<br>
pgsql:execute(Name, .....)<br>
<br>
</blockquote><div><br></div><div>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. </div>
<div><br></div><div>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 (<a href="https://github.com/hyperthunk/edbc_oci">https://github.com/hyperthunk/edbc_oci</a>), 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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>Just my 2 pennies anyway.</div><div><br></div><div>Cheers</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">==========================================<br>

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