Re: Django ORM query syntax enhancement

2021-10-06 Thread Asif Saif Uddin 
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 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 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 
>>> expressions 
>>>  as the 
>>> basis instead.  Primarily because F expressions already support operator 
>>> overloading and are a natural intermediate object;  from there one can 
>>> create Q, OrderBy, and Func objects.
>>>
>>> In []: from model_values import F
>>>
>>> In []: F.user.created
>>> Out[]: FExpr(user__created)
>>>
>>> In []: F.user.created >= 0
>>> Out[]: 
>>>
>>> In []: F.user.created.min()
>>> Out[]: Min(FExpr(user__created))
>>>
>>> In []: -F.user.created
>>> Out[]: OrderBy(FExpr(user__created), descending=True)
>>>
>>> In []: F.text.iexact('...')
>>> Out[]: 
>>>
>>>
>>>
>>>
>>> On Thursday, October 6, 2016 at 10:04:56 AM UTC-7, Alexey Zankevich 
>>> wrote:

 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')
 >>> Q.tags[0] == 'thoughts'
 Q(tags__0='thoughts')
 >>> Q.tags[0:2].contains(['thoughts']) 
 Q(tags__0_2__contains=['thoughts'])


 2. Previously, it was only possible to call defined method (like it is 
 done for *is_not_null()* function) or registered with decorator. Now 
 if you try to call unknown function of sugar Q, it will internally pass 
 function name and append it as *__functionname *to lookup field:

 >>> Q.user.username.contains('Rodriguez')
 Q(user__username__contains='Rodriguez')


 There is no such function "contains" anymore in sugar Q, however, it 
 just adds *__contains* to lookup field and passes parameter to it.

 3. It will pass a tuple to lookup if multiple arguments passed:

 >>> Q.user.create_datetime.range(d1, d2)
 Q(user__create_datetime__range=(d1, d2))


 I think the library is at the final state now and isn't going to get 
 new substantial features, but responses are highly appreciated.

 Regards,
 Alexey


 On Sunday, August 16, 2015 at 4:18:26 PM UTC+3, Alexey Zankevich wrote:
>
> Hi all,
>
> This topic is related to the current ORM query syntax with underscores.
> There are lots of arguing related to it, anyway it has pros and cons.
>
> Let's take a concrete example of querying a model:
>
> >>> 
> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday)
>
>
> Pros:
>
> 1. The syntax is easy to understand
> 2. Can be extended with custom transforms and lookups
>
> However, there are several cons:
>
> 1. Long strings is hard to read, especially if we have fields with 
> underscores.
> It's really easy to make a mistake by missing one:
>
> >>> 
> GameSession.objects.filter(user_profile__last_login_date__gte=yesterday)
>
> Not easy to catch missing underscore between user and profile, is it? 
> Even
> though, it's not easy to say whether it should be "user_profile" 
> attribute or
> user.profile foreign key.
>
> 2. Query strings can't be reused, thus the approach violates DRY 
> principle.
> For example, we need to order results by last_login_date:
>
> >>> 
> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday) 
> \
> .order_by('user__profile__last_login_date')
>
> We can't keep user__profile_login_date as a variable as in the first 
> part of the
> expression we use a keyword argument, meanwhile in the second part - 
> just a 
> string. And thus we just have to type query path twice.
>
> 3. Lookup names not natural to Python language and require to be 
> remembered or
> looked up in documentation. For example, "__gte" or "__lte" lookups 
> tend to be
> confused with "ge" and "le" due to similarity to methods "__ge__" and 
> "__le__".
>
> 4. Lookup keywords limited to a single argument only, very 
> inconvenient when
> necessary to filter objects by range.
>
> I was thinking a lot trying to solve those issues, keeping in mind 
> Django
>

Re: Django ORM query syntax enhancement

2021-10-06 Thread 'Adam Johnson' via Django developers (Contributions to Django itself) 
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 django-model-values is maintained. Moreover they all
achieve their goals without any changes to Django, so there's not much of a
compelling reason to merge anything to core.

To consider adding "another way to do things" in the ORM we'd want more
evidence that users want it. I'd suggest further contributions and advocacy
for django-model-values or similar. Its documentation could definitely be
improved, and blog posts could promote its advantages.

On Wed, 6 Oct 2021 at 10:13, Asif Saif Uddin  wrote:

> 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 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 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
 expressions
  as the
 basis instead.  Primarily because F expressions already support operator
 overloading and are a natural intermediate object;  from there one can
 create Q, OrderBy, and Func objects.

 In []: from model_values import F

 In []: F.user.created
 Out[]: FExpr(user__created)

 In []: F.user.created >= 0
 Out[]: 

 In []: F.user.created.min()
 Out[]: Min(FExpr(user__created))

 In []: -F.user.created
 Out[]: OrderBy(FExpr(user__created), descending=True)

 In []: F.text.iexact('...')
 Out[]: 




 On Thursday, October 6, 2016 at 10:04:56 AM UTC-7, Alexey Zankevich
 wrote:
>
> 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')
> >>> Q.tags[0] == 'thoughts'
> Q(tags__0='thoughts')
> >>> Q.tags[0:2].contains(['thoughts'])
> Q(tags__0_2__contains=['thoughts'])
>
>
> 2. Previously, it was only possible to call defined method (like it is
> done for *is_not_null()* function) or registered with decorator. Now
> if you try to call unknown function of sugar Q, it will internally pass
> function name and append it as *__functionname *to lookup field:
>
> >>> Q.user.username.contains('Rodriguez')
> Q(user__username__contains='Rodriguez')
>
>
> There is no such function "contains" anymore in sugar Q, however, it
> just adds *__contains* to lookup field and passes parameter to it.
>
> 3. It will pass a tuple to lookup if multiple arguments passed:
>
> >>> Q.user.create_datetime.range(d1, d2)
> Q(user__create_datetime__range=(d1, d2))
>
>
> I think the library is at the final state now and isn't going to get
> new substantial features, but responses are highly appreciated.
>
> Regards,
> Alexey
>
>
> On Sunday, August 16, 2015 at 4:18:26 PM UTC+3, Alexey Zankevich wrote:
>>
>> Hi all,
>>
>> This topic is related to the current ORM query syntax with
>> underscores.
>> There are lots of arguing related to it, anyway it has pros and cons.
>>
>> Let's take a concrete example of querying a model:
>>
>> >>>
>> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday)
>>
>>
>> Pros:
>>
>> 1. The syntax is easy to understand
>> 2. Can be extended with custom transforms and lookups
>>
>> However, there are several cons:
>>
>> 1. Long strings is hard to read, especially if we have fields with
>> underscores.
>> It's really easy to make a mistake by missing one:
>>
>> >>>
>> GameSession.objects.filter(user_profile__last_login_date__gte=yesterday)
>>
>> Not easy to catch missing underscore between user and profile, is it?
>> Even
>> though, it's not easy to say whether it should be "user_profile"
>> attribute or
>> user.profile foreign key.
>>
>> 2. Query strings can't be reused, thus the approach violates DRY
>> principle.
>> For example, we need to order results by last_login_date:
>>
>>

Re: DEFAULT_AUTO_FIELD

2021-10-06 Thread 'Adam Johnson' via Django developers (Contributions to Django itself) 
As Mariusz wrote, it depends upon at least the M2M field migration being
fixed first.

‪On Mon, 4 Oct 2021 at 10:36, ‫אורי‬‎  wrote:‬

> Thank you.
>
>
>> In a future Django release the default value of DEFAULT_AUTO_FIELD
>>> 
>>> will be changed to BigAutoField
>>> 
>>> .
>>>
>>
> When do you expect this to happen?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABD5YeEPftdb_YRkbE1HK%2B%2BO34q%3DrvGr3wkuP6%3DR8Puuh%2B4sVA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3R5gQL%3D8ikY1v6uHPxDMVDidL6Bp20N6HR2GhET1-MyQ%40mail.gmail.com.

Re: Redirect type selection in django.contrib.redirects

2021-10-06 Thread 'Adam Johnson' via Django developers (Contributions to Django itself) 
This seems like a reasonable addition to me.

On Fri, 24 Sept 2021 at 08:08, Niccolò Mineo 
wrote:

> Hi. The marketing guys at my workplace asked for the ability to customise
> the redirect type  (301, 302) when creating redirects in the admin and I
> shipped this change a while ago. I believe this could be a nice addition to
> Django itself, too. What do you think?
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0ccdfe91-c97a-4363-9226-518310ceca04n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0Ztz84Gp_YJSjY0Z%2Bz4KnAp7MCa1onSvOD1hQKhD42AA%40mail.gmail.com.