On Sat, May 10, 2008 at 5:48 PM, Sebastian Noack <[EMAIL PROTECTED]> wrote: > Hi, > > I think QuerySet.update works to inflexible. In SQL you can define > expressions containing the current value or the value of an other > column in the update clause, for Example to incrementing a value in the > result set. This is not possible by the ORM at the moment.
The basic idea that you are proposing has been made before - for example, several of the discussions about adding aggregations to the ORM have included a capability similar to the one you propose. However, this is the first time to my knowledge that code has been offered. > I developed a possible solution, by introducing combinable Expression > objects. Look at http://code.djangoproject.com/ticket/7210. > > This patch allows you to do following: > > from django.db.models.sql.expressions import * > > qset = model.objects.all() > > # Equivalent to qset.update(foo=42) > qset.update(foo=LiteralExpr(42)) > # Increment column 'foo' by one. > qset.update(foo=CurrentExpr() + LiteralExpr(1)) > # Swap the value of the column 'foo' and 'bar'. > qset.update(foo=ColumnExpr('bar'), bar=ColumnExpr('foo')) > > Does somebody thinks there are reasons to don't merge this patch? Or > ideas ti even improve this patch? Thanks. A few quick comments: * I don't see why LiteralExpr is required. Surely a literal should continue to work as is; if a literal is involved in an expression with a ColumnExpr(), the definition of ColumnExpr should be smart enough to merge the literal into the resultant expression. * foo=CurrentExpr() is really just the same as foo=ColumnExpr('foo'), isn't it? Why include two ways of providing the reference? * ColumnExpr is a bit cumbersome for something that is really exposing the primitives of the underlying SQL. Given that LiteralExpr and CurrentExpr aren't really required, you only need one object for expressions - the ability to reference a field. I would suggest adopting the syntax from the earlier ORM aggregation discussions: F() (for 'Field'). This follow the lead of Q() to describe Query objects. * The examples you give are driven by use cases in the update() clause. This is certainly a useful application of the idea, but it would be good to ensure that the same syntax can be used elsewhere - most notably, in filter() and exclude() clauses. On top of these criticisms, there is at least one very good reason that this patch won't get merged as-is - it doesn't contain any documentation or test cases. What you are proposing is a fairly big feature addition - documentation and tests would be mandatory before the patch was accepted. I can understand why you might have left off documentation until your idea was accepted, but I (and the other core developers) are rarely convinced that code works unless there is a comprehensive test suite to back it up. 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 django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
