[sqlalchemy] [ANN] - Monetdb backend

2007-11-28 Thread m h
Folks- Just thought I'd spam the list here (in case anyone who hasn't seen my IRC spam recently). I'm working on a monetdb[0] backend for SQLAlchemy. Monetdb is a column oriented db[1]. Basically that means it's not fast at transactions per se, but can be 10+X faster on select queries. So if

[sqlalchemy] Re: FYI: SQLAutocode 0.4.1 and 0.5 released

2007-11-13 Thread m h
On Nov 13, 2007 5:14 AM, Simon Pamies [EMAIL PROTECTED] wrote: Hi, I'm very pleased to announce the release of SQLAutocode 0.4.1 and 0.5. This tool enables SQLAlchemy users to automagically generate python code from an existing database layout and even has the Hey Simon, I found your code

[sqlalchemy] Re: FYI: SQLAutocode 0.4.1 and 0.5 released

2007-11-13 Thread m h
On Nov 13, 2007 4:44 PM, m h [EMAIL PROTECTED] wrote: On Nov 13, 2007 5:14 AM, Simon Pamies [EMAIL PROTECTED] wrote: Hi, I'm very pleased to announce the release of SQLAutocode 0.4.1 and 0.5. This tool enables SQLAlchemy users to automagically generate python code from an existing

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-26 Thread m h
On 9/26/07, Michael Bayer [EMAIL PROTECTED] wrote: On Sep 25, 2007, at 7:30 PM, m h wrote: Have updated the ticket with my fix change the dbapi_type of OracleText from CLOB to NUMBER I'm not sure if this breaks others code the bug is, the type of the bind parameters

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-25 Thread m h
Have updated the ticket with my fix change the dbapi_type of OracleText from CLOB to NUMBER I'm not sure if this breaks others code http://www.sqlalchemy.org/trac/ticket/793 --~--~-~--~~~---~--~~ You received this message because you are subscribed to

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-24 Thread m h
Here's another simple testcase that fails for Oracle beta5 but works with 0.3.7. It's about the simplest query I can come up with. Have a table with a date column in it and query against it using the to_date function. def test_to_date(): start_date = '10/05/04' where =

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-24 Thread m h
forgotten you. just have to get the time to power up my oracle box. thanks for putting in the ticket. On Sep 24, 2007, at 7:22 PM, m h wrote: Here's another simple testcase that fails for Oracle beta5 but works with 0.3.7. It's about the simplest query I can come up with. Have

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-22 Thread m h
Thanks for the response! On 9/22/07, Michael Bayer [EMAIL PROTECTED] wrote: well the issue is not even the bind params its the result coming back from cx_oracle. Again, I'm confused how this query works from straight cx and .3.7 but fails when .4beta calls it. Could you enlighten me on what

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-22 Thread m h
I guess to help validate my confusion, in my debugging I replaced the line 867 in base.py:: raise exceptions.DBAPIError.instance(statement, parameters, e) with:: raise Then it doesn't give me the useful statement and parameters, but it tells me exactly where it failed:: ... File

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-22 Thread m h
Sorry, my mess of emails appears to have confused you (youre looking at the error with .3.10 not .4beta) On 9/22/07, Michael Bayer [EMAIL PROTECTED] wrote: On Sep 22, 2007, at 3:45 PM, m h wrote: So the failure is when CursorFairy executes the execute method on the cx cursor. Where

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-22 Thread m h
On 9/22/07, Michael Bayer [EMAIL PROTECTED] wrote: so the new error youre getting now puts it back in the execution camp. you need to narrow down the query to the specific column expression and/or parameter thats making it break. Here's a simple query that fails. The deal breaker is the

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-22 Thread m h
: print r On 9/22/07, m h [EMAIL PROTECTED] wrote: On 9/22/07, Michael Bayer [EMAIL PROTECTED] wrote: so the new error youre getting now puts it back in the execution camp. you need to narrow down the query to the specific column expression and/or parameter thats making it break

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-22 Thread m h
Disregard this testcase it's late at night no need to convert a date to a date but the previous testcase fails for .4beta and works for .3.7!!! On 9/22/07, m h [EMAIL PROTECTED] wrote: Ok, it's caused by func.to_date. Here's an even simpler testcase. Try to convert a date

[sqlalchemy] 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-21 Thread m h
Ok, so this looks impossible to me, but it's happening. I figure people with more experience debugging SA might be able to help. I've got a generated query (no ORM). I was using 0.3.7 with no problems, but thought I'd give .4 a try to see if I can take advantage of performance improvements.

[sqlalchemy] Re: 0.4.0beta5 breaks [Oracle] query, works on 0.3.7 and with cxOracle

2007-09-21 Thread m h
Just for kicks I tried using .3.10 and it failed giving the same error that was reported in the Aug 18 thread autoloading Oracle tables with column defaults:: File /home/matt/work/vpython/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/databases/oracle.py, line 117, in

[sqlalchemy] Viewing SQL of literals....

2007-05-09 Thread m h
Hey- I think this is a simple question but I couldn't find it in the docs (or wiki or faq). I'm trying to debug a query that has some string literals in it (ie calendar.c.week.between(func.to_date('09/19/06','MM/DD/RR')-84,func.to_date('09/19/06','MM/DD/RR') ) and when I view the sql (via