[PYTHON DB-SIG] DB-Modules returning lists of dicts
Thu, 9 Jan 1997 17:42:05 +0200
David Walton writes:
> Hey folks,
> May I assume that due to the lack of response (with the exception
> of Glenn Colby's, thanks for your comments Glenn), that there is
> no interest out there in Python database modules giving the *option*
> to return a list of dictionaries as an alternative to the list
> of tuples that are currently returned?
> Glenn, comments that at the Jackson Laboratory, while they are
> still having their Sybase module return lists of dictionaries, they
> are doing a rewrite that will cause it to return a list of tuples
> instead (like the API). Glenn also comments that he is setting up
> a SQL class that abstracts away the programmers knowledge of
> the schema, and that he can't see any use for returning a list
> of dictionaries due to the cost in the over-head of the datastructure.
> (part of what I just said may have come from mail that Glenn and
> I exchanged after his initial message. Glenn, please correct me
> if I misinterpreted your words.)
> This is fine for their needs. In our case however, we have no desire
> to abstract away the relational schema from our developers. We also
> find it very useful to be able to reference the results of a query
> by column name, instead of column number. It makes it possible for
> any code that is using a 'SELECT * FROM foo' to continue to function
> when a column is inserted to the schema for foo. And let me say,
> at this point in time this happens frequently to us, because our
> schema is still a moving target.
> I realize that it is possible to take the "description" provided
> by the API and associate the column names with the columns in my
> list of tuples. I do that now. I just thought it would be
> a little more efficient to have the module returning the rows to me
> as dictionaries in the first place.
> I'm very interested in knowing why folks find this option undesirable.
> (if they actually do)
> Glenn's reason being "there is so much space overhead when returning
> a dictionary for each row in the database.". However, for us this
> is not a concern (at least right now), and we would find the
> option useful.
> Thanks again for any input folks can contribute.
I think the space overhead criteria alone is sufficiently strong to do
without a dictionary for each row.
The proper approach in my mind is to wrap the tuple access inside a
class, which can provide very natural access to each field.
Possible interfaces to data, assuming row below is an instance of
above mention wrapper class.
row.field1 # access field1 using __getattr__, name of field is 'field1'
row._tuple # access field1 directly via tuple
row.GetAttribute("field1") # access via class internal dict.
If I remember, Jim Fulton proposed something like this long time ago,
and I've personally implemented this kind of an interface. Works very
nicely. Jim's proposal was more detailed than this quick sketch.
I suggest you browse past archives for this sig, if those are
DB-SIG - SIG on Tabular Databases in Python
send messages to: email@example.com
administrivia to: firstname.lastname@example.org