Re: [Django] #30017: Django should assume port 443 for https in django.utils.http.is_same_domain()

[Django]

#30017: Django should assume port 443 for https in
django.utils.http.is_same_domain()
---+--
 Reporter:  Ruslan Dautkhanov  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  2.1
 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
---+--

Comment (by Ruslan Dautkhanov):

 Related to https://code.djangoproject.com/ticket/26037

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.827641a6bff38295daea56a4ed13c946%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27867: Excluding a reverse relation produces inconsistent queries

[Django]

#27867: Excluding a reverse relation produces inconsistent queries
-+-
 Reporter:  Sébastien Diemer |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 Simon Charette):

 I investigated this is a bit and the first non deterministic issue
 happened to have been fixed as a side effect
 b95c49c954e3b75678bb258e9fb2ec30d0d960bb.

 The second issue still stands though but not
 
[https://github.com/sebdiem/django/commit/e8ca265e8c30f61c88ea17b7c1cab72695d6a4ff
 as reported in the test case provided] anymore because
 b95c49c954e3b75678bb258e9fb2ec30d0d960bb made `.exclude(name='',
 note__isnull=True)` kwargs passed to `Q` always sorted as `[('name', ''),
 ('note__isnull', True)]` which takes the code path where `U0."id" =
 ("queries_tag"."id")` is added to the `WHERE` clause.

 In order to bypass the kwargs ordering added in
 b95c49c954e3b75678bb258e9fb2ec30d0d960bb that hides this issue as reported
 because `'name' < 'note'` one can rely on `Q` args instead

 1. `exclude(Q(note__isnull=True) & Q(name=''))` exhibits the issue.
 2. `exclude(Q(name='') & Q(note__isnull=True))` doesn't as it's equivalent
 to what `exclude(name='', note__isnull=True)` translates to.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a9055ef7263abf176a141dc56ace4c59%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30023: SQLite schema editor can cause table corruption if used within a transaction since Django 2.0

[Django]

#30023: SQLite schema editor can cause table corruption if used within a
transaction since Django 2.0
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  2.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Simon Charette:

Old description:

> From Django 2.0+ SQLite schema editor requires foreign key constraint
> checking to be disabled before performing any operations to make sure
> foreign keys are not left pointing at `__old` tables when performing
> operations requiring table rebuilds.
>
> Since [https://sqlite.org/foreignkeys.html#fk_enable SQLite prevents
> foreign key constraint checking from being disabled within a transaction]
> `SchemaEditor(atomic=True).__enter__()` has no choice but to disable
> foreign key constraints **before** opening the transaction meant to
> ensure atomic DDL operations.
>
> One edge case that `SchemaEditor` doesn't account for though is that the
> it might contextually be used within an already opened transaction that
> would prevent foreign key constraints from being effectively disabled and
> result in silent referent table corruption when an operation requiring a
> table is rebuild id performed.
>
> In order to prevent this from happening `SchemaEditor().__enter__()`
> should ensure foreign key constraint checks are effectively disabled
> after requesting it and error out if it's not the case.
>
> This assertion should be more adequate than preventing schema editor from
> being used in a transaction altogether as disabling constraint checks
> before opening a transaction works just fine as well.
>
> For example
>
> {{{#!python
> with transaction.atomic():
> call_command('migrate')
> }}}
>
> Just has to be converted to
>
> {{{#!python
> with connection.constraint_checks_disabled(), transaction.atomic():
> call_command('migrate')
> }}}
>
> And work just fine.
>
> ''This is was originally reported in #29182 but was hijacked to deal with
> a SQLite 3.26 issue with similar symptoms and can be reproduced in a
> [https://github.com/ezaquarii/django-sqlite-migration-bug test project].

New description:

 From Django 2.0+ SQLite schema editor requires foreign key constraint
 checking to be disabled to make sure foreign keys are not left pointing at
 `__old` tables when performing operations requiring table rebuilds.

 Since [https://sqlite.org/foreignkeys.html#fk_enable SQLite prevents
 foreign key constraint checking from being disabled within a transaction]
 `SchemaEditor(atomic=True).__enter__()` has no choice but to disable
 foreign key constraints **before** opening the transaction meant to ensure
 atomic DDL operations.

 One edge case that `SchemaEditor` doesn't account for though is that the
 it might contextually be used within an already opened transaction that
 would prevent foreign key constraints from being effectively disabled and
 result in silent referent table corruption when an operation requiring a
 table is rebuild id performed.

 In order to prevent this from happening `SchemaEditor().__enter__()`
 should ensure foreign key constraint checks are effectively disabled after
 requesting it and error out if it's not the case.

 This assertion should be more adequate than preventing schema editor from
 being used in a transaction altogether as disabling constraint checks
 before opening a transaction works just fine as well.

 For example

 {{{#!python
 with transaction.atomic():
 call_command('migrate')
 }}}

 Just has to be converted to

 {{{#!python
 with connection.constraint_checks_disabled(), transaction.atomic():
 call_command('migrate')
 }}}

 And work just fine.

 ''This is was originally reported in #29182 but was hijacked to deal with
 a SQLite 3.26 issue with similar symptoms and can be reproduced in a
 [https://github.com/ezaquarii/django-sqlite-migration-bug test project].

--

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion 

Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

[Django]

#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Migrations|  Version:  2.0
 Severity:  Release blocker   |   Resolution:  fixed
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham):

 The original issue reported in this ticket will be addressed in #30023.
 The ticket was repurposed incorrectly for a different issue.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.7ec21b896024cb98d9bb1a67ee5f972b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28905: Overhaul extra_requires to include more optional dependencies

[Django]

#28905: Overhaul extra_requires to include more optional dependencies
-+-
 Reporter:  Jaap Roes|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Packaging|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  setup optional   | Triage Stage:  Accepted
  dependencies packages  |
  requirements   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Nick Pope):

 Thanks for the feedback, please see responses below.

 > ... It would be nice if the overview of optional dependencies could link
 to the relevant sections in the docs. E.g. caching, databases, GIS,
 password hashers, template engines, serializers etc.
 Agreed. Will add in links to useful sections in the documentation.

 > ... For this reason I think it's probably not the right choice to name
 groups directly after the package they are installing (`pylibmc`,
 `pyinotify`, `selenium` etc.).
 >
 > Maybe it would be easier to just start out with just adding the database
 extra's? ...
 I still feel that adding support for some of the packages other than
 database backends would be very useful. There should at the very least be
 an easy option to install all non-database backend packages, particularly
 useful for removing `tests/requirements/*.txt`.

 > It might also be interesting to figure out how to "deprecate" extra
 requirement groups, so at some point it would be possible to phase out the
 `bcrypt` or `argon2` extra requirements.
 I'm not sure it is possible to "deprecate" - in fact it doesn't really
 make sense - a package must be available during a deprecation period.
 However, when the package is removed, the group must either remain empty
 in `extra_requires` or be removed entirely if documented in the release
 notes.

 > I was also thinking, extra requirements would also be a nice place to
 include other "official" Django projects. E.g. `pip install
 django[mysql,localflavor,comments]` or `pip install
 django[postgresql,channels]`.
 I think it best to leave these out of the `extra_requires` option, but
 perhaps document them on the optional dependencies page along with a link
 to other [https://pypi.org/search/?q===Framework+%3A%3A+Django django-
 related projects].

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.c56eaad6b56681c2dabaa809df511ec7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30023: SQLite schema editor can cause table corruption if used within a transaction since Django 2.0 (was: SQLite schema editor can cause table corruption if unsed within a transaction s

[Django]

#30023: SQLite schema editor can cause table corruption if used within a
transaction since Django 2.0
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  2.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.03bf62c0ed67b02f1e19fb05797038cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30023: SQLite schema editor can cause table corruption if unsed within a transaction since Django 2.0

[Django]

#30023: SQLite schema editor can cause table corruption if unsed within a
transaction since Django 2.0
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  2.0
 Severity:  Release blocker  |   Resolution:
 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 Simon Charette):

 * has_patch:  0 => 1


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2bd1bf2d7fa4c620315e98144ba6e53c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30023: SQLite schema editor can cause table corruption if unsed within a transaction since Django 2.0

[Django]

#30023: SQLite schema editor can cause table corruption if unsed within a
transaction since Django 2.0
-+-
   Reporter:  Simon  |  Owner:  Simon Charette
  Charette   |
   Type:  Bug| Status:  assigned
  Component: |Version:  2.0
  Migrations |
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 From Django 2.0+ SQLite schema editor requires foreign key constraint
 checking to be disabled before performing any operations to make sure
 foreign keys are not left pointing at `__old` tables when performing
 operations requiring table rebuilds.

 Since [https://sqlite.org/foreignkeys.html#fk_enable SQLite prevents
 foreign key constraint checking from being disabled within a transaction]
 `SchemaEditor(atomic=True).__enter__()` has no choice but to disable
 foreign key constraints **before** opening the transaction meant to ensure
 atomic DDL operations.

 One edge case that `SchemaEditor` doesn't account for though is that the
 it might contextually be used within an already opened transaction that
 would prevent foreign key constraints from being effectively disabled and
 result in silent referent table corruption when an operation requiring a
 table is rebuild id performed.

 In order to prevent this from happening `SchemaEditor().__enter__()`
 should ensure foreign key constraint checks are effectively disabled after
 requesting it and error out if it's not the case.

 This assertion should be more adequate than preventing schema editor from
 being used in a transaction altogether as disabling constraint checks
 before opening a transaction works just fine as well.

 For example

 {{{#!python
 with transaction.atomic():
 call_command('migrate')
 }}}

 Just has to be converted to

 {{{#!python
 with connection.constraint_checks_disabled(), transaction.atomic():
 call_command('migrate')
 }}}

 And work just fine.

 ''This is was originally reported in #29182 but was hijacked to deal with
 a SQLite 3.26 issue with similar symptoms and can be reproduced in a
 [https://github.com/ezaquarii/django-sqlite-migration-bug test project].

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.760e573a389b25011818dd0fc2b522c3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28110: Model inheritance field name collision check error refers to related accessors as fields

[Django]

#28110: Model inheritance field name collision check error refers to related
accessors as fields
--+
 Reporter:  Matthew Schinckel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (System checks)  |  Version:  1.11
 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 Paul Kenjora):

 This ticket breaks abstraction, user defined fields now clash with
 framework defined fields.  In addition the framework fields are inferred
 not explicit, giving the user no reasonable way to know ahead of time what
 the conflict may be, especially for 3rd party models that may end up
 clashing.  Can we raise the severity of this since it forces a significant
 project rewrite ( rename all clashing fields ) from version 1.8 to 1.9+?

 I'll continue investigating, for the curious the clash is caught at:

 /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-
 packages/django/db/models/base.py" [readonly] line 1453

 Search for E006 in file.  Looks like there is already an exception for id
 clash, do we add one for inherited models?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.7d970f1181d0ab5ff799f9e5914e6c5b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30022: Doc how to combine post_save signal with on_commit to alter a m2m relation when saving a model instance

[Django]

#30022: Doc how to combine post_save signal with on_commit to alter a m2m 
relation
when saving a model instance
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  wontfix
 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 Simon Charette):

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


Comment:

 Thank you for the suggestion but it feels like a pretty specific example
 to document as this is not something you want to do in all cases.

 If I understand where you are coming from you want to make sure changes
 performed in `save()` are committed to the database in the same
 transaction as the m2m alterations.

 In your "group" case your suggested approach will work fine in cases where
 `save()` in not called in within a `transaction.atomic()` block will have
 surprising results if this doesn't hold true.

 For example in

 {{{#!python
 @transaction.atomic
 def accept_group_invite(request, group_id):
 validate_and_add_to_group(request.user, group_id)
 # The below line would always fail in your case because the on_commit
 # receiver wouldn't be called until exiting this function.
 if request.user.has_perm('group_permission'):
 do_something()
 ...
 }}}

 `do_something()` would never be called because
 `validate_and_add_to_group()`'s `save()` calls that would trigger the
 `post_save` receiver would only queue the group additions to be performed
 `on_commit` which wouldn't happen until the `accept_group_invite` function
 exits.

 If you want to make sure both `save()` and its `pre_save` and `post_save`
 side effects are performed in as an atomic operation (either succeed or
 fail) then you should simply wrap your `save()` calls in an `atomic`
 block.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.849b85001adf0983d0dadfef099d4042%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30021: Allow contrib.sites to use the request host and fallback to a SITE_ID (was: Feature request to allow "mixed mode" Sites operation.)

[Django]

#30021: Allow contrib.sites to use the request host and fallback to a SITE_ID
---+-
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Someday/Maybe
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Tim Graham):

 * needs_docs:  1 => 0
 * stage:  Unreviewed => Someday/Maybe
 * easy:  1 => 0


Old description:

> We all learn very early in playing with django to set a site and a
> SITE_ID.  Once we operate as multiple sites, we either use the multiple
> processes, each configured with a separate SITE_ID or we can now pass a
> request in.  However,  I assume for backward compatibility, SITE_ID must
> be removed.  This allows all sites which specify SITE_ID to operate as if
> the addition of passing request was not added.  However, removing SITE_ID
> to allow get_site_by_request breaks all applications which do NOT pass
> request, because there is no SITE_ID.
>
> I propose a setting, which, when set to True in addition to setting
> SITE_ID, causes request to take precedence over SITE_ID.  This will allow
> applications using both paradigms to coexist without modification - sites
> which pass request use get_site_by_request as if SITE_ID had not been
> defined and calls passing no request get SITE_ID.  When the new setting
> is not present, all behavior is backward compatible.
>
> Essentially, I am proposing something like the 'change set' I typed in
> below - I considered that a complex and/or in the fist if could cover all
> of the conditions, but I think qualifying the first line with the new
> setting and adding the elif to cover the cleanup case of not set to True
> is easier to understand - especially in light of understanding the the
> backward compatibility aspect of the change.  The version of this change
> I am currently running simply defines a new SITE_DEFAULT_ID to catch the
> third case, but it occurred to me that some modules may expect SITE_ID
> directly for some reason, and MIXED_MODE has them covered too.
>
> I expect the documentation change to accompany the new setting would go
> with the Sites documentation next to SITE_ID an explanation of removing
> SITE_ID to use request.
>
> This would be my first contribution, so I am unsure that it would
> welcome.  If this ticket is accepted, I will quite gladly prepare a pull
> request with an agreed upon setting name (in case mine doesn't grab ya)
> or other any other suggested style improvements etc.
>
> Thank you for taking the time to review my request.
>
> All the best, and thank you for your work with django.
>
> Manually edited 'change set' describing the proposed change (three lines)
> follow:
>
> django/contrib/sites/models.py
>
> def get_current(self, request=None):
> """
> Return the current Site based on the SITE_ID in the project's
> settings.
> If SITE_ID isn't defined, return the site with domain matching
> request.get_host(). The ``Site`` object is cached the first time
> it's
> retrieved from the database.
> """
> from django.conf import settings
> ++ site_id = getattr(settings, 'SITE_ID', '')
> ++ mixed = getattr(settings, 'SITE_MIXED_MODE', '')
> --if getattr(settings, 'SITE_ID', ''):
> ++ if site_id and not mixed:
> --  site_id = settings.SITE_ID
> return self._get_site_by_id(site_id)
> elif request:
>  return self._get_site_by_request(request)
> ++   elif site_id and mixed == True:
> ++ return self._get_site_by_id(site_id)
>
> raise ImproperlyConfigured(
> "You're using the Django \"sites framework\" without having "
> "set the SITE_ID setting. Create a site in your database and
> "
> "set the SITE_ID setting or pass a request to "
> "Site.objects.get_current() to fix this error."
> )

New description:

 We all learn very early in playing with django to set a site and a
 SITE_ID.  Once we operate as multiple sites, we either use the multiple
 processes, each configured with a separate SITE_ID or we can now pass a
 request in.  However,  I assume for backward compatibility, SITE_ID must
 be removed.  This allows all sites which specify SITE_ID to operate as if
 the addition of passing request was not added.  However, removing SITE_ID
 to allow get_site_by_request breaks all applications which do NOT pass
 request, because there is no SITE_ID.

 I propose a setting, which, when set to True 

Re: [Django] #30019: Add __class_getitem__ method to managers and querysets

[Django]

#30019: Add __class_getitem__ method to managers and querysets
-+-
 Reporter:  Maxim Kurnikov   |Owner:  Greg
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Maxim Kurnikov):

 {{{TypeError: 'type' object is not subscriptable}}}

 Look at
 https://www.python.org/dev/peps/pep-0560/#class-getitem

 and how it was implemented before with {{{GenericMeta}}}
 https://www.python.org/dev/peps/pep-0484/#user-defined-generic-types

 Minimal repro should be this one
 {{{
 from django.db import models

 class UserManager(models.Manager['User']):
 pass

 class User(models.Model):
 objects = UserManager()
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.de7060d981d69d8683d7eab51414521d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30022: Doc how to combine post_save signal with on_commit to alter a m2m relation when saving a model instance

[Django]

#30022: Doc how to combine post_save signal with on_commit to alter a m2m 
relation
when saving a model instance
+
   Reporter:  George Tantiras   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  2.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Trying to alter a many to many relation when saving a model's instance is
 a common use case.

 [https://stackoverflow.com/a/53608043/2996101 For example], when creating
 a new user or altering an already existing user, programmatically add or
 remove groups he should(n't) belong to.

 This can be achieved by catching a post save signal and creating a
 decorator that uses
 
[https://docs.djangoproject.com/en/dev/topics/db/transactions/#django.db.transaction.on_commit
 on_commit]:



 {{{

 def on_transaction_commit(func):
 ''' Create the decorator '''
 def inner(*args, **kwargs):
 transaction.on_commit(lambda: func(*args, **kwargs))

 return inner


 @receiver(
 post_save,
 sender=settings.AUTH_USER_MODEL,
 )
 @on_transaction_commit
 def group_delegation(instance, raw, **kwargs):
 do stuff()
 }}}


 Is it relevant to doc it as an example in the
 
[https://docs.djangoproject.com/en/dev/ref/signals/#django.db.models.signals.post_save
 post_save] signal chapter?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.bb1d8fbf7be8ac4c55ae644fed38ee66%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30018: Regression for selenium tests & inaccurate Content-Length

[Django]

#30018: Regression for selenium tests & inaccurate Content-Length
--+--
 Reporter:  Xavier Fernandez  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  HTTP handling |  Version:  2.1
 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
--+--

Comment (by Florian Apolloner):

 I think this behavior is to be expected with keep-alive support. What we
 could do (if it is easy to implement) is to close the connection if we
 detect such a situation (Literally close the socket, not just a
 "Connection: close" header, because the client would still wait for the
 bytes to come).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.daade9682822bc2af0581c84f5b10239%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.