Alle lunedì 28 gennaio 2008, Michael Bayer ha scritto:
this example is the working version of what's in ticket #948. a few
other combinations of the above are not yet working, namely if you
tried using lazy=True, or if you put an explicit correlate(users) on
the stuff_view selectable.
Im trying to use clause autoload=True to automatically read table
structure under Interbase 7.5. It does not work. Here is my code:
import sqlalchemy
import sqlalchemy.orm
engine = sqlalchemy.create_engine('firebird://
SYSDBA:[EMAIL PROTECTED]:3050/d:/bazy/bw_adriana_old.gdb')
engine.connect();
On Thu, 31 Jan 2008 01:58:30 -0800 (PST)
Dariusz Jakubowski [EMAIL PROTECTED] wrote:
While autoload=True works with newest version of firebird, it does
not with interbase. Is interbase supported in case of using
autoload=True ?
It should, and I bet there's something easy-to-fix to properly
It seems like the following update call is forcing func.concat to be a
string:
connection.execute(note_table.update(
table.c.id==1,
notes =
func.concat(note_table.c.notes, 'NEW NOTE TO BE ADDED')
I cant reproduce that exact outcome but to specify the SET clause of
an UPDATE, you want to use the values keyword:
table.update(table.c.id==1, values={'notes':func.concat(table.c.nodes,
'FOO')})
Also, you dont even need to use func.concat here as just saying
table.c.nodes + 'FOO' will
Great, thanks. That works.
Jim
On Jan 31, 10:53 am, Michael Bayer [EMAIL PROTECTED] wrote:
I cant reproduce that exact outcome but to specify the SET clause of
an UPDATE, you want to use the values keyword:
table.update(table.c.id==1, values={'notes':func.concat(table.c.nodes,
'FOO')})
I'm using SA 0.4 and Pylons 0.9.6.
Why would this:
def by_date ( self, year, month, day ):
post_q = Session.query ( Post )
start_date = datetime ( int ( year ) , int ( month ), int ( day ) )
end_date = start_date + timedelta ( 1 )
c.post_index = post_q.filter (
and_ ( [
This appears to be a bug in SA 0.4.2p3:
From the datetime docs:
'''
Note: In order to stop comparison from falling back to the default
scheme of comparing object addresses, datetime comparison normally
raises TypeError if the other comparand isn't also a datetime object.
However, NotImplemented
if you compare from the left to the right, it will work:
table.c.column = start_date
the DateTime type itself is not part of the operation at the python
comparison level.
On Jan 31, 2008, at 4:02 PM, Cliff Wells wrote:
This appears to be a bug in SA 0.4.2p3:
From the datetime docs:
Hello Cliff,
I'm using datetime queries to filter results based on a date interval. You
could try using the between() construct to get the records you desire.
Something like this:
q = q.filter(between(Post.c.post_date,start_date,end_date))
Specifying the query this way works for me. Hope that
On Thu, 2008-01-31 at 16:19 -0500, Michael Bayer wrote:
if you compare from the left to the right, it will work:
table.c.column = start_date
the DateTime type itself is not part of the operation at the python
comparison level.
Also, just monkeypatching a timetuple = None onto the
Cliff Wells wrote:
This appears to be a bug in SA 0.4.2p3:
From the datetime docs:
'''
Note: In order to stop comparison from falling back to the default
scheme of comparing object addresses, datetime comparison normally
raises TypeError if the other comparand isn't also a datetime
12 matches
Mail list logo
