>>> "C. Derek Fields" wrote:
> 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.
I'm inclined more towards the first option - partly because it's easier
for me to code :-) and it seems easier for SQL folks to deal with.
> 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.
Currently I just return a tuple of rows, each row is another tuple. My
thinking at the time was that the user knows what they are asking for,
they can pull apart the result. This is something that should probably
be fixed in a future version of PymSQL, but it works adequately for my
purposes at the moment.
> 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
In the case of mSQL, the C API returns everything in one lump, then
provides a cursor to manipulate the returned rows. I figured that I
could deal with the data more easily in Python structures than in C
structures. There is a memory consideration, at the moment I havent
thought too hard about the pro's and cons of this.
> 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.
I support everything that mSQL supports - ints, floats, and (fixed length)
strings. If the database is extended further, I'll add support for the
new types.
> 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 think raising an exception is best.
I'm all in favor of a standard SQL interface - it would make life
much easier for the Python community as a whole.
Anthony