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
617
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
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
[sqlalchemy] PyODBCConnector dbapi question
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?
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.
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 ?
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
Re: [sqlalchemy] Mixing matching connectors and dialects in 0.6
Hi Michael,
Thanks for the tip on dialect creation; I have a working connection
and much of the low level library functionality appears to just
work.
I've just started digging into the internals to begin implementing
introspection support. One issue I've encountered is that PyODBC
happens to return boolean columns as strings with values 1 and 0.
This confuses the current type system. I have skimmed the
TypeDecorator documentation but am still confused about how to
associate that with this custom dialect. Any hints?
I have attached the dialect base.py and a few test cases (not sure
they're useful as Vertica is frustratingly secretive about everything)
if you have time to review and comment.
On Fri, Jan 15, 2010 at 2:57 PM, Bo Shi bs1...@gmail.com wrote:
That's funny because Oracle and SQL server are utterly, totally different
from a SQL quirks perspective. If I were to pick two dialects in SQLA
that were *most* different from each other and also non-standard, those
would be the two.
I was a bit puzzled by this also (granted this was from some early
press release I dredged up* from google). I'm still working through
their documentation and haven't run across any configuration that
might enable a compatability mode yet.
* improved compatibility with Oracle and SQLServer SQL dialects
http://www.vertica.com/company/news_and_events/Vertica-Analytics-Database-2.5-The-Most-Cost-Effective-Way-To-Modernize-Data-Warehousing
create_engine()
using 'mssql+pyodbc' seems to work but upon attempting to execute a
simple select statement, I get a programming error indicating the
following failed to run:
'SELECT user_name() as user_name;'
So it seems the dialect is getting some additional state under the
hood. lib/sqlalchemy/dialects/mssql/pyodbc.py appears to be hooking
PyODBCConnector and MSDialect together. Is it possible to specify
another dialect here? If so, is there any documentation on how to do
so?
you'd want to make yourself a vertica dialect module that imports the
PyODBCConnector and uses it as a mixin. I'd suggest copying one of the
existing dialects, and probably not the SQL server one unless you know
that vertica has a lot of the transact-SQL lineage that SQL server does
(the PG and SQLite dialects are the most barebones). To run it, add a
setup.py which configures your library as a setuptools entry point, in
this case the name would be vertica+pyodbc:
from setuptools import setup
setup(name=SQLAVertica,
description=...,
entry_points={
'sqlalchemy:plugins':
['vertica+pyodbc = mypackage.base:VerticaDialect']
}
then using create_engine('vertica+pyodbc://user:p...@host/dbname') will load
in your dialect.
--
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.
base.py
Description: Binary data
vertica.py
Description: Binary data
[sqlalchemy] Mixing matching connectors and dialects in 0.6
Hi All, I'm attempting to get rudimentary support for a Vertica deployment using an ODBC connector. According to their docs, their dialect is mostly compatible with Oracle and SQLServer dialects. create_engine() using 'mssql+pyodbc' seems to work but upon attempting to execute a simple select statement, I get a programming error indicating the following failed to run: 'SELECT user_name() as user_name;' So it seems the dialect is getting some additional state under the hood. lib/sqlalchemy/dialects/mssql/pyodbc.py appears to be hooking PyODBCConnector and MSDialect together. Is it possible to specify another dialect here? If so, is there any documentation on how to do so? -- 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] Mixing matching connectors and dialects in 0.6
That's funny because Oracle and SQL server are utterly, totally different
from a SQL quirks perspective. If I were to pick two dialects in SQLA
that were *most* different from each other and also non-standard, those
would be the two.
I was a bit puzzled by this also (granted this was from some early
press release I dredged up* from google). I'm still working through
their documentation and haven't run across any configuration that
might enable a compatability mode yet.
* improved compatibility with Oracle and SQLServer SQL dialects
http://www.vertica.com/company/news_and_events/Vertica-Analytics-Database-2.5-The-Most-Cost-Effective-Way-To-Modernize-Data-Warehousing
create_engine()
using 'mssql+pyodbc' seems to work but upon attempting to execute a
simple select statement, I get a programming error indicating the
following failed to run:
'SELECT user_name() as user_name;'
So it seems the dialect is getting some additional state under the
hood. lib/sqlalchemy/dialects/mssql/pyodbc.py appears to be hooking
PyODBCConnector and MSDialect together. Is it possible to specify
another dialect here? If so, is there any documentation on how to do
so?
you'd want to make yourself a vertica dialect module that imports the
PyODBCConnector and uses it as a mixin. I'd suggest copying one of the
existing dialects, and probably not the SQL server one unless you know
that vertica has a lot of the transact-SQL lineage that SQL server does
(the PG and SQLite dialects are the most barebones). To run it, add a
setup.py which configures your library as a setuptools entry point, in
this case the name would be vertica+pyodbc:
from setuptools import setup
setup(name=SQLAVertica,
description=...,
entry_points={
'sqlalchemy:plugins':
['vertica+pyodbc = mypackage.base:VerticaDialect']
}
then using create_engine('vertica+pyodbc://user:p...@host/dbname') will load
in your dialect.
--
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.
[sqlalchemy] pyodbc ini file
Hi All - I'm playing around with pyodbc (using unixodbc) support in trunk - I was wondering if there is any way to bypass the additional system-wide odbc.ini settings file to create connections. Is there a way to simply pass in all the connection parameters via create_engine(...) that would normally be specified with the ini file? 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.
[sqlalchemy] Is there a way to get a list of bindparam() names from a pre-constructed select clause?
I have a select clause containing a subselect that may or may not have a bindparam... I haven't been able to dig up a way to get the list of bindparams in said clause. Is there a way to do this? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: MySQL, unions and ordering
Right; my bad - I misread the instructions.
On Sat, Dec 6, 2008 at 9:41 AM, Michael Bayer [EMAIL PROTECTED] wrote:
you'd say, s.alias().select()
it makes subqueries which MySQL probably doesn't require.
On Dec 5, 2008, at 10:35 PM, Bo Shi wrote:
Thanks; the monkeypatch approach works nicely. Using the alias()
method will raise
AttributeError: 'Alias' object has no attribute '_order_by_clause'
On Fri, Dec 5, 2008 at 7:25 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
there's logic which is removing the order_by's from the selects, and
in that case this is what's blowing away the parenthesis as well.
Some databases don't even allow ORDER BY inside of the queries used
in
a UNION since in the absense of LIMIT/OFFSET, which also is not
standard SQL, they have no effect.
However I dont think its good form for SQLA to be whacking the ORDER
BY from the unions if that is in fact what was requested.So this
behavior is changed in the 0.5 series in r5425. As far as the 0.4
series, we're only supporting critical bugfixes there and I'd like to
avoid any behavioral changes (0.4 is also on a more conservative
release schedule). If you're truly stuck with 0.4, you can use
select.order_by(...).alias().select() to get an equivalent query
which
is insulated from changes (and is probably more compatible across
databases), or to get exactly the same SQL here's a safe monkeypatch
approach:
from sqlalchemy import *
s = select([x, y]).select_from(table)
def frozen_order_by(s):
s = s.self_group()
s.order_by = lambda *args: s
return s
qlist = [s.limit(10).order_by('x'), s.limit(10).order_by('x')]
print union_all(*[frozen_order_by(q) for q in
qlist]).order_by(foo).limit(10)
frozen_order_by() calls self_group() thereby generating a new
select()
so that the original is unchanged.
On Dec 5, 2008, at 5:08 PM, Bo Shi wrote:
Oh, check this out:
(SA 0.4.7)
from sqlalchemy import *
s = select([x, y]).select_from(table)
qlist = [s.limit(10).order_by('x').self_group(),
s.limit(10).order_by('x').self_group()]
print union_all(*qlist).order_by(foo).limit(10)
SELECT x, y
FROM table
LIMIT 10 UNION ALL SELECT x, y
FROM table
LIMIT 10 ORDER BY foo
LIMIT 10
for q in qlist:
... print q
...
(SELECT x, y
FROM table ORDER BY x
LIMIT 10)
(SELECT x, y
FROM table ORDER BY x
LIMIT 10)
On Fri, Dec 5, 2008 at 4:55 PM, Bo Shi [EMAIL PROTECTED] wrote:
I had to upgrade to 0.4.7 from 0.4.2, but your sample query works,
however, my application of it does not.
Sorry I'm being so light on details, I'll try to reproduce with a
complete sample versus using snippets of production code.
Each select statement is generated like so:
sel = select(pre_select + selectlist,
from_obj=join_datatables(tables))
I apply self_group() using a list comprehension and if I print each
select statement in the list individually, the parentheses show up.
If I then union_all(*querylist) and print that, the parentheses
disappear.
Weird.
I should note that the individual selects have filters, an order by
clause and a limit, but the following works fine so I would not
expect
that to be a problem.
from sqlalchemy import *
s = select([x, y]).select_from(table)
print s.self_group()
(SELECT x, y
FROM table)
print union_all(s.self_group(), s.self_group()).order_by(foo)
(SELECT x, y
FROM table) UNION ALL (SELECT x, y
FROM table) ORDER BY foo
print union_all(s.limit(10).self_group(),
s.limit(10).self_group()).order_by(foo).limit(10)
(SELECT x, y
FROM table
LIMIT 10) UNION ALL (SELECT x, y
FROM table
LIMIT 10) ORDER BY foo
LIMIT 10
import sqlalchemy as sa
sa.__version__
'0.4.7'
On Fri, Dec 5, 2008 at 4:23 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
from sqlalchemy import *
s = select([x, y]).select_from(table)
print union_all(s.self_group(), s.self_group()).order_by(foo)
(SELECT x, y
FROM table) UNION ALL (SELECT x, y
FROM table) ORDER BY foo
On Dec 5, 2008, at 4:17 PM, Bo Shi wrote:
Thanks for the quick response!
The following does *not* work. Am I making the call incorrectly?
sel = union_all(*[q.self_group() for q in querylist])
On Fri, Dec 5, 2008 at 4:08 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
try calling self_group() on each select object.
On Dec 5, 2008, at 3:55 PM, Bo Shi wrote:
Hi all,
There appear to be some nuances to using order by statements
with
set
operations like unions in MySQL but the following is allowed*:
(SELECT a,b from DBA.tbl ORDER BY b LIMIT 5)
UNION ALL
(SELECT a,b from DBB.tbl ORDER BY b LIMIT 5)
ORDER BY b
When I attempt to generate such a statement with:
union_all(*list_of_select_objs),
The SQL generated lacks parentheses around the SELECT
statements (in
addition to dropping the order by clauses, but that appears
to be
expected behavior). Is there a way to put the parentheses in?
*just an example, the query i've written is meaningless/
useless :-)
--
Bo Shi
[sqlalchemy] MySQL, unions and ordering
Hi all, There appear to be some nuances to using order by statements with set operations like unions in MySQL but the following is allowed*: (SELECT a,b from DBA.tbl ORDER BY b LIMIT 5) UNION ALL (SELECT a,b from DBB.tbl ORDER BY b LIMIT 5) ORDER BY b When I attempt to generate such a statement with: union_all(*list_of_select_objs), The SQL generated lacks parentheses around the SELECT statements (in addition to dropping the order by clauses, but that appears to be expected behavior). Is there a way to put the parentheses in? *just an example, the query i've written is meaningless/useless :-) -- Bo Shi 207-469-8264 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: MySQL, unions and ordering
Thanks for the quick response! The following does *not* work. Am I making the call incorrectly? sel = union_all(*[q.self_group() for q in querylist]) On Fri, Dec 5, 2008 at 4:08 PM, Michael Bayer [EMAIL PROTECTED] wrote: try calling self_group() on each select object. On Dec 5, 2008, at 3:55 PM, Bo Shi wrote: Hi all, There appear to be some nuances to using order by statements with set operations like unions in MySQL but the following is allowed*: (SELECT a,b from DBA.tbl ORDER BY b LIMIT 5) UNION ALL (SELECT a,b from DBB.tbl ORDER BY b LIMIT 5) ORDER BY b When I attempt to generate such a statement with: union_all(*list_of_select_objs), The SQL generated lacks parentheses around the SELECT statements (in addition to dropping the order by clauses, but that appears to be expected behavior). Is there a way to put the parentheses in? *just an example, the query i've written is meaningless/useless :-) -- Bo Shi 207-469-8264 -- Bo Shi 207-469-8264 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: MySQL, unions and ordering
I had to upgrade to 0.4.7 from 0.4.2, but your sample query works, however, my application of it does not. Sorry I'm being so light on details, I'll try to reproduce with a complete sample versus using snippets of production code. Each select statement is generated like so: sel = select(pre_select + selectlist, from_obj=join_datatables(tables)) I apply self_group() using a list comprehension and if I print each select statement in the list individually, the parentheses show up. If I then union_all(*querylist) and print that, the parentheses disappear. Weird. I should note that the individual selects have filters, an order by clause and a limit, but the following works fine so I would not expect that to be a problem. from sqlalchemy import * s = select([x, y]).select_from(table) print s.self_group() (SELECT x, y FROM table) print union_all(s.self_group(), s.self_group()).order_by(foo) (SELECT x, y FROM table) UNION ALL (SELECT x, y FROM table) ORDER BY foo print union_all(s.limit(10).self_group(), s.limit(10).self_group()).order_by(foo).limit(10) (SELECT x, y FROM table LIMIT 10) UNION ALL (SELECT x, y FROM table LIMIT 10) ORDER BY foo LIMIT 10 import sqlalchemy as sa sa.__version__ '0.4.7' On Fri, Dec 5, 2008 at 4:23 PM, Michael Bayer [EMAIL PROTECTED] wrote: from sqlalchemy import * s = select([x, y]).select_from(table) print union_all(s.self_group(), s.self_group()).order_by(foo) (SELECT x, y FROM table) UNION ALL (SELECT x, y FROM table) ORDER BY foo On Dec 5, 2008, at 4:17 PM, Bo Shi wrote: Thanks for the quick response! The following does *not* work. Am I making the call incorrectly? sel = union_all(*[q.self_group() for q in querylist]) On Fri, Dec 5, 2008 at 4:08 PM, Michael Bayer [EMAIL PROTECTED] wrote: try calling self_group() on each select object. On Dec 5, 2008, at 3:55 PM, Bo Shi wrote: Hi all, There appear to be some nuances to using order by statements with set operations like unions in MySQL but the following is allowed*: (SELECT a,b from DBA.tbl ORDER BY b LIMIT 5) UNION ALL (SELECT a,b from DBB.tbl ORDER BY b LIMIT 5) ORDER BY b When I attempt to generate such a statement with: union_all(*list_of_select_objs), The SQL generated lacks parentheses around the SELECT statements (in addition to dropping the order by clauses, but that appears to be expected behavior). Is there a way to put the parentheses in? *just an example, the query i've written is meaningless/useless :-) -- Bo Shi 207-469-8264 -- Bo Shi 207-469-8264 -- Bo Shi 207-469-8264 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: MySQL, unions and ordering
Thanks; the monkeypatch approach works nicely. Using the alias()
method will raise
AttributeError: 'Alias' object has no attribute '_order_by_clause'
On Fri, Dec 5, 2008 at 7:25 PM, Michael Bayer [EMAIL PROTECTED] wrote:
there's logic which is removing the order_by's from the selects, and
in that case this is what's blowing away the parenthesis as well.
Some databases don't even allow ORDER BY inside of the queries used in
a UNION since in the absense of LIMIT/OFFSET, which also is not
standard SQL, they have no effect.
However I dont think its good form for SQLA to be whacking the ORDER
BY from the unions if that is in fact what was requested.So this
behavior is changed in the 0.5 series in r5425. As far as the 0.4
series, we're only supporting critical bugfixes there and I'd like to
avoid any behavioral changes (0.4 is also on a more conservative
release schedule). If you're truly stuck with 0.4, you can use
select.order_by(...).alias().select() to get an equivalent query which
is insulated from changes (and is probably more compatible across
databases), or to get exactly the same SQL here's a safe monkeypatch
approach:
from sqlalchemy import *
s = select([x, y]).select_from(table)
def frozen_order_by(s):
s = s.self_group()
s.order_by = lambda *args: s
return s
qlist = [s.limit(10).order_by('x'), s.limit(10).order_by('x')]
print union_all(*[frozen_order_by(q) for q in
qlist]).order_by(foo).limit(10)
frozen_order_by() calls self_group() thereby generating a new select()
so that the original is unchanged.
On Dec 5, 2008, at 5:08 PM, Bo Shi wrote:
Oh, check this out:
(SA 0.4.7)
from sqlalchemy import *
s = select([x, y]).select_from(table)
qlist = [s.limit(10).order_by('x').self_group(),
s.limit(10).order_by('x').self_group()]
print union_all(*qlist).order_by(foo).limit(10)
SELECT x, y
FROM table
LIMIT 10 UNION ALL SELECT x, y
FROM table
LIMIT 10 ORDER BY foo
LIMIT 10
for q in qlist:
... print q
...
(SELECT x, y
FROM table ORDER BY x
LIMIT 10)
(SELECT x, y
FROM table ORDER BY x
LIMIT 10)
On Fri, Dec 5, 2008 at 4:55 PM, Bo Shi [EMAIL PROTECTED] wrote:
I had to upgrade to 0.4.7 from 0.4.2, but your sample query works,
however, my application of it does not.
Sorry I'm being so light on details, I'll try to reproduce with a
complete sample versus using snippets of production code.
Each select statement is generated like so:
sel = select(pre_select + selectlist,
from_obj=join_datatables(tables))
I apply self_group() using a list comprehension and if I print each
select statement in the list individually, the parentheses show up.
If I then union_all(*querylist) and print that, the parentheses
disappear.
Weird.
I should note that the individual selects have filters, an order by
clause and a limit, but the following works fine so I would not
expect
that to be a problem.
from sqlalchemy import *
s = select([x, y]).select_from(table)
print s.self_group()
(SELECT x, y
FROM table)
print union_all(s.self_group(), s.self_group()).order_by(foo)
(SELECT x, y
FROM table) UNION ALL (SELECT x, y
FROM table) ORDER BY foo
print union_all(s.limit(10).self_group(),
s.limit(10).self_group()).order_by(foo).limit(10)
(SELECT x, y
FROM table
LIMIT 10) UNION ALL (SELECT x, y
FROM table
LIMIT 10) ORDER BY foo
LIMIT 10
import sqlalchemy as sa
sa.__version__
'0.4.7'
On Fri, Dec 5, 2008 at 4:23 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
from sqlalchemy import *
s = select([x, y]).select_from(table)
print union_all(s.self_group(), s.self_group()).order_by(foo)
(SELECT x, y
FROM table) UNION ALL (SELECT x, y
FROM table) ORDER BY foo
On Dec 5, 2008, at 4:17 PM, Bo Shi wrote:
Thanks for the quick response!
The following does *not* work. Am I making the call incorrectly?
sel = union_all(*[q.self_group() for q in querylist])
On Fri, Dec 5, 2008 at 4:08 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
try calling self_group() on each select object.
On Dec 5, 2008, at 3:55 PM, Bo Shi wrote:
Hi all,
There appear to be some nuances to using order by statements with
set
operations like unions in MySQL but the following is allowed*:
(SELECT a,b from DBA.tbl ORDER BY b LIMIT 5)
UNION ALL
(SELECT a,b from DBB.tbl ORDER BY b LIMIT 5)
ORDER BY b
When I attempt to generate such a statement with:
union_all(*list_of_select_objs),
The SQL generated lacks parentheses around the SELECT
statements (in
addition to dropping the order by clauses, but that appears to be
expected behavior). Is there a way to put the parentheses in?
*just an example, the query i've written is meaningless/
useless :-)
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--~--~-~--~~~---~--~~
You received this message because you are subscribed
[sqlalchemy] Re: Problem using utf-8
Switching to 1.2.2 and using connect_args = {'use_unicode':
False,'charset': 'utf8'} works fine for me.
Hi Jürgen,
I'm curious; if you upgraded to 1.2.2, does the issue persist if you
stop using connect_args = {'use_unicode': False,'charset': 'utf8'}?
Bo
On Thu, Sep 18, 2008 at 3:07 AM, Jürgen Hauptmann
[EMAIL PROTECTED] wrote:
Thank you.
Switching to 1.2.2 and using connect_args = {'use_unicode':
False,'charset': 'utf8'} works fine for me.
Jürgen
Michael Bayer schrieb:
I believe this is the ticket:
http://sourceforge.net/tracker/index.php?func=detailaid=1592353group_id=22307atid=374932
its a little ambiguous as to its resolution, maybe I'll ask Shannon
what his most recent experiences were.
On Sep 17, 2008, at 12:03 PM, Bo Shi wrote:
While researching which version to deploy, I had run into a thread
post _claiming_ that 1.2.2 had a critical bug which was documented in
the fedora bugzilla. I never managed to actually find said bug but it
scared me off. The reason we went with 1.2.1p2 was because it was the
version the Django people have been using with success.
At any rate, the workaround I posted seems to work for us thus far,
though I don't have a good understanding of exactly why it works (I
suspect it tiptoes around a double-encoding bug in mysqldb).
Bo
On Wed, Sep 17, 2008 at 11:31 AM, Michael Bayer
[EMAIL PROTECTED] wrote:
On Sep 17, 2008, at 10:50 AM, Bo Shi wrote:
I ran into a similar issue using MySQL-python-1.2.1_p2-1 (mysqldb)
with SA 0.4.2p3-1.
I would advise upgrading to MySQL-python 1.2.2. I believe some utf-8
issues have been fixed.
--
Bo Shi
207-469-8264
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Problem using utf-8
I ran into a similar issue using MySQL-python-1.2.1_p2-1 (mysqldb)
with SA 0.4.2p3-1.
http://www.mail-archive.com/sqlalchemy@googlegroups.com/msg00373.html
might shed some more light on this issue which might be a double
encoding problem?
Here is the subset of relevant keyword arguments we use with that
particular database driver in create_engine:
create_engine_kwargs = {
'encoding': 'utf-8',
'connect_args': {
'use_unicode': False,
'charset': 'utf8',
},
}
On Wed, Sep 17, 2008 at 9:57 AM, Jürgen Hauptmann
[EMAIL PROTECTED] wrote:
Hi
Im using utf-8 in my mysql tables. If i insert a String with German
Umlaute like Ü it is converted to Ãœ in the database, it ist returned as
Ü. - What can i do that this will be correctly saved?
my connection looks like this:
engine = create_engine('mysql://xxx:[EMAIL PROTECTED]/test123', echo=False,
pool_size=30, pool_recycle=3600)
use_unicode, or the other Parameters doesn't work for me.
the table definition looks like this:
raum_table = Table('raum', metadata,
Column('id', Integer, ForeignKey('objekt.id'),primary_key=True),
Column('name', Unicode(100)),
Column('anzahl', Integer),
Column('raumbezeichnung', Integer),
Column('raumtyp', Integer),
Column('siedlungstyp', Integer),
Column('gebaeude', Unicode(200)),
Column('gebaeudeteil', Unicode(200)),
Column('fundstelle', Unicode(200)),
Column('befundgattung', Integer),
Column('befund', Unicode(200)),
Column('orttyp', Integer),
Column('ort', Integer)
)
the mapper looks like this:
mapper(Raum, raum_table,
inherits=Objekt, polymorphic_identity='raum',
properties={
'personen':relation(Person, secondary = person_raum_table),
'handlungen':relation(Handlung, secondary = raum_handlung_table),
'objekte':relation(WObjekt, secondary = wobjekt_raum_table),
'eigenschaften' : relation(Eigenschaft, secondary =
eigenschaft_raum_table)
}
)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
