Simple DB Access
Wed Aug 2 23:51:34 CEST 2006
Being a long time developer on Oracle I now don't understand this
'prepare' concept. Every single SQL statement that takes in user
input should use bind variables. If this makes you have to prepare
statements, then so be it (our oracle API doesnt require prepares, but
forces us to use binds).
With binds you don't have SQL injection holes. It's as simple as that.
Say no to constructed SQL.
On 8/2/06, Christian S <> wrote:
> On 8/1/06, Mikael Karlsson <> 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
> 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.
> 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