Bo Shi wrote:
>> pep 249 specifies "list of tuples" for fetchmany() and fetchall()
>
> Hrm, pep-249 seems to only specify "sequence" and "sequence of
> sequences" for the fetch*() functions, specifying list of tuples only
> as one possible example.  Perhaps the C implementation of RowProxy is
> being too strict here?  I'm surprised that pyodbc is the only dbapi
> implementation that this problem has occurred in... do all the other
> implementations subclass tuple for their rows?

we run the tests all the time with Pyodbc, so I wasn't aware this was a
pyodbc issue.   I'd run without the c extensions for now.   For our C
extension to coerce into a tuple begins to add overhead and defeat the
purpose of using the extensions in the first place, though Gaetan would
have to answer this question.





>
> On Mon, Mar 29, 2010 at 8:03 PM, Michael Bayer <mike...@zzzcomputing.com>
> wrote:
>> how come the strack trace shows "beta2" as the version number in the
>> path ?   did you mean to say between beta1 and beta2 ?   it looks
>> specific to the C rewrite of RowProxy.   basically the rows returned by
>> fetchone(), fetchall() etc. are expected to be tuples.   pep 249
>> specifies "list of tuples" for fetchmany() and fetchall() though is less
>> specific for fetchone(), though I'm pretty sure it intends tuples there
>> as well.
>>
>>
>> On Mar 29, 2010, at 7:43 PM, Bo Shi wrote:
>>
>>> 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.
>>>
>>
>> --
>> 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.
>
>

-- 
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