Re: Django ORM query syntax enhancement

Hi Adam, I agree with some of your points. however djngo orm query syntax is the main pain point for anyone new to django orm. The reason those packages are not widely used is because most people dont know about them and not about this DEP. And most new users mainly end up learning built in

Re: Django ORM query syntax enhancement

I would not be for merging anything into Django at this time. There are several libraries providing "enhanced" query syntax: django-orm-sugar, django-model-values, and django-natural-query. None of them seems to be particularly popular (<100 github stars, minimal PyPI downloads), and only

Re: Django ORM query syntax enhancement

Hey all, can we have some consensus on this? Asif On Saturday, April 1, 2017 at 12:55:27 PM UTC+6 Alexey Zankevich wrote: > Hey all, > > Please check a draft DEP related to external query language support by > Django ORM https://github.com/django/deps/pull/40. > > Regards, > Alexey > > > On

Re: Django ORM query syntax enhancement

Hey all, Please check a draft DEP related to external query language support by Django ORM https://github.com/django/deps/pull/40. Regards, Alexey On Wednesday, March 22, 2017 at 10:07:51 AM UTC+3, Asif Saifuddin wrote: > > Hi Aric, > > I checked your package. it's nice too. thanks for the

Re: Django ORM query syntax enhancement

Hi Aric, I checked your package. it's nice too. thanks for the work. Asif On Monday, October 17, 2016 at 4:38:26 AM UTC+6, Aric Coady wrote: > > +1. I implemented much the same thing for part of django-model-values > , but went with F >

Re: Django ORM query syntax enhancement

+1. I implemented much the same thing for part of django-model-values , but went with F expressions as the basis instead. Primarily because F expressions already support operator

Re: Django ORM query syntax enhancement

Agreed about concatenation functions calls. It would be easy to achieve once filter will accept object-based lookups (previously we discussed expression objects). I think it would be even better to accept objects of expression builder instead (versus expressions directly) - it will separate

Re: Django ORM query syntax enhancement

+1 from me, too. I still think we should be able to get into a point where you can run queries like: Q.user.firstname.collate('fi').lower() == 'anssi' So, not only can you call regular transforms (like lower), but also transforms that take arguments. Other use cases are for example

Re: Django ORM query syntax enhancement

+1 from me. I really like this approach to help making my queries more DRY. I also like how lightweight the library is altogether. Well done! For those looking for a direct link, here you go: https://github.com/Nepherhotep/django-orm-sugar On Thursday, October 6, 2016 at 1:04:56 PM UTC-4,

Re: Django ORM query syntax enhancement

Hey all, Just want to announce recent changes in Django ORM Sugar library, which might be useful in future Django query syntax enhancement (if ever happens). 1. Now it supports indexes and slices: >>> Q.data.owner.other_pets[0].name='Fishy' Q(data__owner__other_pets__0__name='Fishy') >>>

Re: Django ORM query syntax enhancement

Here is a link https://github.com/django/django/pull/5443, sorry :) Making F object as expression wasn't required, but I still had to create FieldExpression wrapper, which wrapped F object. Eventually, I thought it would confuse people, especially taking in account F objects referenced in doc

Re: Django ORM query syntax enhancement

this is the PR josh https://github.com/django/django/pull/5443 On Monday, October 19, 2015 at 5:09:14 PM UTC+6, Josh Smeaton wrote: > > I think you forgot the PR link Alexey. I'd like to have a look at the > changes you've made. I'm not sure about the extensions to F() just yet, I'm > hoping

Re: Django ORM query syntax enhancement

I think you forgot the PR link Alexey. I'd like to have a look at the changes you've made. I'm not sure about the extensions to F() just yet, I'm hoping they aren't actually needed for your patch to work, but will need to review to be sure. Cheers On Monday, 19 October 2015 21:49:37 UTC+11,

Re: Django ORM query syntax enhancement

Hi all, Here is a raw pull request, allowing lookup instances passing to filter method There are two new test cases working: 1. Passing lookup with F object: Article.objects.filter(GreaterThan(F('id'), Value(5))) 2. And passing lookup with transforms:

Re: Django ORM query syntax enhancement

Lets concentrate on making expressions in filter calls and lookups as expressions reality. When we have done that we can try out different syntax approaches in 3rd party apps. Finally, after we have field tested the approaches, we can merge something in to Django. - Anssi On Thu, Oct 1, 2015 at

Re: Django ORM query syntax enhancement

> I think the `F('name').decode('utf-8')` syntax is a good candidate for core. When Django supports expression lookups, it will be possible to build syntax sugar third-party library on top of it. For example, it will be possible to implement dotted syntax for F objects:

Re: Django ORM query syntax enhancement

> On Oct 1, 2015, at 13:38, Anssi Kääriäinen wrote: > > +1 to not requiring all transforms to handle __underscore__ syntax. +1 > I think what we want to do is allow users choose which syntax they > prefer. The idea is that Django will support both JSONExtract('data', >

Re: Django ORM query syntax enhancement

+1 to not requiring all transforms to handle __underscore__ syntax. I think what we want to do is allow users choose which syntax they prefer. The idea is that Django will support both JSONExtract('data', path=['owner', 'other_pets', 0, 'name']) and data__owner__other_pets__0__name out of the

Re: Django ORM query syntax enhancement

No, not all Lookups or Transforms are required to handle __underscore__ syntax. The entire point of supporting object based lookups is to handle cases that get more complex than a single argument transform or a left and right hand side lookup. In particular, I think your Decode(utf8) example

Re: Django ORM query syntax enhancement

Hi Mark, I can explain why long string is a bad design (other than anything I described earlier). In fact it assumes that the additional parameters can be serialized into alphanumeric string, which apply additional and unnecessary limitation. In my example above, it's not clear how to pass

Re: Django ORM query syntax enhancement

I don't think complex cases need to have __ equivalents, but I also dispute that long chains like that are necessarily a bad API, I don't find your option 1 particularly neat compared to option 2. Worth noting though that you've used a 2-valued function there which is not a lookup in the same

Re: Django ORM query syntax enhancement

I'll try to turn lookups into expression (will use master branch). I also have a question. Meanwhile the old query syntax with underscores is pretty good for simple queries (like Model.objects.filter(name='Bob'), it gets really ugly for parametrized calls, a new JSONField is a good example of

Re: Django ORM query syntax enhancement

I don't think we need split-to-subq support for Lookups before we make them expressions. Lookups as expressions are usable outside .filter(), and we need the split-to-subq support only in .filter(expression). - Anssi On Wed, Sep 30, 2015 at 8:46 AM, Josh Smeaton wrote:

Re: Django ORM query syntax enhancement

I'm mixing my versions, sorry to those following along. 1.9 has just reached alpha. Lookups as Expressions should be doable for 1.10 which master is currently tracking. Cheers On Wednesday, 30 September 2015 15:31:24 UTC+10, Josh Smeaton wrote: > > The alpha for 1.10 has already been cut, and

Re: Django ORM query syntax enhancement

The alpha for 1.10 has already been cut, and I'm not sure that the kinds of changes needed here are appropriate to add now that the alpha is out. One could *maybe* make the argument that changing Lookup to an Expression now rather than later is the right move considering Transforms just

Re: Django ORM query syntax enhancement

On the core ORM side we need to make .exclude(LessThan(F('friends__age'), 30)) do a subquery. This way .exclude(friends__age__lt=30) does the same thing as the expression version. This isn't that easy to do. If we just use resolve_expression, then the friends relation will generate a join, and

Re: Django ORM query syntax enhancement

1. Lookups should become Expressions, just as Transforms have become Expressions. This will let us process Lookup arguments as Expressions all the way the way through. I think this should be a major goal for version 1.11. 2. Chaining transforms is now possible since they are just Func

Re: Django ORM query syntax enhancement

Here is a list of issues to solve to support explicit transforms and lookups by filter (and exclude) methods. 1. Make Lookup.__init__ signature to support initialization with F objects or string path (e.g. GreaterThan(F('user__id'), 10) or GreaterThan('user__id', 10)), not sure it's possible

Re: Django ORM query syntax enhancement

Hi Josh, As https://github.com/django/django/pull/5090 pull request merged into master, I wanted to extend django-orm-sugar library with some functionality, related to passing transforms or lookup objects. Currently it's not clear to me how lookups or transforms can be used in that way. I'm

Re: Django ORM query syntax enhancement

The patch allowing F objects for select_related and prefetch_related methods was trivial, unfortunately F uses "name" field as a part of Expression interface, so dotted querying will conflict with internal field (as "name" is quite a popular name for model field). >>> Contains(F.user.name,

Re: Django ORM query syntax enhancement

Gotcha. So, F objects seem to be pretty good as generic interface to specify query paths, the only remaining patch - adding select_related and prefetch_related support. I'll preapare a preliminary pull request soon. On Tuesday, August 25, 2015 at 2:48:10 AM UTC+3, Josh Smeaton wrote: > >

Re: Django ORM query syntax enhancement

Expressions have built in support for ordering with asc or desc, see here: https://docs.djangoproject.com/en/1.8/ref/models/expressions/#django.db.models.Expression.asc Meaning that -F() is never ambiguous, which is the main reason we went for the F().desc() API rather than using the minus

Re: Django ORM query syntax enhancement

Hey Josh, Here is the current state of F support by different functions: * annotations (Count, Sum etc) - work * order_by - works partially (only asc order supported) * select_related, prefetch_related - don't work So, F is not a universal interface for getting paths right now. Also, there is

Re: Django ORM query syntax enhancement

Most expressions already support strings, and most that support strings expect them to be field_paths that can be wrapped in F() expressions. So you have two options really, without built in support from other expressions. 1. P.field.other.some_field() returns an F() 2.

Re: Django ORM query syntax enhancement

What about the idea to add interface to specify paths with special class or callable? On Wednesday, August 19, 2015 at 10:49:07 AM UTC+3, Josh Smeaton wrote: > > If I finish the patch in time (I think I have about a month left), then > it'll be included in 1.9. Review and comments on the PR

Re: Django ORM query syntax enhancement

If I finish the patch in time (I think I have about a month left), then it'll be included in 1.9. Review and comments on the PR will go a long way to helping me tidy it up sooner rather than later, so please feel free to review. Regards, On Wednesday, 19 August 2015 04:55:21 UTC+10, Alexey

Re: Django ORM query syntax enhancement

Once Josh completes this patch https://github.com/django/django/pull/5090 (.filter method accepting class-based lookups and transforms), it will be almost everything required by third-party apps. Is it going to be a part of Django 1.9, by the way? Additionally, for pure flexibility, next method

Re: Django ORM query syntax enhancement

+1 for making it doable for 3rd party apps. Regards, Michael Manfre On Tue, Aug 18, 2015 at 12:49 PM, Anssi Kääriäinen wrote: > I'm still thinking we shouldn't integrate any new query syntax into > 1.9. Instead lets make it easy to create 3rd party apps that offer >

Re: Django ORM query syntax enhancement

I strongly agree with the third party approach. On 18 Aug 2015 17:49, "Anssi Kääriäinen" wrote: > I'm still thinking we shouldn't integrate any new query syntax into > 1.9. Instead lets make it easy to create 3rd party apps that offer > different querying syntax, and then

Re: Django ORM query syntax enhancement

I'm still thinking we shouldn't integrate any new query syntax into 1.9. Instead lets make it easy to create 3rd party apps that offer different querying syntax, and then lets see which solution (if any) gets popular enough to be integrated into Django. - Anssi On Tue, Aug 18, 2015 at 5:54

Re: Django ORM query syntax enhancement

Just a quick thought: I could imagine some newbies could get confused by the python-like syntax and try to do: Equal(P.user.get_full_name(), 'Bob Someone') I don't think it's not a huge deal, but worth noting. On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote: > > Hi all,

Re: Django ORM query syntax enhancement

Hi all, Thanks for detailed response. I thought over the described expressions/ transforms patches and here are my thoughts about the best way to implement simplified lookups. Firstly, I want to describe which properties of the new syntax seem to be important: 1. Using Python operators to do

Re: Django ORM query syntax enhancement

I like this idea, too. The work I and Loic have been doing has been about transforms that can accept arguments. I don't see why the two styles couldn't be mixed directly. .filter(Q.user.profile.last_login.date(timezone='Europe/Helsinki') < '2015-01-01')

Re: Django ORM query syntax enhancement

Hi Alexey, I find this approach really interesting, and I don't mind the API you've created at all. Even if this doesn't make it into Django, I think there's enough utility in your library that other people would want to use it. I'm not going to comment on specifics just yet like method names,