Simple DB Access

Christian S chsu79@REDACTED
Wed Aug 2 22:41:50 CEST 2006


On 8/1/06, Mikael Karlsson <mikael.karlsson@REDACTED> wrote:
> I beleive there are some open source contributions that provide "direct"
> access to mysql and postgresql databases for Erlang.
> It would be nice if they could use the same api, something like jdbc for java
> etc. If they already not are doing this? How about and "edbc" application?
>
> /Mikael
>
> Refs:
> http://support.process-one.net/doc/display/CONTRIBS/Yxa
> http://jungerl.cvs.sourceforge.net/jungerl/jungerl/lib/pgsql/
>
>

It is somewhat tricky to coerce them into the same api. I was all set
to do it and a number of reasons made me unable to continue the work,
small ones like having my computer break, getting a fulltime job, but
mostly learning more about mnesia to solve things i only knew how to
do in sql previously. Also, I'm lazy.

One thing I learned from jdbc is that you will be bound to the
database of choice
(through things such as vendor specific features and database-side
extension functions) even though you have a database agnostic db
interface.

My conclusion, which seems to be close to other ones later in the
thread is that some kind of "edbc" (name as you suggested) application
is made, have it provide a few operations (least common denominator)
via all the different sql databases it knows of. One might want to
implement the sql92 syntax and a unified parametric-name syntax for
prepared statements, just to allow for prepared statements with every
db. SQL-injections are bad and we dont want people to resort to
primitively appending strings together. Such security vulnerability
WILL give erlang a bad rep, however innocent it is.

That would still allow me, and others interested, to hit the metal on
pgsql and use NOTIFY/LISTEN, for example. But simple apps without any
specific database requirement other than sql would work with whatever
edbc supports.

PS
A question. Is there any way to have multiple gen_servers under the
same name, and same node, and have the first one no busy serve my
gen_server:call ? If there is I find very little reason to support
connection pooling. I'd rather pool gen_servers that implement the
application's operations.



More information about the erlang-questions mailing list