Also, dunno if it's helpful or not, but this is a regression in
0.6beta3. My dialect plugin works as is when using 0.6beta2.
On Mon, Mar 29, 2010 at 7:41 PM, Bo Shi <bs1...@gmail.com> wrote:
> 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
>
--
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.
