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
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
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,
, 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
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
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
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
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
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
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
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
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
, 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
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
)
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
=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
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
18 matches
Mail list logo
