On Sat, Jan 31, 2009 at 5:39 AM, Ian Kelly <[email protected]> wrote: > > On Thu, Jan 29, 2009 at 4:14 AM, Russell Keith-Magee > <[email protected]> wrote: >> >> Hi all, >> >> With [9792], I've committed F() query expressions to trunk. For >> details, see the docs: > > Hi Russell, > > First, my apologies for not testing this with Oracle sooner. It
No problems Ian. > appears that nobody else tested it either, because there are some > issues - specifically, Oracle doesn't have the expected %, &, and | > operators. Can you clarify what you mean here - is it case of 'doesn't have these operators in any form', or 'has these operators, but uses different characters/functions? You answer this below for the bitwise operators, but what about %? How does Oracle implement mod? > In order to get this working, it looks like we're going to need to do > some refactoring to push the expression evaluation code into > connection.ops, since currently 1) the operators are hard-coded into > the ExpressionNode class, and 2) the evaluation needs to be flexible > enough to allow function calls in place of operators. Do you have any > suggestions for approaching this task? To a limited extent, we've actually already hit this problem with Postgres. Postgres doesn't support the % operator with floats, for example, whereas SQLite and MySQL do. The decision that was made at the time: http://groups.google.com/group/django-developers/browse_thread/thread/c8cff7e5e16c692a was to accept that the backends all have different capabilities, and while complete backend independence is a laudable goal, it just isn't practical. We already have some backend-specific incompatibilities (such as the handling of case sensitivity on some MySQL collations, and the forward-referencing problem with MySQL) However, your idea about pushing this evaluation into connection.ops, and providing the ability to use function calls in addition to simple infix notation sounds like a good idea to me. A separate thread has already raised similar questions in the context of operations on date fields (e.g., add 3 days). Some backends may require function calls to handle date expressions. Operations on strings are also possible candidates here. > The bit-wise or operator presents a third obstacle, since Oracle > annoyingly doesn't even provide a function for that; it's customarily > implemented as a user-defined function. Since we're not currently in > the habit of installing custom functions for Django, the means of > accomplishing that is an open question. As a stopgap measure, we > could implement `x | y` as `x + y - (x & y)`, with all the usual > caveats that double evaluation implies. If we can't find a simple workaround, I'm happy to put the bitwise operators into the 'Oracle doesn't support it' bucket, and make a special case of the tests. Bitwise operators are a bit of an edge case - making sure the major arithmetic operators work is more important. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
