On Fri, Apr 2, 2010 at 21:08, Bo Shi bs1...@gmail.com wrote:
Hrm, some different errors pop up. I'll move the dialog to the ticket
in question.
http://www.sqlalchemy.org/trac/ticket/1757
Should be fixed now (hopefully). Could you test once more?
Thanks,
--
Gaëtan de Menten
--
You
On Tue, Mar 30, 2010 at 19:32, Michael Bayer mike...@zzzcomputing.com wrote:
Bo Shi wrote:
pep 249 specifies list of tuples for fetchmany() and fetchall()
Hrm, pep-249 seems to only specify sequence and sequence of
sequences for the fetch*() functions, specifying list of tuples only
as one
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
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, 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
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
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
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,
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
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
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
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
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
13 matches
Mail list logo
