DB-API Field Type Codes in mysql-python

[ahroth]

I am using Google App Engine with the Google Cloud SQL module "rdbms".  According to the documentation, rdbms uses DB-API 2.0.  What I've been trying to do is take advantage of the cursor.description attribute, which is a sequence of 7 item sequences (name, type_code,  display_size, internal_size,  precision,  scale, null_ok).  "type_code" is what I'm trying to get at , because I need to pass the data to Google Visualizations, which require types to be declared for each column.

Here's the problem:

"type_code" is returned as an integer.  Different integers represent different types.  I searched madly on the internet for mappings for these codes, and found them for MySQLdb.  The problem is that the ones returned from the Google Cloud SQL rdbms module (for Google App Engine) are different codes!  An integer gets a different code on my local machine than an integer returned from Google Cloud SQL in GAE.

So my questions:

1. Does anyone know where I can get a mapping for the type_codes returned from the rdbms module to GAE?  Or am I going to have to manually test each type in the database?

2. Are there any constants for FIELD_TYPE that I can use with rdbms?  MySQLdb defines these constants in human-readable form, so it would be great if rdbms had the same constant names, so that I wouldn't have to worry about coding for two type mappings.

Can anyone help?  Thanks!

[Ken Ashcraft]

I think this is just an oversight.  We're returning the JDBC integers instead of the mysqldb integers.  I'll file a bug.

Ken

[ahroth]

Thanks, Ken. But since I've coded my application to handle the JDBC codes, it will immediately break once you switch over to the proper MySQLdb codes.

Will I (and other developers with the same issue) get ample warning to make the switch? Even better, would it be possible to query the system to find out which code set is currently being used?

Thanks again for your help!

[Ken Ashcraft]

On Wed, Sep 5, 2012 at 4:06 AM, ahroth <aviv...@gmail.com> wrote:

Thanks, Ken.  But since I've coded my application to handle the JDBC codes, it will immediately break once you switch over to the proper MySQLdb codes.

Will I (and other developers with the same issue) get ample warning to make the switch?

You appear to be the only developer that has noticed...

These kinds of backwards incompatible bugs are tricky because we are dependent on app engine's rollout schedule.  Sometimes app engine will roll out a new release and roll it back because of a bug.  Your app would see the old behavior, then the new behavior, then the old behavior, then the new behavior.

 

 Even better, would it be possible to query the system to find out which code set is currently being used?

I don't see a way to run the system in a "both ways work" mode.  I think you should query a known column and check the type.  For example, create a dummy table with a single varchar column and a single row. When your app instance starts up, query that table and check the type of the column.  Since the typecode for varchar is different, you can tell which mode the system is running in.  Store the mode in a global variable that the app instance can use for its lifetime.

Sorry about the trouble,

Ken

[ahroth]

Thanks for the warning, Ken.  I was actually thinking about doing exactly what you suggest: putting a dummy table in the database and testing it for its known type to figure out which codes are being used.  But now it seems essential, since there will be no way to know when JDBC or MySQLdb type codes are being used and there is always a possiblity of rollback.

So I'll do just that.  Thanks again for your responses.