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