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)


Jim Blandy <jimb@red-bean.com> writes:

> I would expect a good design to support both: the ability to send SQL
> commands directly, and something for cleanly and reliably building
> them under program control.

Absolutely.

> Why not just have the database interface accept raw strings, and
> provide another module for constructing those strings nicely?

While it is true that we can seperate them into different modules, and
they almost definetly will be, I do think that their designs need to
mesh well.

The SQL generation module, depending on complexity, will need to know
a certain amount about the DB backend, and the table sets.  We need to
ensure that the DB interfaces support a minimum level of meta-data
about the DB backend.

Also, it would seem that the ideal interface would be built on top o
the base driver level access, and the sql generation module.  So that
we can have constructions like the (sql-find-if) and (select) with the
higher level syntax for generatin their underlying SQL.

So I would propose a three step process:

1. Start generating drivers for various free DBs, which provide an
   interface for querying about the backends features, and the format
   of tables and their fields and types.  JDBC may be a good place to
   start, not so much for structure of the interface, but for it's
   relative thoroughness in meta-data.  I'm not sure how keen DBI is
   on this.  Perhaps someone can come up with a reference
   implementation based on a popular free database, so that other
   implementors know what they should aim for.  It should consider the
   suggestions made by myself and others with regards to resource
   management, and ease of use.

2. Create a few macros for the SQL generation, with SQL syntax
   checking only, don't worry about verifying field lists and the like
   for now. This can probably be pulled off in a day covering 90% of
   what people use SQL for in one or two nights.  Just wanna cover
   selects, inserts, delete, and updates for now.

3. Standardize the driver level interface, and begin to integrate the
   SQL generation and the driver metadata, as well as results and
   error handling.  This should give us a very nice high level
   interface to databases, but allow people to stick their nose in
   anywhere along the chain.  It also lets us get things into thehands
   of users quickly.

Typical Heideggerian development model, nyuk nyuk.