<div dir="ltr">Oh no, you mean, like, to do REAL work? :)<br>I'll try to find the latest version - my main server has something old and barely usable.<br><br>Wouldn't you like to spec a basic API first? That could be used one-to-one on the JNode proxy, for simplicity, as a thin wrapper.<br>
<br><br><div class="gmail_quote">On Mon, Aug 1, 2011 at 1:47 PM, Tim Watson <span dir="ltr"><<a href="mailto:watson.timothy@gmail.com">watson.timothy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On 1 August 2011 09:20, Alex Arnon <<a href="mailto:alex.arnon@gmail.com">alex.arnon@gmail.com</a>> wrote:<br>
><br>
> I agree, it does feel unnatural. However, in this case:<br>
> 1. It's rather simple, easy to make consistent and stable.<br>
> 2. It enables us to deliver immediate value to the customer... HELP I'VE GOT<br>
> ENTERPRISITIS!!!<br>
<br>
Ok fine, but I need to see your code in order to know how to plug it<br>
into any API we dream up. :)<br>
<br>
> But seriously:<br>
> 2. It makes any and all RDBMS's available, immediately.<br>
> 3. It's a fallback.<br>
><br>
<br>
Fine let's do it.<br>
<br>
><br>
> Right.<br>
> One beneficial side effect of streaming result sets is that it enables<br>
> processing enormous sets without blowing up your process/node.<br>
> Transformation/map/reduce/whichever is probably a good starting point.<br>
><br>
<br>
I agree that streaming result sets is useful and we'll put something<br>
in for that. I also want to do a basic "transform the result set using<br>
this function" API - let's have both.<br>
<br>
>><br>
>> Is your JDBC thing open source? I might have a stab at this just for<br>
>> fun - maybe fronting your library and the ESL postgres API as the<br>
>> first cut.<br>
>><br>
><br>
> It was a prototype, got to the<br>
> usable-but-hell-no-you're-not-seeing-this-pile stage. :)<br>
> I don't think I've even updated my main repo with the last changes in a few<br>
> months.<br>
><br>
> Basically what I did was:<br>
> 1. register a global controller (edbc_master). This is optional, meant to be<br>
> used for general monitoring of the connection processes.<br>
> 2. Each connection is an {Erlang process, JNode} pair, linked to its<br>
> creator/user and registered with 'edbc_master'.<br>
>     The connection is started with a configuration such as:<br>
>     { { proxy_dir, "c:/dev/edbc/java/deploy" },<br>
>       { driver_class, "com.oracle.xxx.yyy.OracleDriver" },<br>
>       { hostname, "localhost" },<br>
>       { port, 4444 },<br>
>       ...<br>
>       other connection-stringy stuff<br>
>     }<br>
> 3. The Controller process (the linked Erlang process) gets a "unique" node<br>
> name for the JNode from the edbc_master, and spawns it.<br>
> 4. A basic handshake with X-second timeout between the Controller process<br>
> and a counterpart on the JNode (registered as 'edbc_proxy' on the JNode I<br>
> think) is done, including adding monitors on success.<br>
> 5. From this point on, operations are forwarded via the Controller to the<br>
> JNode, which executes them, packages up the results and sends them back.<br>
><br>
> What I've done is somewhat crude - a process per connection etc., no proper<br>
> support for most datatypes - but it was just a couple of days' work to get a<br>
> simple SELECT/UPDATE/INSERT working. And it would work on Oracle, MSSql,<br>
> Postgres, MySQL, Sybase, what have you.<br>
><br>
><br>
<br>
Yeah I'm terribly well versed in JDBC and have a vague inkling of how<br>
JNodes work, so that's all fine. Like I said, let's glue together a<br>
basic API and plug it into your thing and one other popular API -<br>
perhaps the OTP odbc application would actually be the best thing<br>
alongside yours - and then we'll go from there. Once we have something<br>
working we can come back here and ask the community for input.<br>
</blockquote></div><br></div>