Wednesday, September 5, 2012

Re: DB-API Field Type Codes in mysql-python

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.

On Wednesday, September 5, 2012 1:44:31 PM UTC-4, Ken Ashcraft wrote:
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
 
Thanks again for your help!

No comments:

Post a Comment