_last_executed cursor property

Showing 1-7 of 7 messages
_last_executed cursor property Bika 8/28/12 7:27 AM
from the django/db/backends/mysql/base.py
# With MySQLdb, cursor objects have an (undocumented) "_last_executed"
# attribute where the exact query sent to the database is saved.
# See MySQLdb/cursors.py in the source distribution.

Is there a way to access the last executed query string using cloud sql?
Re: _last_executed cursor property Rob Clevenger 8/29/12 10:50 AM

Our dbapi driver doesn't have this field.

Re: _last_executed cursor property Bika 8/29/12 5:11 PM
sorry, my mail was a bit misleading, it was meant to draw your attention to the fact that your dbapi driver does not have this property despite claiming to be 100% mysql compatible

please, consider my mail either as a bug report

thanks, V
Re: _last_executed cursor property Tony Tseng 8/29/12 5:20 PM
Please file a bug on http://code.google.com/p/googlecloudsql/issues/list.

Also could you tell us where you saw the compatibility claim for the dbapi driver? I didn't see that on https://developers.google.com/appengine/docs/python/cloud-sql/developers-guide.
Re: _last_executed cursor property Bika 8/29/12 11:34 PM
bug filed

I was trying to find an exact wording on MySQL compatibility, and you are right there is no such claim. Still, as you refer to the mysql docs in the developers' guide, it gives the idea of being compatible.

Django is a popular third-party Python web framework. When coupled with Google Cloud SQL, all of its functionality can be fully supported by applications running on App Engine. Support for using Google Cloud SQL with Django is provided by a custom Django database backend which wraps Django's MySQL backend.

On the other hand you are perfectly right about not claiming to be compatible:
The Python Development Server in the Google App Engine SDK can use a locally-installed MySQL server instance to closely mirror the Google Cloud SQL environment during development.

I hope these clarify why I thought that you aim for compatibility in APIs. 
Re: _last_executed cursor property Ken Ashcraft 8/30/12 2:25 PM
Using a protected field in the mysql driver seems like the wrong thing for django to do.  Is there a substantial difference between the default implementation of last_executed_query() and the one returned by the mysql version?

    def last_executed_query(self, cursor, sql, params):
        Returns a string of the query last executed by the given cursor, with
        placeholders replaced with actual values.

        `sql` is the raw query containing placeholders, and `params` is the
        sequence of parameters. These are used by default, but this method
        exists for database backends to provide a better implementation
        according to their own quoting schemes.
        from django.utils.encoding import smart_unicode, force_unicode

        # Convert params to contain Unicode values.
        to_unicode = lambda s: force_unicode(s, strings_only=True, errors='replace')
        if isinstance(params, (list, tuple)):
            u_params = tuple([to_unicode(val) for val in params])
            u_params = dict([(to_unicode(k), to_unicode(v)) for k, v in params.items()])

        return smart_unicode(sql) % u_params

On Wed, Aug 29, 2012 at 5:11 PM, bika <akash...@gmail.com> wrote:

Re: _last_executed cursor property Bika 8/31/12 1:32 AM
I've posted your question to the django tracker https://code.djangoproject.com/ticket/18886

Yes, there is a difference, see #14091.

I hope this helps.