pubdate__year=2005
fname__contains='n'
name__exact='John' (can be abbreviated to name='John')
and so an?
Why don't we use something simple, like tuples:
pubdate=('year', 2005)
name='John' (it is possible now)
fname=('contains','n')
or something similar along these lines? It's more explicit, and you
don't need to parse kwargs.
Did I miss something obvious?
Thanks,
Eugene
This is strange. Somehow lines in my post got swapped during posting.
Originally it was (taken from my Sent folder):
===================================
What was the motivation behind using complex kwargs like (taken from
http://code.djangoproject.com/wiki/RemovingTheMagic):
pubdate__year=2005
name__exact='John' (can be abbreviated to name='John')
fname__contains='n'
and so an?
Why don't we use something simple, like tuples:
===================================
Bizarre...
I think "more explicit" and "simple" is in the eye of the beholder here.
I personally find the fname__contains = 'n' construction clearer than
reading fname = ('contains', 'n') and having to remember that the first
part is a modifier and the second an argument.
My preference is for the current syntax over your version.
Malcolm
Interesting, but I'm not sure I see the advantage. I don't think this
notation is inherently more obvious, and I don't see any use cases
that the existing notation does not service, but this notation would
be able to service.
> or something similar along these lines? It's more explicit, and you
> don't need to parse kwargs.
You still need to parse kwargs to handle queries across joins (e.g.,
Article.objects.filter(author__name__exact='fred'))
Russ Magee %-)
I don't see either. It is a pure aesthetics. Many people complained to
me that Django has the "ugly ORM syntax with underscores".
> You still need to parse kwargs to handle queries across joins (e.g.,
> Article.objects.filter(author__name__exact='fred'))
...which can be replaced with tuples easily thus eliminating parsing. ;-)
Thanks,
Eugene
The complex kwargs predate magic-removal. Most of the magic kwargs are
slowly disappearing, too, like the sudden recent introduction of
.exclude(). (Yay for exclude! Boo for making me spend too much time in
confusion! Yay for moving targets!)
> name='John' (it is possible now)
This has been possible in magic-removal for a while:
Article.objects.filter(name='John')
--
--Max Battcher--
http://www.worldmaker.net/
Just playing around with ideas, but what if you could do something like:
Article.objects.filter(author=Author.objects.filter(name='fred'))
It's a bit verbose, mainly because of the repeated .objects. and
.filter, but it does point to an interesting question: how hard would it
be for filter to create a join in cases where it is getting a related
object QuerySet, like above?
It also points to several possibilities that the current join kwargs
can't handle, such as:
authors = Author.objects.order_by('last_name', 'first_name')
articles = Article.objects.filter(author=authors).order_by('title')
At the very least, it gives a lazier alternative to __in for QuerySets.
In fact, why keep __in, anyway? Why not just have it check to see if
the object is scalar, QuerySet, or List/Tuple and "do the right thing"?
Fairly ugly, that :-P
Has something like the following syntax been discussed here before?
Article.objects.filter(Article.author.name == 'fred')
Article.objects.filter(Article.author.name.contains('fred'))
etc
(overloading operators of the field descriptors to make this work)
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Yeah, that's been discussed and shot down. It's unnecessarily verbose.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com