Awesome! Thanks!
We work with large amounts of time series data so we have high hopes
for the c extension.
Bo
On Fri, Apr 2, 2010 at 2:38 PM, Michael Bayer <mike...@zzzcomputing.com> wrote:
> Michael Bayer wrote:
>> 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.
>
> Looks like we have a fix as of r3b40ceca28d3, cextensions now look for
> "sequence" instead of "tuple".
>
>
>
>
>>
>>
>>
>>
>>
>>>
>>> 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.
>>
>>
>
> --
> 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.
