Simple DB Access

[Christian S]

On 8/5/06, Ryan Rawson <ryanobjc@REDACTED> wrote:
> example, most libraries which implement the oracle 'wire protocol'
> can't handle things like RAC.

Some kind of redundancy or replication feature? I stay as far away from oracle's
price model as possible. :)

> As for the atom thing - you can't have a SQL statement as an atom.  I
> dont think a 5000 character atom is really supported well.  SQL
> statements do get that big.  Typically a few hundred chars - still not
> really atom-land.  Like I said, just hash the string and use that as a
> unique key into a table of prepared statements.  Or whatever.

I meant an atom that names a statement that has been previously
defined. Think "register_statement" from a few mails back.

execute(SQLText, Binds) when atom(SQLText) ->
  execute_registered(SQLText, Binds);
execute(SQLText, Binds) ->
  execute_parse(SQLTEXT, Binds).

Since it leaves the possibility of placing all the sql strings at one
place in the code, making code a bit more readable:

{ok, [Balance]} = execute(balance, [Account])

And still be able to do oneshots: execute("DELETE FROM foo", [])

> As for the SQL 92 parser - that is a little unnecessary.

I thought it would be nice if one could smooth over that different
rdbms use different syntax for parameters to be bound. Imagine if I
write my code as

edbc:execute("SELECT * FROM foo WHERE id = $1", [Id])

and what keeps it from running on SQL-omatic-3000 is that the proper
syntax there is

edbc:execute("SELECT * FROM foo WHERE id = @1", [Id])

There are probably cheaper ways to get uniform syntax there. Maybe
thinking outside the string could be the solution, I dont feel
intelligent enough to evaluate this idea this late:

edbc:execute(["SELECT * FROM foo WHERE id = ", param], [Id])

> As for the returning tags to indicate the kind of result, that sounds
> good - probably better than my thought :-)

I wonder if all rdbms do that though. If one doesnt, it will be
impossible to write a fully transparent edbc backend for it.

> Again, re: transactions, never ever ever assume people will only need
> auto-commit mode.  I can't stand that - transactions are THE reason to
> use a RDBMs.  Otherwise just use BDB (which supports transactions
> btw).  Ok, data richness too, but ssssh.

Yes, and on the topic of that. A mnesia:transaction like interface to
transactions is nice, I would think? It hides the dynamic-unwind from
API-user's code.