Thanks, explicitly assigning self.dbapi in my dialect constructor
seems to get around the exception.

I do, however, encounter a new exception:

  File "test_vertica.py", line 57, in testTransactionIsolation
    _, iso_level = e.execute('SHOW TRANSACTION_ISOLATION').fetchone()
  File 
"/home/vmc/ENV/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py",
line 2204, in fetchone
    return self.process_rows([row])[0]
  File 
"/home/vmc/ENV/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py",
line 2163, in process_rows
    for row in rows]
TypeError: row must be a tuple


Any idea what's going on?  The stack trace isn't very informative, I'm afraid.

On Mon, Mar 29, 2010 at 6:05 PM, Michael Bayer <mike...@zzzcomputing.com> wrote:
> Bo Shi wrote:
>> Hello,
>>
>> I had a custom dialect based on the PyODBC functionality that was
>> working with SQLA SVN-6738.  Upgrading to beta 3, my tests no longer
>> pass, so I've begun the process updating - on_connect() was easy, now
>> I'm stumped on connect(...).  I've gotten to the point where, when
>> using my dialect, connect() fails because it attempts to run
>> self.dbapi.connect(...) but the PyODBC connector seems to implement it
>> as a classmethod:
>>
>>
>> Taking the following from the connector in revision control:
>>
>> 9     class PyODBCConnector(Connector):
>>
>> 27       �...@classmethod
>> 28        def dbapi(cls):
>> 29            return __import__('pyodbc')
>>
>> 84        def initialize(self, connection):
>> 85            # determine FreeTDS first.   can't issue SQL easily
>> 86            # without getting unicode_statements/binds set up.
>> 87
>> 88            pyodbc = self.dbapi
>> 89
>> 90            dbapi_con = connection.connection
>> 91
>> 92            self.freetds = bool(re.match(r".*libtdsodbc.*\.so",
>>              dbapi_con.getinfo(pyodbc.SQL_DRIVER_NAME)))
>>
>>
>> If dbapi is implemented as a class method, then wouldn't the call on
>> line 92 fail?  Indeed, that's what I'm seeing.  So is self.dbapi
>> getting assigned somewhere else?
>
> yeah there's a slight misfortune in that naming scheme - the @classmethod
> should have some different name, probably "import_dbapi".   the
> reassignment takes place on line 102 of sqlalchemy/engine/default.py.
> this naming scheme is also present in 0.5 - it was just the
> PyODBCConnector that somehow didn't catch up until recently.
>
>
>
>
>>
>>
>> Thanks,
>> Bo
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To post to this group, send email to sqlalch...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sqlalchemy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sqlalchemy?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to 
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/sqlalchemy?hl=en.
>
>



-- 
Bo Shi
617-942-1744

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to