Re: [Django] #32946: Prefer non-kwargs construction of dynamically generated Q objects

[Django]

#32946: Prefer non-kwargs construction of dynamically generated Q objects
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 Agreed.

 > I also think that `Q(a=1, b=2, _connector=Q.OR)` and/or the
 `reduce(...)` should be documented in the
 https://docs.djangoproject.com/en/3.2/topics/db/queries/#complex-lookups-
 with-q section. Dynamic Q construction is fairly common IME, doesn't
 appear to be covered there, and ultimately points to Q test cases which
 ''also'' don't show any form of dynamic variants.

 Using `Q(a=1, b=2, _connector=...)` internally is fine, but I don't think
 we would like to encourage users to use it. I'd add an example with
 `reduce()` which was mentioned in several tickets.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.edfe10edc55c2c7b27c312857d3923a4%40djangoproject.com.

[Django] #32954: Improve error message with URLValidator and schemes

[Django]

#32954: Improve error message with URLValidator and schemes
-+-
   Reporter:  tomdjango  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  3.2
  Uncategorized  |
   Severity:  Normal |   Keywords:  error message
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 If you limit the schemes for a URL to a subset of legal values with
 URLValidator, like this:

 url = models.URLField(max_length=200,
 validators=[URLValidator(["http","https"])])

 And then enter a value URL starting with "ftp://;, the error message given
 is

 Enter a valid URL.

 The URL is valid, so this does not give the user useful information for
 fixing the problem.  Something like

 URL must begin with one of [http, https]

 would be more helpful.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.130c1c90312e5ed6a4a26a47c764e6d1%40djangoproject.com.

Re: [Django] #32953: Enable optional auto-reloading for testserver

[Django]

#32953: Enable optional auto-reloading for testserver
-+-
 Reporter:  Igor Bakutin |Owner:  Igor
 |  Bakutin
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  4.0
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  testserver reloader  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Igor Bakutin):

 * owner:  Igor Bakutin => Igor Bakutin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0af9b944264e36f3a50b3980e9ac7c98%40djangoproject.com.

Re: [Django] #32953: Enable optional auto-reloading for testserver

[Django]

#32953: Enable optional auto-reloading for testserver
-+-
 Reporter:  Igor Bakutin |Owner:  Igor
 |  Bakutin
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  4.0
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  testserver reloader  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Igor Bakutin):

 * type:  Uncategorized => New feature


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.9c659677e559003621ad13d79db73dd6%40djangoproject.com.

[Django] #32953: Enable optional auto-reloading for testserver

[Django]

#32953: Enable optional auto-reloading for testserver
-+-
   Reporter:  Igor   |  Owner:  Igor Bakutin
  Bakutin|
   Type: | Status:  assigned
  Uncategorized  |
  Component:  Core   |Version:  4.0
  (Management commands)  |
   Severity:  Normal |   Keywords:  testserver reloader
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `django/core/management/commands/testserver.py:39` has the following
 comment

 {{{
 # Run the development server. Turn off auto-reloading because it causes
 # a strange error -- it causes this handle() method to be called
 # multiple times.
 }}}


 The task is to fix the issue and add optional `--autoreload` flag to the
 command

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.1d10eb21e02757a7e367bb79bd1693c4%40djangoproject.com.

Re: [Django] #32951: Remove Query.where_class in favor of using WhereNode directly.

[Django]

#32951: Remove Query.where_class in favor of using WhereNode directly.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  wherenode,   | Triage Stage:  Accepted
  where_class|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a709da3fab1ad144324e6612100ca36b%40djangoproject.com.

Re: [Django] #32688: The ON CONFLICT sql suffix creates a syntax error on m2m inserts

[Django]

#32688: The ON CONFLICT sql suffix creates a syntax error on m2m inserts
-+-
 Reporter:  Malik A. Rumi|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => needsinfo


Comment:

 I cannot reproduce this issue on PostgreSQL 11. Can you provide an SQL
 statement which crashes? or a sample project? and confirm your database
 version.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.144067c25dab409a2cebce49fb279d3b%40djangoproject.com.

Re: [Django] #32688: The ON CONFLICT sql suffix creates a syntax error on m2m inserts

[Django]

#32688: The ON CONFLICT sql suffix creates a syntax error on m2m inserts
-+-
 Reporter:  Malik A. Rumi|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Patrick K):

 * cc: Patrick K (added)
 * status:  closed => new
 * resolution:  invalid =>
 * type:  Uncategorized => Bug


Comment:

 I'm not 100% sure, but I think this needs to be reopened. I can easily
 reproduce this with the admin interface when trying to save an M2M with
 Postgres 11. I do understand that Postgres 9.x is not supported anymore,
 but IMHO this should not happen with Postgres 11.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.28743b84f290e55a1854317fe32bc278%40djangoproject.com.

Re: [Django] #32952: Django is not generating new session

[Django]

#32952: Django is not generating new session
--+--
 Reporter:  Inexpli   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.sessions  |  Version:  3.2
 Severity:  Normal|   Resolution:  invalid
 Keywords:  session, cookies  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Please don't use Trac as a support channel. Closing per
 TicketClosingReasons/UseSupportChannels.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.7c1c66a5c2fee7764e540c004e6dde38%40djangoproject.com.

Re: [Django] #28455: Create "inplace" QuerySets to speed up certain operations

[Django]

#28455: Create "inplace" QuerySets to speed up certain operations
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Keryn Knight):

 PR is https://github.com/django/django/pull/14675

 Based heavily on Anssi's original implementation idea. This introduces 2
 ways of opting out of cloning, both ostensibly private API. Firstly and
 primarily, a context manager which temporarily makes the current QuerySet
 (+ Query, implicitly) mutable:

 {{{
 with User.objects.all()._avoid_cloning() as queryset1:
 queryset1.filter(x=1).exclude(y=2).filter(z__in=[1,2,3])
 # OR
 queryset2 = User.objects.all()
 with queryset2._avoid_cloning():
 queryset2.filter(x=1).exclude(y=2).filter(z__in=[1,2,3])
 }}}

 And secondly, an imperative form, for use cases where there might be
 multiple filters across a long list of lines, where it's not desirable to
 muddy the VCS history and/or the indent depth by using the context
 manager:
 {{{
 queryset = User.objects.all()._disable_cloning()
 queryset.filter(x=1).exclude(y=2).filter(z__in=[1,2,3])
 queryset._enable_cloning()
 queryset2 = queryset.filter(abc='test')  # This should be a new clone, as
 usual.
 }}}

 There's currently no support for any sort of nesting or ensured balancing
 (as with the original implementation, as I understand it), so
 `._disable_cloning()._disable_cloning()._disable_cloning()` would be
 undone by a single `._enable_cloning()` call because it's a toggle rather
 than a stack of pushes/pops; hence the preference for the contextmanager.

 Given the following SQLite data:
 {{{
 In [1]: from django.contrib.auth.models import User, Group, Permission
 In [2]: Group.objects.count()
 Out[2]: 101
 In [3]: User.objects.count()
 Out[3]: 101
 In [4]: Permission.objects.count()
 Out[4]: 24
 In [5]: User.user_permissions.through.count()
 Out[5]: 0
 In [6]: for user in User.objects.all():
...: print(f'{user.groups.count()}, {user.groups.first().pk},
 {user.user_permissions.count()}')
 1, 1, 0
 1, 2, 0
 1, 3, 0
 1, 4, 0
 1, 5, 0
 ... they all have 1 group and zero permissions
 In[7]: from django.db import connection
 In[8]: connection.queries[-2:]
 [{'sql': 'SELECT "auth_user"."id", ... FROM "auth_user"',
   'time': '0.001'},
  {'sql': 'SELECT ("auth_user_groups"."user_id") AS
 "_prefetch_related_val_user_id", "auth_group"."id", "auth_group"."name"
 FROM "auth_group" INNER JOIN "auth_user_groups" ON ("auth_group"."id" =
 "auth_user_groups"."group_id") WHERE "auth_user_groups"."user_id" IN (1,
 2, 3, [...] 99, 100, 101)',
   'time': '0.000'}]
 }}}

 Before applying any of the changes:
 {{{
 In [2]: %timeit tuple(User.objects.all())
 1.26 ms ± 9.06 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
 (0 calls to ._clone)
 In [3]: %timeit tuple(User.objects.prefetch_related('groups'))
 6.52 ms ± 62.3 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
 (105 calls to ._clone)
 In [4]: %timeit tuple(User.objects.prefetch_related('groups',
 'user_permissions'))
 12.1 ms ± 226 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
 (213 calls to ._clone)
 }}}
 After enabling the avoidance cloning technique for prefetch_related only:
 {{{
 In [2]: %timeit tuple(User.objects.all())
 1.28 ms ± 16.5 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
 (0 calls to ._clone)
 In [3]: %timeit tuple(User.objects.prefetch_related('groups'))
 5.93 ms ± 53.4 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
 (4 calls to ._clone)
 In [4]: %timeit tuple(User.objects.prefetch_related('groups',
 'user_permissions'))
 10.2 ms ± 59.3 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
 (7 calls to ._clone)
 }}}

 So for the 1 prefetch it's a decrease of maybe ~9%, and for the 2
 prefetches it's a decrease of roughly ~15%. I make no pretense about being
 able to calculate improvement by factor vs percent and risk getting it
 wrong.

 The number of calls to clone was done by re-running the queries in fresh
 `ipython` sessions, having `_clone()` increment a global integer each time
 it's called. It isn't part of the actual timeit numbers.

 These improved prefetch timings are only found when hitting the
 `manager.get_queryset()` of `prefetch_one_level` because we can assume
 that returns a fresh QuerySet 

Re: [Django] #32952: Django is not generating new session (was: Since i removed sessionid in browser cookies, django is not creating new one)

[Django]

#32952: Django is not generating new session
--+--
 Reporter:  Inexpli   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  session, cookies  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.8d41e7955201e7155b6c97a9e2e6dabe%40djangoproject.com.

[Django] #32952: Since i removed sessionid in browser cookies, django is not creating new one

[Django]

#32952: Since i removed sessionid in browser cookies, django is not creating new
one
-+-
   Reporter:  Inexpli|  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  3.2
  contrib.sessions   |
   Severity:  Normal |   Keywords:  session, cookies
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 While i was creating shopping cart which depends on sessionid included in
 cookie files I once removed sessionid in my browser to test something and
 then i realised that django don't want to recreate new one. I was looking
 for solution in internet but i didn't found any equal problem to my and
 solution to it.

 By looking on the django docs. i wrote to setting.py hoping that it would
 help:

 {{{
 SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies'

 SESSION_COOKIE_HTTPONLY = True
 }}}

 but still sessionid in cookies doesn't occur.

 I read post that sessionid should be generated by django while there is
 request which require sessionid, and it would be in my situation solution
 on this problem but in the context_processors.py I wrote that i require
 sessionid globally:


 {{{
 def basket(request):
 try:
 customer = request.user.customer
 except:
 device = request.COOKIES['sessionid']

 customer, created = Customer.objects.get_or_create(device=device)

 order, created = Order.objects.get_or_create(
 customer=customer, complete=False)

 return {
 'order': order,
 }
 }}}

 And beacouse of the context_processors sends request for sessionid and it
 can't get one, this error occurs:
 https://i.stack.imgur.com/D3d9U.png

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.ac3a7d6001b55518364b36accd0976c5%40djangoproject.com.

Re: [Django] #32949: decimal.InvalidOperation error on DecimalField form field

[Django]

#32949: decimal.InvalidOperation error on DecimalField form field
-+
 Reporter:  yakimka  |Owner:  yakimka
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Jacob Walls):

 * owner:  nobody => yakimka
 * needs_docs:  1 => 0
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d0595c80afbb2686a23e7284abd1548d%40djangoproject.com.

Re: [Django] #32951: Remove Query.where_class in favor of using WhereNode directly.

[Django]

#32951: Remove Query.where_class in favor of using WhereNode directly.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  wherenode,   | Triage Stage:
  where_class|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14674 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6a10d5b39b3613d2a9126b8eb81bccd9%40djangoproject.com.

[Django] #32951: Remove Query.where_class in favor of using WhereNode directly.

[Django]

#32951: Remove Query.where_class in favor of using WhereNode directly.
-+-
   Reporter:  Nick Pope  |  Owner:  Nick Pope
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  layer (models, ORM)|   Keywords:  wherenode,
   Severity:  Normal |  where_class
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 #6261 added support for customized `WhereNode` and `QUERY_TERMS`.

 This was to "get GeoDjango working with the queryset-refactor branch" as
 it required a custom `GeoWhereNode` and being able to extend geographic
 lookup types.

 `QUERY_TERMS` was removed in 244cc401559e924355cf943b6b8e66ccf2f6da3a for
 Django 2.1 with the intended replacement being the Lookup Registration
 API.

 `GeoWhereNode` was removed in 3caf957ed5eaa831a485abcb89f27266dbf3e82b for
 Django 1.8, obsoleted by `GISLookup`.

 `Query.where_class` is internal and undocumented and is propagated around
 through other methods signatures, e.g. `.get_extra_restriction()`, which
 is also internal and undocumented. We should be able to remove this no
 longer necessary complexity and use `WhereNode` directly.

 Despite these being undocumented APIs, I don't know whether we want to go
 through a deprecation period?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.96a66694f9063c1274e49cef2940aadb%40djangoproject.com.

Re: [Django] #32688: The ON CONFLICT sql suffix creates a syntax error on m2m inserts

[Django]

#32688: The ON CONFLICT sql suffix creates a syntax error on m2m inserts
-+-
 Reporter:  Malik A. Rumi|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by sehmaschine):

 I'm having the same issue with Postgres 11. Just trying to update an M2M
 field (with both `set` or `add`) leads to this error.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b4a0b905ce71d591d757f7624767da55%40djangoproject.com.

Re: [Django] #32950: Remove "myproject" from imports in docs (was: Documentation errors in ModelAdmin objects (/ref/contrib/admin)?)

[Django]

#32950: Remove "myproject" from imports in docs
---+
 Reporter:  Ken Whitesell  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords:  ModelAdmin | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Yes, I think that should be adjusted. A complete audit:
 {{{
 docs/ref/contrib/syndication.txt:from myproject.feeds import
 LatestEntriesFeed
 docs/ref/contrib/syndication.txt:from myproject.feeds import
 AtomSiteNewsFeed, RssSiteNewsFeed
 docs/ref/contrib/admin/index.txt:from myproject.myapp.models
 import Author
 docs/ref/contrib/admin/index.txt:from myproject.myapp.models
 import Author
 docs/ref/contrib/admin/index.txt:from myproject.admin_site import
 custom_admin_site
 docs/ref/contrib/admin/index.txt:from myproject.myapp.models import
 Image, Product
 docs/ref/contrib/admin/index.txt:from myproject.admin import
 advanced_site, basic_site
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.cf440a078fd9d7e01e3853c041a6e348%40djangoproject.com.

[Django] #32950: Documentation errors in ModelAdmin objects (/ref/contrib/admin)?

[Django]

#32950: Documentation errors in ModelAdmin objects (/ref/contrib/admin)?
-+
   Reporter:  Ken Whitesell  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  3.2
   Severity:  Normal |   Keywords:  ModelAdmin
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 The first example in the section for
 
[https://docs.djangoproject.com/en/3.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin
 class ModelAdmin] has the following line:

 {{{
 #!python
 from myproject.myapp.models import Author
 }}}
 (There are multiple occurrences of this on this page.)
 Is it proper to specify the "myproject" path component here?

 It looks to me like this would only be valid if the manage.py file were
 located "above" the myproject directory, which is different from where the
 startproject command places it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/055.7db58e470c1c0b87587bced6b64fc9ca%40djangoproject.com.

Re: [Django] #32949: decimal.InvalidOperation error on DecimalField form field

[Django]

#32949: decimal.InvalidOperation error on DecimalField form field
-+
 Reporter:  yakimka  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted
 * severity:  Normal => Release blocker
 * needs_docs:  0 => 1


Comment:

 Thanks for the report.

 This is a regression in cc3d24d7d577f174937a0744d886c4c7123cfa85.

 The # originally added handling of `NaN` and `Inf` in `DecimalField`
 (in 692fd7da5e5bfe1533c40f94999ea42f9b986356).
 It looked redundant but wasn't because `MaxValueValidator` does not handle
 `Decimal('NaN')`.

 Here's a minimal diff showing that:

 {{{
 diff --git a/tests/validators/tests.py b/tests/validators/tests.py
 index e39d0e3a1c..42665c6ccb 100644
 --- a/tests/validators/tests.py
 +++ b/tests/validators/tests.py
 @@ -214,6 +214,7 @@ TEST_DATA = [

  (MaxValueValidator(0), 1, ValidationError),
  (MaxValueValidator(NOW), NOW + timedelta(days=1), ValidationError),
 +(MaxValueValidator(Decimal('NaN')), 1, ValidationError),

  (MinValueValidator(-10), -10, None),
  (MinValueValidator(-10), 10, None),
 }}}

 Results in:

 {{{
 ==
 ERROR: test_validators (validators.tests.TestValidators)
 [MaxValueValidator] (value=1)
 --
 Traceback (most recent call last):
   File "...django/tests/validators/tests.py", line 355, in test_validators
 validator(value)
   File "...django/django/core/validators.py", line 358, in __call__
 if self.compare(cleaned, limit_value):
   File "...django/django/core/validators.py", line 383, in compare
 return a > b
 decimal.InvalidOperation: []
 }}}

 You PR here should (partially?) revert
 cc3d24d7d577f174937a0744d886c4c7123cfa85 (see #31806 and
 [https://github.com/django/django/pull/13212/ the PR for discussion and
 related commits]).

 Add `max_value` to the existing `test_enter_a_numer_error()` case:

 {{{
 diff --git a/tests/forms_tests/field_tests/test_decimalfield.py
 b/tests/forms_tests/field_tests/test_decimalfield.py
 index c8b044722e..04c555c4ad 100644
 --- a/tests/forms_tests/field_tests/test_decimalfield.py
 +++ b/tests/forms_tests/field_tests/test_decimalfield.py
 @@ -49,7 +49,7 @@ class DecimalFieldTest(FormFieldAssertionsMixin,
 SimpleTestCase):
  self.assertIsNone(f.min_value)

  def test_enter_a_number_error(self):
 -f = DecimalField(max_digits=4, decimal_places=2)
 +f = DecimalField(max_value=1, max_digits=4, decimal_places=2)
  values = (
 }}}

 It looks as if test `test_value_placeholder_with_decimal_field
 (forms_tests.tests.test_validators.ValidatorCustomMessageTests)` will need
 adjusting.

 A release note in 3.2.6.txt will be needed.
 Good spot.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.035b1a15efc961cd3a6063cf5cef29ee%40djangoproject.com.

Re: [Django] #28455: Create "inplace" QuerySets to speed up certain operations

[Django]

#28455: Create "inplace" QuerySets to speed up certain operations
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Keryn Knight):

 * owner:  nobody => Keryn Knight
 * status:  new => assigned


Comment:

 I don't think I'm stepping on anyone's toes at this juncture, but do shout
 if so!

 I'd accidentally been wading into similar waters when I stumbled across
 this ticket, which has ended up at roughly the same place/conclusions, and
 I have a rough sketch based on the prior branches for an MVP to resume
 discussion on this. I'll tidy up what I have, try and gather some simple
 benchmarks, and throw it into the PR queue for sanity checking.

 I guarantee there's more nuance to this than I've anticipated so far, but
 we've got to restart somewhere, right? If it works out, all the better :)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.2e561b84b5871b94ca82ef1a6068fc02%40djangoproject.com.

Re: [Django] #32704: QuerySet.defer() doesn't clear deferred field when chaining with only().

[Django]

#32704: QuerySet.defer() doesn't clear deferred field when chaining with only().
-+-
 Reporter:  Manuel Baclet|Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  defer only   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"fd999318ad78613227cdb7c5656345d9e216802b" fd999318]:
 {{{
 #!CommitTicketReference repository=""
 revision="fd999318ad78613227cdb7c5656345d9e216802b"
 Fixed #32704 -- Fixed list of deferred fields when chaining
 QuerySet.defer() after only().
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.57040e6fde3cd961f587b80dc595e0b7%40djangoproject.com.

Re: [Django] #32949: decimal.InvalidOperation error on DecimalField form field

[Django]

#32949: decimal.InvalidOperation error on DecimalField form field
-+--
 Reporter:  yakimka  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by yakimka):

 [https://github.com/django/django/pull/14645 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.cd61be479dfe40dac5e97d3ab8f9b8b2%40djangoproject.com.

[Django] #32949: decimal.InvalidOperation error on DecimalField form field

[Django]

#32949: decimal.InvalidOperation error on DecimalField form field
--+
   Reporter:  yakimka |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |Version:  3.2
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 I have a form with DecimalField and max_value argument:


 {{{
 class OrderForm(forms.ModelForm):
 sum = DecimalField(max_value=12)

 class Meta:
 model = Order
 fields = ['sum']

 # model
 class Order(models.Model):
 sum = models.DecimalField(
 'Sum',
 max_digits=18,
 decimal_places=2,
 default=0
 )
 }}}


 If I pass "NaN" value to this form it will fail with
 decimal.InvalidOperation error.

 https://github.com/django/django/pull/14645

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.2e3739e1c109d60d79e6fa35efcc9c17%40djangoproject.com.

Re: [Django] #32938: App name changes and is confusing to use across a project

[Django]

#32938: App name changes and is confusing to use across a project
---+--
 Reporter:  Michael|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  3.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Old description:

> I hope this is just a case of "you doing it wrong". This issue has been a
> thorn in my side for so long, and is an issue of constant confusion for
> me. So like many larger projects, my applications doesnt have all the
> django apps in the root folder. I created a framework as follows:
>
> **project_root**
> - **core** - contains essentials apps for the framework
> - **applib** - contains apps that a certain deployment may or may not
> use
> - **dist** - contains apps that are only used for a certain
> distribution
>
> Now say there is app **foo** within **core**, then from experimentation
> (as in things don't work otherwise) one must set:
> {{{
> # Filename: project_root/core/foo/apps.py
> from django.apps import AppConfig
>
> class FooConfig(AppConfig):
> name = 'core.foo'  # I hope here I am doing it wrong, and this is the
> source of trouble
> }}}
>
> Okay great so the app name must include the dotted path from the project
> root, no problem. So now all the **reverse(...)** and **{% url '...' %}**
> use this dotted path app name.
>
> Then say one has an issue of circular imports with models, so one must
> lazy import the model name. However it does not use the app name, it uses
> some other combination, after trying various ways turns out it must be in
> like this:
>
> {{{
> # Filename: applib/bar/models.py
>
> class BarModel(models.Model):
> foo = models.ForeignKey('foo.FooModel', on_delete=models.PROTECT,
> null=True, blank=True)
> }}}
> Notice how now the appname is '**foo**', whereas most of the time it is
> '**core.foo**'.
> Additionally with migrations it uses this shorter app name. If one looks
> in the django_migration table and migration files, one sees  '**foo**'
> instead of '**core.foo**' (which is what it was explicitly set to).
>
> Is this not a bit confusing. What I am suggesting is consistency in the
> app.name.
> The app name is not clearly define and consistantly applied.
> Can we set the app name to be same when importing a model, in migrations,
> and in i'ts apps.py name?

New description:

 I hope this is just a case of "you doing it wrong". This issue has been a
 thorn in my side for so long, and is an issue of constant confusion for
 me. So like many larger projects, my applications doesnt have all the
 django apps in the root folder. I created a framework as follows:

 **project_root**
 - **core** - contains essentials apps for the framework
 - **applib** - contains apps that a certain deployment may or may not
 use
 - **dist** - contains apps that are only used for a certain
 distribution

 Now say there is app **foo** within **core**, then from experimentation
 (as in things don't work otherwise) one must set:
 {{{
 # Filename: project_root/core/foo/apps.py
 from django.apps import AppConfig

 class FooConfig(AppConfig):
 name = 'core.foo'  # I hope here I am doing it wrong, and this is the
 source of trouble
 }}}

 Okay great so the app name must include the dotted path from the project
 root, no problem. So now all the **reverse(...)** and **{% url '...' %}**
 use this dotted path app name.

 Then say one has an issue of circular imports with models, so one must
 lazy import the model name. However it does not use the app name, it uses
 some other combination, after trying various ways turns out it must be in
 like this:

 {{{
 # Filename: applib/bar/models.py

 class BarModel(models.Model):
 foo = models.ForeignKey('foo.FooModel', on_delete=models.PROTECT,
 null=True, blank=True)
 }}}
 Notice how now the appname is '**foo**', whereas most of the time it is
 '**core.foo**'.
 Additionally with migrations it uses this shorter app name. If one looks
 in the django_migration table and migration files, one sees  '**foo**'
 instead of '**core.foo**' (which is what it was explicitly set to).

 Is this not a bit confusing. What I am suggesting is consistency in the
 app.name.
 The app name is not clearly define and consistantly applied.
 Can we set the app name to be same when importing a model, in migrations,
 and in its apps.py name?

--

Comment (by Tim Graham):

 > Can we set the app name to be same when importing a model, in
 migrations, and in its apps.py name?

 

Re: [Django] #32947: Missing call `make_hashable` on `through_fields` in `ManyToManyRel`

[Django]

#32947: Missing call `make_hashable` on `through_fields` in `ManyToManyRel`
-+-
 Reporter:  Tomasz Wójcik|Owner:  Tomasz
 |  Wójcik
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  ManyToManyRel,through_fields,  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: David Wobrock (added)


Comment:

 Regression in c32d8f33d8e988a376e44997b8f3606d821f305e.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.bbf0a07e05d0ad39b7e9020d2800da47%40djangoproject.com.

Re: [Django] #32947: Missing call `make_hashable` on `through_fields` in `ManyToManyRel`

[Django]

#32947: Missing call `make_hashable` on `through_fields` in `ManyToManyRel`
-+-
 Reporter:  Tomasz Wójcik|Owner:  Tomasz
 |  Wójcik
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  ManyToManyRel,through_fields,  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * severity:  Normal => Release blocker
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report.

 [https://github.com/django/django/pull/14672 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.5f485f1503d2758b1089387291a9135a%40djangoproject.com.

[Django] #32948: Optimise Q combination and inversion

[Django]

#32948: Optimise Q combination and inversion
-+-
   Reporter:  Keryn  |  Owner:  Keryn Knight
  Knight |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This is corollary to #32946 and #32940.

 Q is currently inconsistent with it's friends `WhereNode` and `Node` in
 that it doesn't use the `_new_instance` trick. Even using the
 `_new_instance` trick leaves some performance on the table vs just
 inlining the `__class__` switch, because it's an extra method call which
 affects both `_combine()` and `__invert__()`.

 The `_combine` method also has conditionals for what to do about an
 ''empty'' node being combined, either lhs or rhs. One side uses
 `deconstruct`, the other uses the shallow copy protocol (only since
 c8b659430556dca0b2fe27cf2ea0f8290dbafecd), which is unimplemented.

 If `__copy__` is not implemented, it ultimately falls back (after some
 branching checks) to the builtin `__reduce_ex__(4)` + `copy._reconstruct`
 which gives:
 {{{
 In [3]: x = Q()
 In [4]: %timeit copy.copy(x)
 2.2 µs ± 70.9 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
 In [5]: %timeit copy.copy(Q())
 3.52 µs ± 264 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
 }}}

 If we implement the necessary method like so:
 {{{
 def __copy__(self):
 obj = self._new_instance()
 obj.__dict__ = self.__dict__.copy()
 return obj
 }}}
 we can reduce those numbers to:
 {{{
 In [3]: x = Q()
 In [4]: %timeit copy.copy(x)
 1.27 µs ± 6.19 ns per loop (mean ± std. dev. of 7 runs, 100 loops
 each)
 In [5]: %timeit copy.copy(Q())
 2.37 µs ± 28.7 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
 }}}

 we can then reduce the work further by not invoking `copy.copy()` at all,
 by setting the `copy = __copy__` attribute on the Q class.

 From there, we can avoid calling `self.deconstruct()` at all, instead
 calling `self.copy()` knowing that `self` has values, but `other` does
 not. Both are basically on-par with eachother speedwise, with deconstruct
 being faster on empty nodes (which `self` isn't) and copy being minimally
 faster when there's a different connector (eg: `OR`).

 For inverting, we can similarly change it to avoid the `Node.add()` call:
 {{{
 def __invert__(self):
 obj = self.copy()
 obj.negate()
 return obj
 }}}
 which would allow it to go from:
 {{{
 In [2]: %timeit ~Q()
 2.89 µs ± 18.7 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
 In [3]: %timeit ~Q(a=1, b=2, c=3, d=4)
 3.77 µs ± 57.1 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
 }}}
 to:
 {{{
 In [2]: %timeit ~Q()
 2.34 µs ± 9.49 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
 In [3]: %timeit ~Q(a=1, b=2, c=3, d=4)
 3.14 µs ± 72.5 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
 }}}


 In totality, then, baselines:
 {{{
 In [2]: full = Q(a=1, b=2, c=3)
 In [3]: full2 = Q(d=4, e=5, f=6)
 In [4]: empty = Q()
 In [5]: %timeit full & full2
 2.65 µs ± 17.9 ns per loop (mean ± std. dev. of 7 runs, 10
 loops each)
 In [6]: %timeit full | full2
 3 µs ± 39.1 ns per loop (mean ± std. dev. of 7 runs, 10 loops
 each)
 In [7]: %timeit ~(full | full2)
 5.09 µs ± 122 ns per loop (mean ± std. dev. of 7 runs, 10
 loops each)
 In [8]: %timeit ~(full & full2)
 4.67 µs ± 58.5 ns per loop (mean ± std. dev. of 7 runs, 10
 loops each)
 In [9]: %timeit empty & full
 2.81 µs ± 18.3 ns per loop (mean ± std. dev. of 7 runs, 10
 loops each)
 In [10]: %timeit full & empty
 3.16 µs ± 43.4 ns per loop (mean ± std. dev. of 7 runs, 10
 loops each)
 In [11]: %timeit empty | full
 2.8 µs ± 22.9 ns per loop (mean ± std. dev. of 7 runs, 10
 loops each)
 In [12]: %timeit full | empty
 3.13 µs ± 20.3 ns per loop (mean ± std. dev. of 7 runs, 10
 loops each)
 In [13]: values = (Q(a=1), Q(b=2), Q(c=3), Q(d=4), Q(e__in=[1,2,3,4]))
 In [14]: %timeit reduce(or_, values)
 12 µs ± 212 ns per loop (mean ± std. dev. of 7 runs, 10 loops
 each)
 }}}

 and after the changes:
 {{{
 In [5]: %timeit full & full2
 2.11 µs ± 20.8 ns per loop (mean ± std. dev. of 7 runs, 10
 loops each)
 In [6]: %timeit full | full2
 2.39 µs ± 37.7 ns per loop (mean ± std. dev. of 7 runs, 10
 loops each)
 In [7]: %timeit ~(full | full2)
  

Re: [Django] #32947: Missing call `make_hashable` on `through_fields` in `ManyToManyRel`

[Django]

#32947: Missing call `make_hashable` on `through_fields` in `ManyToManyRel`
-+-
 Reporter:  Tomasz Wójcik|Owner:  Tomasz
 |  Wójcik
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  ManyToManyRel,through_fields,  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tomasz Wójcik):

 * owner:  nobody => Tomasz Wójcik
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.695755f8015a1642a374632c0fec16bc%40djangoproject.com.

[Django] #32947: Missing call `make_hashable` on `through_fields` in `ManyToManyRel`

[Django]

#32947: Missing call `make_hashable` on `through_fields` in `ManyToManyRel`
-+-
   Reporter:  Tomasz |  Owner:  nobody
  Wójcik |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  ManyToManyRel,through_fields,
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 In 3.2 `identity` property has been added to all `ForeignObjectRel` to
 make it possible to compare them. A hash is derived from said `identity`
 and it's possible because `identity` is a tuple. To make
 `limit_choices_to` hashable (one of this tuple elements),
 
[https://github.com/django/django/commit/0ef04fdd7ab75daa59536261bbfc5da4c4e31079
 #diff-edcf303eda6c4eaf2fa963e4d39d80c818bb786817d63772c636b3272cb659eb
 there's a call] to `make_hashable`.

 It happens that `through_fields` can be a list. In such case, this
 `make_hashable` call is missing in
 
[https://github.com/django/django/blob/b6475d7d7940f3ce575e0b0f2d83e517f899b4cf/django/db/models/fields/reverse_related.py#L309-L315
 ManyToManyRel].

 For some reason it only fails on checking proxy model. I think proxy
 models have 29 checks and normal ones 24, hence the issue, but that's just
 a guess.

 Minimal repro:

 {{{

 class Parent(models.Model):
 name = models.CharField(max_length=256)


 class ProxyParent(Parent):
 class Meta:
 proxy = True


 class Child(models.Model):
 parent = models.ForeignKey(Parent, on_delete=models.CASCADE)
 many_to_many_field = models.ManyToManyField(
 to=Parent,
 through="ManyToManyModel",
 through_fields=['child', 'parent'],
 related_name="something"
 )


 class ManyToManyModel(models.Model):
 parent = models.ForeignKey(Parent, on_delete=models.CASCADE,
 related_name='+')
 child = models.ForeignKey(Child, on_delete=models.CASCADE,
 related_name='+')
 second_child = models.ForeignKey(Child, on_delete=models.CASCADE,
 null=True, default=None)

 }}}

 Which will result in

 {{{
   File "manage.py", line 23, in 
 main()
   File "manage.py", line 19, in main
 execute_from_command_line(sys.argv)
   File "/home/tom/PycharmProjects/broken_m2m_project/venv/lib/python3.8
 /site-packages/django/core/management/__init__.py", line 419, in
 execute_from_command_line
 utility.execute()
   File "/home/tom/PycharmProjects/broken_m2m_project/venv/lib/python3.8
 /site-packages/django/core/management/__init__.py", line 413, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/tom/PycharmProjects/broken_m2m_project/venv/lib/python3.8
 /site-packages/django/core/management/base.py", line 354, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/tom/PycharmProjects/broken_m2m_project/venv/lib/python3.8
 /site-packages/django/core/management/base.py", line 393, in execute
 self.check()
   File "/home/tom/PycharmProjects/broken_m2m_project/venv/lib/python3.8
 /site-packages/django/core/management/base.py", line 419, in check
 all_issues = checks.run_checks(
   File "/home/tom/PycharmProjects/broken_m2m_project/venv/lib/python3.8
 /site-packages/django/core/checks/registry.py", line 76, in run_checks
 new_errors = check(app_configs=app_configs, databases=databases)
   File "/home/tom/PycharmProjects/broken_m2m_project/venv/lib/python3.8
 /site-packages/django/core/checks/model_checks.py", line 34, in
 check_all_models
 errors.extend(model.check(**kwargs))
   File "/home/tom/PycharmProjects/broken_m2m_project/venv/lib/python3.8
 /site-packages/django/db/models/base.py", line 1277, in check
 *cls._check_field_name_clashes(),
   File
 "/home/tom/PycharmProjects/djangbroken_m2m_projectProject/venv/lib/python3.8
 /site-packages/django/db/models/base.py", line 1465, in
 _check_field_name_clashes
 if f not in used_fields:
   File "/home/tom/PycharmProjects/broken_m2m_project/venv/lib/python3.8
 /site-packages/django/db/models/fields/reverse_related.py", line 140, in
 __hash__
 return hash(self.identity)
 TypeError: unhashable type: 'list'
 }}}

 Solution: Add missing `make_hashable` call on `self.through_fields` in
 `ManyToManyRel`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [Django] #32938: App name changes and is confusing to use across a project

[Django]

#32938: App name changes and is confusing to use across a project
---+--
 Reporter:  Michael|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  3.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Michael):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Replying to [comment:1 Tim Graham]:
 > I don't want to be dismissive of your confusion, but I don't see any
 actionable suggestion in this ticket. See
 TicketClosingReasons/UseSupportChannels for ways to get help. Feel free to
 create a new ticket or repurpose this one if you have some specific
 suggestion after your understanding is clarified.
 >
 > It may help to read about the difference between
 
[https://docs.djangoproject.com/en/dev/ref/applications/#django.apps.AppConfig.name
 AppConfig.name] and
 
[https://docs.djangoproject.com/en/dev/ref/applications/#django.apps.AppConfig.label
 AppConfig.label].

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.21bb29bd316774d73c5b3d482d33a4ce%40djangoproject.com.

Re: [Django] #32938: App name changes and is confusing to use across a project

[Django]

#32938: App name changes and is confusing to use across a project
---+--
 Reporter:  Michael|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Michael):

 * status:  closed => new
 * resolution:  invalid =>


Old description:

> I hope this is just a case of "you doing it wrong". This issue has been a
> thorn in my side for so long, and is an issue of constant confusion for
> me. So like many larger projects, my applications doesnt have all the
> django apps in the root folder. I created a framework as follows:
>
> **project_root**
> - **core** - contains essentials apps for the framework
> - **applib** - contains apps that a certain deployment may or may not
> use
> - **dist** - contains apps that are only used for a certain
> distribution
>
> Now say there is app **foo** within **core**, then from experimentation
> (as in things don't work otherwise) one must set:
> {{{
> # Filename: project_root/core/foo/apps.py
> from django.apps import AppConfig
>
> class FooConfig(AppConfig):
> name = 'core.foo'  # I hope here I am doing it wrong, and this is the
> source of trouble
> }}}
>
> Okay great so the app name must include the dotted path from the project
> root, no problem. So now all the **reverse(...)** and **{% url '...' %}**
> use this dotted path app name.
>
> Then say one has an issue of circular imports with models, so one must
> lazy import the model name. However it does not use the app name, it uses
> some other combination, after trying various ways turns out it must be in
> like this:
>
> {{{
> # Filename: applib/bar/models.py
>
> class BarModel(models.Model):
> foo = models.ForeignKey('foo.FooModel', on_delete=models.PROTECT,
> null=True, blank=True)
> }}}
> Notice how now the appname is '**foo**', whereas most of the time it is
> '**core.foo**'.
> Additionally with migrations it uses this shorter app name. If one looks
> in the django_migration table and migration files, one sees  '**foo**'
> instead of '**core.foo**' (which is what it was explicitly set to).
>
> Is this not a bit confusing?

New description:

 I hope this is just a case of "you doing it wrong". This issue has been a
 thorn in my side for so long, and is an issue of constant confusion for
 me. So like many larger projects, my applications doesnt have all the
 django apps in the root folder. I created a framework as follows:

 **project_root**
 - **core** - contains essentials apps for the framework
 - **applib** - contains apps that a certain deployment may or may not
 use
 - **dist** - contains apps that are only used for a certain
 distribution

 Now say there is app **foo** within **core**, then from experimentation
 (as in things don't work otherwise) one must set:
 {{{
 # Filename: project_root/core/foo/apps.py
 from django.apps import AppConfig

 class FooConfig(AppConfig):
 name = 'core.foo'  # I hope here I am doing it wrong, and this is the
 source of trouble
 }}}

 Okay great so the app name must include the dotted path from the project
 root, no problem. So now all the **reverse(...)** and **{% url '...' %}**
 use this dotted path app name.

 Then say one has an issue of circular imports with models, so one must
 lazy import the model name. However it does not use the app name, it uses
 some other combination, after trying various ways turns out it must be in
 like this:

 {{{
 # Filename: applib/bar/models.py

 class BarModel(models.Model):
 foo = models.ForeignKey('foo.FooModel', on_delete=models.PROTECT,
 null=True, blank=True)
 }}}
 Notice how now the appname is '**foo**', whereas most of the time it is
 '**core.foo**'.
 Additionally with migrations it uses this shorter app name. If one looks
 in the django_migration table and migration files, one sees  '**foo**'
 instead of '**core.foo**' (which is what it was explicitly set to).

 Is this not a bit confusing. What I am suggesting is consistency in the
 app.name.
 The app name is not clearly define and consistantly applied.
 Can we set the app name to be same when importing a model, in migrations,
 and in i'ts apps.py name?

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving 

Re: [Django] #32944: Simplify where clause creation where the WhereNode is immediately created and then added to and then returned.

[Django]

#32944: Simplify where clause creation where the WhereNode is immediately 
created
and then added to and then returned.
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"6a970a8b4600eb91be25f38caed0a52269d6303d" 6a970a8]:
 {{{
 #!CommitTicketReference repository=""
 revision="6a970a8b4600eb91be25f38caed0a52269d6303d"
 Fixed #32944 -- Avoided unnecessary WhereNode.add() calls.

 Co-authored-by: Mariusz Felisiak 
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2cf0d6651a66861fde6f9d4b65111958%40djangoproject.com.

Re: [Django] #31676: Document DEP 10 governance

[Django]

#31676: Document DEP 10 governance
-+-
 Reporter:  James Bennett|Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14670 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.18e11fe2768370eff88990006780872e%40djangoproject.com.

Re: [Django] #29898: Adapt schema editors to operate from model states instead of fake rendered models

[Django]

#29898: Adapt schema editors to operate from model states instead of fake 
rendered
models
-+-
 Reporter:  Simon Charette   |Owner:  Manav
 Type:   |  Agarwal
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * cc: David Wobrock (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8dbdd7d577cc866b1af38f50c1c183bb%40djangoproject.com.

[Django] #32946: Prefer non-kwargs construction of dynamically generated Q objects

[Django]

#32946: Prefer non-kwargs construction of dynamically generated Q objects
-+-
   Reporter:  Keryn  |  Owner:  Keryn Knight
  Knight |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 There are a number of places where Q objects are created dynamically to do
 things like construct a big OR expression, but they do so in the
 historically available API way; because once upon a time there was no way
 to pass the connector in the Q constructor, to make a OR node would've
 required doing:
 {{{
 x = Q(a=1, b=2)
 x.connector = Q.OR
 }}}
 which understandably was not the ideal from the general public API
 standpoint, and so everyone re-uses the `|` pattern.
 But that changed  way back when, in
 508b5debfb16843a8443ebac82c1fb91f15da687 for #11964, and now it ''can'' be
 done as `Q(a=1, b=2, _connector=Q.OR)`

 This is important because it's a substantially faster way of constructing
 a single Q object which does the right thing, because it ignores the
 complexity of cloning an instance and combining the parts into it. Here
 follows demonstration data.

 The smallest data point to consider is that sending in kwargs is
 (unfortunately) slower because they're sorted (which I don't think is
 correct, particularly, but that's a separate ticket tbh):

 {{{
 In [2]: %timeit Q(a=1, b=2, c=3, d=4)
 1.85 µs ± 14.8 ns per loop (mean ± std. dev. of 7 runs, 100
 loops each)
 In [3]: %timeit Q(('a', 1), ('b', 2), ('c', 3), ('d', 4))
 1.2 µs ± 10.4 ns per loop (mean ± std. dev. of 7 runs, 100
 loops each)
 In [4]: Q(a=1, b=2, c=3, d=4) == Q(('a', 1), ('b', 2), ('c', 3), ('d', 4))
 True
 }}}

 Now, one of the common ways to build a dynamic Q is to use
 `functools.reduce` and `operator.or_`, like the below, which is a
 facsimile of the usage in Django and elsewhere:

 {{{
 In [1]: from functools import reduce
...: from operator import or_
...: from django.db.models.query_utils import Q
 In [2]: values = (Q(a=1), Q(b=2), Q(c=3), Q(d=4), Q(e__in=[1,2,3,4]))
 In [3]: %timeit reduce(or_, values)
 12.3 µs ± 91 ns per loop (mean ± std. dev. of 7 runs, 10 loops
 each)
 In [4]: %timeit Q(a=1, b=2, c=3, d=4, e__in=[1,2,3,4], _connector=Q.OR)
 2.02 µs ± 23.5 ns per loop (mean ± std. dev. of 7 runs, 10
 loops each)
 In [5]: %timeit Q(('a', 1), ('b', 2), ('c', 3), ('d', 4), ('e__in', [1, 2,
 3, 4]), _connector=Q.OR)
 1.4 µs ± 2.31 ns per loop (mean ± std. dev. of 7 runs, 100
 loops each)
 }}}

 In the reduce given above, that's 5 Q objects created initially, and then
 4 additional Q objects created, vs 1 for the latter. Which is basically
 borne out by the timings, `1.4 * 9 == 12.6`.

 Another usage which comes up is to do something like `Q(**{field.name:
 xxx})` when `Q((field.name, xxx))` would suffice.

 Or doing something like:
 {{{
 x = models.Q()
 if y:
 x |= models.Q(**{field: '!'})
 if z:
 x |= models.Q(**{field: '?'})
 }}}
 when it could be:
 {{{
 x = []
 if y:
 x.append((field, '!'))
 if z:
 x.append((field, '?'))
 q = Q(x, _connector=Q.OR)
 }}}
 and so on.

 I have a patch which targets most/all? of the constructions I think it
 might make sense to change, and assuming the CI passes we can discuss from
 there.

 I also think that `Q(a=1, b=2, _connector=Q.OR)` and/or the `reduce(...)`
 should be documented in the
 https://docs.djangoproject.com/en/3.2/topics/db/queries/#complex-lookups-
 with-q section. Dynamic Q construction is fairly common IME, doesn't
 appear to be covered there, and ultimately points to Q test cases which
 ''also'' don't show any form of dynamic variants.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.f1e1fa46bbe16f07196e51b8df5933e9%40djangoproject.com.

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  Moses
 |  Mugisha
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Krzysztof Szularz):

 * cc: Krzysztof Szularz (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.a75756058e14c50d8d9f5e779da2bea1%40djangoproject.com.

Re: [Django] #31676: Document DEP 10 governance

[Django]

#31676: Document DEP 10 governance
-+-
 Reporter:  James Bennett|Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  James Bennett => Mariusz Felisiak
 * needs_docs:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.2fb4a48c3785f16105ee92a517a0bbfc%40djangoproject.com.

Re: [Django] #32940: Consider removing unused/unnecessary functionality in tree.Node.add

[Django]

#32940: Consider removing unused/unnecessary functionality in tree.Node.add
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * resolution:   => fixed


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b30eb3dd572e53a021abe04a97471ab9%40djangoproject.com.

Re: [Django] #32940: Consider removing unused/unnecessary functionality in tree.Node.add

[Django]

#32940: Consider removing unused/unnecessary functionality in tree.Node.add
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"fb35e0a2feb36e60b93a12dd43eb9eed2015adda" fb35e0a2]:
 {{{
 #!CommitTicketReference repository=""
 revision="fb35e0a2feb36e60b93a12dd43eb9eed2015adda"
 Refs #32940 -- Removed Node.add()'s unused squash parameter.

 Unused since its introduction in d3f00bd5706b35961390d3814dd7e322ead3a9a3.

 Co-authored-by: Nick Pope 
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.51a8d219deafbb55e692da42cbed5979%40djangoproject.com.

Re: [Django] #32940: Consider removing unused/unnecessary functionality in tree.Node.add

[Django]

#32940: Consider removing unused/unnecessary functionality in tree.Node.add
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"ff661dbd506efbdf51cc8da89cb98731c8a62f49" ff661db]:
 {{{
 #!CommitTicketReference repository=""
 revision="ff661dbd506efbdf51cc8da89cb98731c8a62f49"
 Refs #32940 -- Removed unnecessary branch in Node.add().

 The "data in self.children" branch was causing data.__eq__ to be
 called for each entries in "self.children" which resulted in a huge
 slowdown during queryset construction.

 It's purpose was to prevent queries of the form
 Model.objects.filter(foo='bar').filter(foo='bar')
 from resulting in
 WHERE foo='bar' AND foo='bar'
 but it's not covered by the suite and has arguable performance benefits
 since it's not very common and SQL engines are usually very good at
 folding/optimizing these.

 See also #32632 for prior discussion around comparing data to the
 Node's children.

 Co-authored-by: Nick Pope 
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f0d26e61f56a9478f0a9e0239df3c986%40djangoproject.com.