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