Re: db interface (was Re: Scheme is too complicated)

[Craig Brozefsky <craig@onshore.com>]

Sascha Ziemann <szi@aibon.ping.de> writes:

> > - More concise syntax for generating SQL than a series of string
> >   manipulations.
> 
> When you forget a required keyword, you will get the same error like
> that from a broken SQL query. Where is the difference?

Only if the code for doing this is completely lame.  There is no
reason why I can't throw a scheme exception if you forget to tell me
what table(s) to query against, or if you want me to return a field
that doesn't exist.  Tons of libraries do checking like this. The fact
that we're generating SQL does not somehow render impotent schemes
argument checking.

> > - Keywords make it easier to trigger various options in sql, and to
> >   setup your query. You don't have to deal with SQLs syntax like makin
> >   sure you don't put a comma after the last value in a list, etc...
> 
> Do you expect someone knowing about inner joins without knowing SQL?

This is not just for people who know nothing about SQL, it's for
anyone wanting to generate SQL programmatically, without having to
re-invent the same set of string bashing funcs that everyone else will
be making.

> > - Unified syntax for generating most SQL, would be independent of the
> >   backends incompatabilities.  So like in postgresql, I think the
> >   outer-join syntax is different than some other DBs.
> 
> If so, someone should fix that bug in Postgres.

Dewd, there are some many incompatabilities and tweakosities between
the myriad different DB vendors that this disagreement makes so little
sense.  Besides the fact that most DB systems only track an old SQL
standard, and nearly all of them are incomplete or have some set of
incompatabilities unless you stick within a very strict subset of
SQL.

> > - let's us do nice things like the example I previously gave with
> >   find-if and remove-if.
> 
> You can do nice things only when you do them in Guile. The normal
> database situation is, that the database and Guile do not run on the
> same system. Furthermore SQL is the only standardized way to access a
> database. If you don't want to kill you local network, you have to do as
> much as possible in SQL. This leeds to the situation, that you can use
> Guiles cleverness only for the query results. So even if you write a
> wrapper in Guile, which produces SQL, you will not be able to do more
> than SQL lets you doing.

Obviously, and I made no claim otherwise.  But find-if and other
set operations can be mapped onto SQL without much head scratching,
and make thier representation more concise and readable.

> >   (select       :fields '(field-list)
> >                 :from '(table-list)
> >                 :join-type 'inner
> >                 :qualifier (= fieldname value))
> 
> Why do you think that a query becomes easier when you throw away the
> grammatical structure of normal SQL queries?

Because schemes grammer is much nicer than SQL's.  no annoying commas
to remember, sub queries and things of that nature can be easily
identified by their encasing in parenthesis. Because parts of the
query can be identified with keywords.  Because I can produce the
query programmaticaly and thus abstract out he annoying and repetitive
parts of write out an sql query (field lists and that shit).  Lastly,
it's not scheme.

Perhaps your thinking that there will be no way for you to send a
straight SQL string to the DB backend.  This is not true.  I'll I'm
proposing is that a library for generating SQL queries
programmatically be produced, so that not everyone has to invent them,
so that using SQL DBs from scheme is more enjoyable.

As far as usability and utility, having done alot of DB work, I found
that I usually ended up writing this stuff over and over again, as I'm
sure alot of other people did.  The NeXT Enterprise Object Framework
has something similiar, with it's "Qualifiers", which while crushed
under the weight of object stupidity at times, is EXTREMELY useful if
your trying to abstract away from your data store.

Your comments ad concerns are appreciated, but it seems that someone is
going to build this stuff anyways.