Oops. One "zope bug" I complained of was mine. If it had been reported to the gadfly-rdbms list it would have been fixed back when. viz: Aaron Watters wrote:
[copied to gadfly-rdbms list]
Jim Fulton wrote:
...most RDBMSs (as in all but gadfly)
accept:
cursor.execute(""" select name from table where descr = 'this doesn''t work for two reasons' """)
Are you saying that the SQL spec disallows newlines in quoted strings?
I actually was unaware of that. I'll look to my docus. In the mean time if you want it, in sqlgen.py change the charstre to
charstre = "'[^']*'"
===interactively
c.execute(""" select 'this doesn''t work for two reasons' from dual""") print c.pp() <const "this\012doesn't work for two reasons" at 9340320> ========================================================= this doesn't work for two reasons ===end
...
-- Aaron Watters
ps: and thanks.
post script: The current usage of gadfly in Zope makes gadfly do lots of parsing as in insert into table(a,b,c) values (1,2,3) insert into table(a,b,c) values (6,2,3) insert into table(a,b,c) values (1,7,3) insert into table(a,b,c) values (1,2,8) The "right" way to do this would be to take advantage of gadfly's dynamic parameter/multiinsert feature executing insert into table(a,b,c) values (?,?,?) ONCE with dynamic parameters list [(1,2,3), (6,2,3), (1,7,3), (1,2,8)] which would run much faster than thrashing the parser with the individual inserts above (with kjbuckets present). In general dynamic parameters on repeated statements reduce parsing and binding overhead (even for other types of statements). However, I understand this may be hard to implement as it would require special features for the gadfly "adapter" not of value for the other adapters. Oh well. Anyway, in future please post/forward/crosspost any gadfly related issues to the gadfly list. I just discovered a pile of complaints on the zope list this morning and I found it distressing. I don't normally read the zope list. -- Aaron Watters http://www.chordate.com