>
> As committed, the expressions framework is fairly dumb - it is really
> just a way to do two things:
> 1) Expand Django-style field references into column names (and joins
> if required)
> 2) Turn Python expression trees into SQL expression trees.
>
> This means that the operations that are allowed depend somewhat on the
> database in use. For example, on MySQL, you can perform mod operations
> on floats; under Postgres, you can't.
>
> Constants in expressions are rendered as-is, so whether dates are
> allowed depends on what your database allows. From some quick tests,
> date + integer works on SQLite and MySQL -- or, at least, doesn't
> throw an error. I haven't confirmed that the answer it gives is
> actually meaningful. Postgres complains with an error "operator does
> not exist: timestamp with time zone + integer".
>
> However, I'm certainly interested in entertaining any modification to
> support more interesting expressions - for example, converting the
> expression "F('date') + timedelta(days=3)" into meaningful SQL.
> Patches welcome.
I will have a look at how expressions are implemented (I am aware of
the patches philosophy).
It seems though that the different backends will certainly need
different handlings:
I think
filter(enddate__gt=F('startdate')+timedelta(days=3))
will need to become in SQLITE:
where enddate > date(startdate, "3 days")
and in Postgres:
where enddate > (startdate + interval '3 days')
Koen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
