[racket] Racket in the large
On 08/24/2011 12:18 PM, gonzalo diethelm wrote:
>>> 6. I think there is one thing missing in Racket, and this was also
>>> pointed out during the discussion: database drivers for major DBMSs (I
>>> would say at least Oracle, DB2 and SQL Server on the commercial front,
>>> and PostgreSQL, SQLite and MySQL on the open source front).
>>
>> My database package (ryanc/db) works for PostgreSQL, MySQL, SQLite
>> directly and Oracle and DB2 via ODBC. It should work with SQL Server also,
>> but I haven't tested that configuration.
>>
>> Docs are here:
>> http://planet.racket-lang.org/package-source/ryanc/db.plt/1/4/planet-
>> docs/db/index.html
>
> Great information, thanks. I take it this package works natively with
> PostgreSQL, SQLite and MySQL. Is it possible and "cheap" to make it
> work natively with other RDBMSs, such as Oracle?
It's certainly possible. I haven't looked at the Oracle C API(s), but I
would estimate it would take between one and two thousand lines of
Racket code. ODBC support, for comparison, currently takes about 1500
lines. More features, like interval types and asynchronous execution,
will add to that.
What benefits would "native" Oracle support provide (compared to ODBC)
to justify the cost?
>> > In addition to that, I think Racket would be greatly enhanced by a
>>> single relational data access layer that would hide the differences
>>> between specific RDBMSs and facilitate switching from one to another.
>>> (Note: I am not trying to dictate anything about Racket, just voicing
>>> my opinion).
>>
>> There are many things you might mean by that (ORMs, relational-algebra-to-
>> SQL compilers, etc). The concerns that Sigrid raised make me think that hiding
>> *all* the differences is a hopeless task, but maybe something with a
>> narrower focus could be useful. Are there any existing frameworks that
>> accomplish what you have in mind?
>
> You are right, my requirement is ambiguous. This is what I have in mind:
>
> 1. A set of abstractions (probably written in Racket) that allow you
> to interact with any RDBMS in a uniform way: select records, join
> tables, insert / update / delete data, etc. Hopefully you would have
> one or more DSLs to specify what you want to do, and not have to use
> strings (as in JDBC) for your commands. This should apply to all
> RDBMSs.
It sounds like you want some kind of abstract SQL syntax. I'll probably
try to do something like that.
> 2. A generic library (probably written in C / C++) that provides all
> the low-level trappings for #1.
> 3. A set of drivers (written in C / C++), one for each RDBMS, that #2
> uses when configured to talk to that particular RDBMS.
Why would I write C code when I could write Racket code? These are
currently done using Racket and, when necessary, FFI bindings.
Ryan