Magic-removal query syntax
Eugene Lazutkin
http://code.djangoproject.com/wiki/RemovingTheMagic):
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
Eugene Lazutkin
> What was the motivation behind using complex kwargs like (taken from
> http://code.djangoproject.com/wiki/RemovingTheMagic):
>
> 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:
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...
Malcolm Tredinnick
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
Russell Keith-Magee
>
> Why don't we use something simple, like tuples:
>
> pubdate=('year', 2005)
> name='John' (it is possible now)
> fname=('contains','n')
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 %-)
Eugene Lazutkin
>
> 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.
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
Max Battcher
> What was the motivation behind using complex kwargs like (taken from
> http://code.djangoproject.com/wiki/RemovingTheMagic):
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/
Max Battcher
> You still need to parse kwargs to handle queries across joins (e.g.,
> Article.objects.filter(author__name__exact='fred'))
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"?
Christopher Lenz
> Russell Keith-Magee wrote:
>> You still need to parse kwargs to handle queries across joins (e.g.,
>> Article.objects.filter(author__name__exact='fred'))
>
> Just playing around with ideas, but what if you could do something
> like:
>
> Article.objects.filter(author=Author.objects.filter(name='fred'))
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/
Adrian Holovaty
> 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
Yeah, that's been discussed and shot down. It's unnecessarily verbose.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com