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 dateti
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 th
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 h
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 doc
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
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_ ( [
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,
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'"
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')
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 pr
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();
12 matches
Mail list logo