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.