Re: [sqlalchemy] PyODBCConnector dbapi question
On Fri, Apr 2, 2010 at 21:08, Bo Shi bs1...@gmail.com wrote: Hrm, some different errors pop up. I'll move the dialog to the ticket in question. http://www.sqlalchemy.org/trac/ticket/1757 Should be fixed now (hopefully). Could you test once more? Thanks, -- Gaëtan de Menten -- 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.
Re: [sqlalchemy] PyODBCConnector dbapi question
On Tue, Mar 30, 2010 at 19:32, Michael Bayer mike...@zzzcomputing.com 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. Supporting arbitrary sequences is cheaper than I expected (you pay more than previously only if the sequence is neither a tuple nor a list), so now we are still fast for usual DBAPIs and hopefully don't break on odd stuff (as long as it is a sequence). -- Gaëtan de Menten -- 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.
Re: [sqlalchemy] PyODBCConnector dbapi question
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
Re: [sqlalchemy] PyODBCConnector dbapi question
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
Re: [sqlalchemy] PyODBCConnector dbapi question
Hrm, some different errors pop up. I'll move the dialog to the ticket
in question.
http://www.sqlalchemy.org/trac/ticket/1757
On Fri, Apr 2, 2010 at 2:40 PM, Bo Shi bs1...@gmail.com wrote:
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
Re: [sqlalchemy] PyODBCConnector dbapi question
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?
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
Re: [sqlalchemy] PyODBCConnector dbapi question
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
Re: [sqlalchemy] PyODBCConnector dbapi question
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
28def dbapi(cls):
29return __import__('pyodbc')
84def initialize(self, connection):
85# determine FreeTDS first. can't issue SQL easily
86# without getting unicode_statements/binds set up.
87
88pyodbc = self.dbapi
89
90dbapi_con = connection.connection
91
92self.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.
Re: [sqlalchemy] PyODBCConnector dbapi question
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.
Re: [sqlalchemy] PyODBCConnector dbapi question
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.
Re: [sqlalchemy] PyODBCConnector dbapi question
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
28def dbapi(cls):
29return __import__('pyodbc')
84def initialize(self, connection):
85# determine FreeTDS first. can't issue SQL easily
86# without getting unicode_statements/binds set up.
87
88pyodbc = self.dbapi
89
90dbapi_con = connection.connection
91
92self.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.
Re: [sqlalchemy] PyODBCConnector dbapi question
how come the strack trace shows beta2 as the version number in the path ?
Yeesh. My bad; I spoke too soon.
As you had hypothesized, the error occurs only when I install using
--with-cextensions (it doesn't have anything to do with beta2/3).
Thanks,
Bo
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.
