This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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

> I would not prefer a wrapper around SQL.  That has the following
> disadvantages:
> 
>   - This is a mapping from a functional to a declarative
>     language.  This job is complicated and probably impossible.

I don't buy that one, since scheme can support declarative, object
oriented and functional as well as a whole host of other styles of
programming.  I'm not sure why you think this is so difficult:

(insert '(list of values)
	tablename)

(with-cursor blah
  (select	:fields '(field-list)
		:from '(table-list)
		:join-type 'inner
		:qualifier (= fieldname value))
  (do ((val (at-point cursor) (at-point cursor)))
	((= val 0) #t)
       (display "The name is: ")
       (display (field-value "name" val ))
       (newline)))

I wouldn'texcept you to hit every feature of sql-92 or whatever the
majority of DBs out there are supporting now adays, but you
could surely hit enough to hit probably 99% of the projects out
there.

>   - Someone must write it.

Someone has to write everything...

>   - Everybody must learn it.

They have to learn something anyhow, and this is hardly an excuse.

>   - It makes it probably impossible to use some DB special features.

There is no reason why the only way to generate sql for the interface
has to be thru this nice schemified manner.

> And now the advantages:
> 
>   - ?

- More concise syntax for generating SQL than a series of string
  manipulations.

- 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...

- 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.

- let's us do nice things like the example I previously gave with
  find-if and remove-if.

- People would just do it anyways, so why not let everyone benefit from
  having the same base to work from.

- Makes interfacing with table and DB metadata easier because instead
  of an unorganized bunch of string formatting, you have a
  programmatic interface that can do type checking and other
  verification using what it knows about the tables, the DB backend
  and the fields.

I can think ofsome more, but I gotta get ready for a bike ride.