[DB-SIG] [ANNOUNCEMENT] MySQLdb-0.1.3 released

[Harri Pasanen]

crypt@ihug.co.nz wrote:
> 
> On 03/09 14:46  Andy Dustman was heard to utter:
> > On Thu, 9 Mar 2000, M.-A. Lemburg wrote:
> >
> > > Andy Dustman wrote:
> > > >
> > > > cursor.fetchrow(), of course, returns the result as a sequence of values,
> > > > usually a tuple. cursor.fetchrowDict() returns the result as a dictionary,
> > > > where the keys are the column names and the values are the column values.
> > >
> > > How does this help with columns which are the result of
> > > a SQL function, e.g. select max(value) from table ?
> >
> > You'd probably want to use AS to rename computed columns, e.g.,
> >
> > SELECT MAX(value) AS max_value FROM table;
> >
> > > Wouldn't the same functionality be available by simply
> > > merging the information from cursor.description and the
> > > result of .fetchone() (that's how my own abstract DB class works,
> > > BTW) ?
> >
> > Yep, and that's essentially what fetchoneDict() is doing. fetchoneDict()
> > could have been implemented in Python to do that, but in this case, it's
> > done in C: conn.fetch_row_as_dict(), conn.fetch_rows_as_dict(n),
> > conn.fetch_all_rows_as_dict()); where conn is a _mysql.MYSQL connection
> > object. result.describe() produces the DB API description tuple from some
> > MySQL structures; where result is a _mySQL.MYSQL_RES result object. The
> > various fetch_XXX_as_dict() methods just get this information directly out
> > of some C data structures.
> >
> > And, one of the things about MySQLdb is, since the top-level interface IS
> > written in Python, you can directly subclass the Connection and Cursor
> > objects (rather than writing wrappers), so really someone could have just
> > added this on as their own subclass. Let's just say it's there due to
> > popular demand, and documentated as non-portable.
> 
> I looked at doing this but was wanting to include the tablename as well
> and discovered for some reason that the discription field does not seem
> to include this.
> 
> Is there a good reason for this?
> 

Your SQL query can be a join from multiple tables.  Or if the result set
comes from a stored procedure, you can't even look at your query to see
what tables are affected.

The result set is just value columns with their attributes.  Tables have
nothing to do with the result sets.

Disclaimer: I'm not familiar with MySQL, only with Sybase, but the same
concepts should apply.

-Harri