source: project/wiki/dbi @ 9079

Last change on this file since 9079 was 9079, checked in by svnwiki, 13 years ago

Changes applied for Vincent Manis ( through svnwiki:

Changed my comment about SQL null representation.

File size: 2.7 KB
1== Database Interface Discussion
3=== Proposed Interface
5; <procedure>(dbi:connect TYPE #!key FILE PORT USER PASS etc)</procedure> : Connect to a database. TYPE is a symbol, like mysql, postgres, sqlite, etc. Returns a connection object.
6''Possibly put the type, file, and port info into a URI-type string as JDBC does? That would make
7the whole thing a lot more extensible; it would be nice to do it both ways, having the separate keyword parameters also. -- vincent''
9; <procedure>(dbi:query CONNECTION SQL)</procedure> : Query the database (see the mysql egg)
11; <procedure>(dbi:num-rows CONNECTION)</procedure> : Return the number of rows produced by the last query (see mysql)
13; <procedure>(dbi:fetch-row CONNECTION)</procedure> : Return the next row (see mysql).
15; <procedure>(dbi:query-fold CONNECTION PROC SQL SEED)</procedure> : fold
17; <procedure>(dbi:query-map CONNECTION PROC SQL)</procedure> : map
19; <procedure>(dbi:query-for-each CONNECTION PROC SQL SEED)</procedure> : for-each
21; <procedure>(dbi:insert-id CONNECTION)</procedure> : Returns the ID generated by the last insert statement.
24''Instead of the query-fold, query-map and query-for-each procedures I'd prefer just returning a SRFI-40/SRFI-41 stream using promises that advance the cursor when forced. This way you don't restrict the user to these three procedures, but he can use the full stream library to iterate over the result set.'' -- [[Peter Bex]]
26''I'd like to see support for prepared statements. Especially in transactional environments, on some
27DBMSs they can result in big performance wins. And a DBMS that doesn't support them can easily
28implement stubs (e.g., prepare creating a record that holds the original string). Also, another vote for streams. -- vincent''
30=== Open issues
32==== Row Representation
34How are rows returned from a query represented?
36Ozzi proposes either an association list or a plain list.
38''Plain list or vector would be my choice. There should be a separate way of getting the field
39names. Also, there's the issue of how field values are represented. For those data types that correspond to Scheme values, the obvious conversion would be fine; for other datatypes it may not be so obvious.There also needs to be a blob API, so that one can read a piece of a blob without having to ship the whole thing over the network. -- vincent''
41==== Null Representation
43How are null values represented? ''We need an object that corresponds to SQL null. I don't think this object should be {{nil}}. -- vincent''
45==== Return values
47What should be returned from query functions. For example, could we return the insert id of a row instead of having a separate function for that? How about the number of rows in a result?
Note: See TracBrowser for help on using the repository browser.