<div dir="ltr"><br><br><div class="gmail_quote">On Sun, Jul 31, 2011 at 10:10 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;">
<div class="im">><br>
> I agree with the sentiment. Java will indeed usually get the least friction<br>
> for any implementation, which for the Enterprise-minded is usually reason<br>
> enough to use it for everything.<br>
> However, in many places one could find instances where building at least a<br>
> prototype in Erlang might be the Right Thing. Several back-end or even<br>
> front-end services I have built I would certainly have knocked up in Erlang<br>
> very rapidly, just as an idea to Show The Boss or even as a real deployment<br>
> candidate. In all these instances, the database was either Oracle or MS-SQL,<br>
> with reasonably low DB access performance expectations.<br>
> Now, like you said above, just dropping into another VM for whatever service<br>
> is going to "look bad". Certainly if you've really built it from scratch for<br>
> your pet project, but what if we were talking about something that's been<br>
> battle-proven? That maybe speaks Enterprise lingo? Maybe put a nice face on<br>
> it, for instance - add a RESTful JSON interface or something, as a<br>
> diversion? :) Like you said, the Enterprise is often willing to take a lot<br>
> of crap just to have something that looks "standard" - and deploying a Lean<br>
> JDBC Proxy can go down relatively easily.<br>
><br>
<br>
</div>I've written a few real production systems in Erlang, but they were<br>
all OSS applications and it was the right fit. Even in a telco, most<br>
BSS applications tend not to be written in Erlang. I'm not saying<br>
that's right or good - I personally would rather build something in<br>
Erlang than Java - but there we have it.<br>
<div class="im"><br>
><br>
> Right.<br>
> Something that I'd use the JDBC Proxy Abomination suggested above is a<br>
> fallback. In that case, you're not expecting blazing performance - however,<br>
> you'll have a stable backend to bang your API out on. Gradually adding clean<br>
> Erlang backends can come later.<br>
><br>
<br>
</div>Yeah I get that it will work ok, it just feels a bit weird not to use<br>
existing native implementations that are known to work. ESL have a<br>
postgres driver which I'm assuming (?) is used in production<br>
applications. The database support for Zotonic is also very solid in<br>
my experience. As I said, a guy at work wrote a driver based Oracle<br>
back end and it's absolutely rock solid in production - the app quite<br>
data access centric and has never once failed in the last 3 years<br>
whilst it deals with a reasonable load (avg. few thousand<br>
regular/daily users with peak times dipping into five figures).<br>
<div class="im"><br></div></blockquote><div><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 ENTERPRISITIS!!!<br>
But seriously:<br>2. It makes any and all RDBMS's available, immediately.<br>3. It's a fallback.<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
><br>
> I think that's spot on.<br>
> Neither should they change this approach.<br>
> If you want to leap forward in language/tool technology in the Enterprise,<br>
> there's always stuff like Scala (which is an excellent step up from Java,<br>
> and starting to get some Traction).<br>
><br>
<br>
</div>Like I said, we use Erlang at work where it's deemed appropriate.<br>
Nobody there thinks Erlang "is a ghetto" but they do see it as niche<br>
and the fact that they pay sub contractors a lot more for it than bog<br>
standard Java applications is something they think about a lot. Having<br>
said that IMHO the fact that these Erlang based systems never seem to<br>
go wrong is testament to what I call the "you get what you pay for"<br>
effect combined with "some tools are better than others". Just my<br>
opinion though.<br>
<div class="im"><br>
><br>
> AFAICT, the existing APIs are similar to a severely cut-down JDBC API. So<br>
> nothing very surprising there - I'm guessing most (if not all) have been<br>
> built on a per-need basis.<br>
<br>
</div>That's why I'd like to start by fronting a well established API - like<br>
the ESL postgres driver - just to see what's already there and build<br>
on it in the general case.<br>
<div class="im"><br></div></blockquote><div><br>OK.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> I agree that one should try to veer as much away from heavily-stateful APIs,<br>
> and this can probably be avoided.<br>
<br>
</div>Yes - just avoiding exposing internal data structures by providing a<br>
handle is probably enough to do this. The various modules can actually<br>
return whatever (real state if required) but the API should just hide<br>
this by exporting opaque types only:<br>
<br>
-opaque connection_handle :: term().<br>
-export_type([connection_handle/0]).<br>
<div class="im"><br>
> However, since we ARE dealing with RDBMS's, some of the flavour of using<br>
> them is bound to come through the API - connection pooling, transactions and<br>
> error handling/reporting should definitely be part of any API that expects<br>
> to be widely useful. I'd also add an Erlang-y flavour to some operations,<br>
> like streaming of result sets, to work with the platform's grain and not so<br>
> much against it.<br>
><br>
<br>
</div>Yes all these things (pooling, transactions, etc) are necessary. I<br>
maintain that you can provide them to the user without the<br>
implementation details leaking though.<br>
<br>
I also agree with the notion of having operations that are Erlang-y.<br>
Not sure what the best thing to do with streaming result sets would<br>
be, but I suspect looking at the existing implementations would<br>
clarify what people expect to see. For sure you don't always want to<br>
have to wait until the entire result set has been processed before you<br>
can do anything. I do think having operations that convert result sets<br>
using some transformation fun/function would be useful though - you<br>
might think of there as the Erlang equivalent of the Spring Framework<br>
JdbcTemplate ResultSetConverter or RowMapper interfaces. Except in<br>
Erlag you just a function, plain and simple.<br>
<br></blockquote><div><br>Right.<br>One beneficial side effect of streaming result sets is that it enables processing enormous sets without blowing up your process/node. Transformation/map/reduce/whichever is probably a good starting point.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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></blockquote><div><br>It was a prototype, got to the 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 months.<br><br>
Basically what I did was:<br>1. register a global controller (edbc_master). This is optional, meant to be used for general monitoring of the connection processes.<br>2. Each connection is an {Erlang process, JNode} pair, linked to its 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 name for the JNode from the edbc_master, and spawns it.<br>
4. A basic handshake with X-second timeout between the Controller process and a counterpart on the JNode (registered as 'edbc_proxy' on the JNode I think) is done, including adding monitors on success.<br>5. From this point on, operations are forwarded via the Controller to the 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 support for most datatypes - but it was just a couple of days' work to get a simple SELECT/UPDATE/INSERT working. And it would work on Oracle, MSSql, Postgres, MySQL, Sybase, what have you.<br>
 <br></div></div><br></div>