1) Should the interface take a SQL literal only or should there be "helper"
functions to allow non-SQL interface to SQL databases? The first option
can be implemented by just having a db.sql() call that takes a string.
The second is, obviously, more complex. One possible solution (not
necessarily a good solution) is to have Select, Update, Insert, Delete
objects that have methods for specifying project, select, and join
parameters.
2) How should rows returned from the database be represented. My interface
uses a dictionary, where the key is a string with the column name. However,
I toyed with just using a list of values and providing the column names
as a list returned by a separate method. Another approach is to have
a Row object that hides the representation.
3) Should a select return a cursor object that is interrogated for the
rows? My implementation does not do this. I return one row at a time,
though internally, I fetch into an array for speed. I am not sure
that there is any advantages to a cursor at the Python level and I am
certain that fetching ALL rows from a query automatically can cause
serious memory concerns
4) How should data be represented. I support strings, ints, and floats
as native datatypes. What about BLOBs? What about arbitrarily long
data? My solution is to allow the user to set a max length on long
ascii data. I don't support BLOBs at all right now.
5) How should database-generated error messages be passed back to the
user? I provide a method to get at the information in the sqlca structure
but the only exception I return is 'oracle.error'
I could probably list another 5 issues, but these are sufficient to generate
some response and start discussing whether a standard interface is needed
and, if so, what shape it might take.
-- Derek Fields (derek@cc.bellcore.com)