Re: [Django] #30516: Autoreloader crashes on re-raising exceptions with custom signature.

[Django]

#30516: Autoreloader crashes on re-raising exceptions with custom signature.
-+
 Reporter:  Alan Trick   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  autoreload   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by felixxm):

 * Attachment "30516.diff" added.

 Regression test.

-- 
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.4eaaf89e8eea46bd9a13c78d7ab55f5f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30516: Autoreloader crashes on re-raising exceptions with custom signature. (was: raise_last_exception doesn't work with exception types with different __init__ signatures)

[Django]

#30516: Autoreloader crashes on re-raising exceptions with custom signature.
-+
 Reporter:  Alan Trick   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  autoreload   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by felixxm):

 * severity:  Normal => Release blocker
 * cc: Tom Forbes (added)
 * component:  Uncategorized => Utilities
 * keywords:   => autoreload
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report.

 Regression in c8720e7696ca41f3262d5369365cc1bd72a216ca.
 Reproduced at df46b329e0900e9e4dc1d60816c1dce6dfc1094e.

-- 
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.c4eae9a3e0983a5954d985d7d30652cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30515: Document django.shortcuts.resolve_url. (was: Document django.shortcuts.resolve_url)

[Django]

#30515: Document django.shortcuts.resolve_url.
-+-
 Reporter:  sage |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Thanks for this ticket, however as you mentioned the way how `redirect()`
 resolves URLs is already described in documentation. I don't see many (if
 any) use cases for  `resolve_url()` (beyond the current), hence adding it
 to shortcuts can be confusing for users. IMO this should remain part of
 internal API.

-- 
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.4e847d5741f23a7d333cc259cf6e4cac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30517: refactor BaseMemcachedCache to be a base class for KV engines (was: Base class for Key Value engines for caching)

[Django]

#30517: refactor BaseMemcachedCache to be a base class for KV engines
-+-
 Reporter:  dulmandakh   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  redis| 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 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/068.a99022ee5df68c027f2a7cca4e39%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30517: Base class for Key Value engines for caching

[Django]

#30517: Base class for Key Value engines for caching
-+-
 Reporter:  dulmandakh   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  redis| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by dulmandakh:

Old description:

> I think that it would be best to have built-in support for Redis caching
> in Django, as it's getting more popular and has other use cases than just
> caching. And I found that most of the features overlap with memcached. So
> I think that it might be better to refactor BaseMemcachedCache to be base
> for KV engines, and use it for both Memcached and Redis, to reduce code
> duplication.
>
> I can work on this if approved.

New description:

 I think that it would be best to have built-in support for Redis caching
 in Django, as it's getting more popular and has other use cases than just
 caching. And I found that most of the features overlap with memcached. So
 I think that it might be better to refactor BaseMemcachedCache to be base
 for KV engines, and use it for both Memcached and Redis, to reduce code
 duplication.

 I would like to start discussion about best approach adding Redis support
 into Django. Also I can work on this if approved.

--

-- 
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/068.2dda7c79c2bdf73a9168200b3e6d6101%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30517: Base class for Key Value engines for caching

[Django]

#30517: Base class for Key Value engines for caching
-+-
 Reporter:  dulmandakh   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  redis| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by dulmandakh):

 * keywords:   => redis


-- 
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/068.36cb422450bb9e1f74fccdf231e4f802%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30517: Base class for Key Value engines for caching

[Django]

#30517: Base class for Key Value engines for caching
+
   Reporter:  dulmandakh|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Cache system)   |Version:  master
   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 |
+
 I think that it would be best to have built-in support for Redis caching
 in Django, as it's getting more popular and has other use cases than just
 caching. And I found that most of the features overlap with memcached. So
 I think that it might be better to refactor BaseMemcachedCache to be base
 for KV engines, and use it for both Memcached and Redis, to reduce code
 duplication.

 I can work on this if approved.

-- 
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/053.c42845fb54ab9f83d4a18c00f9fff61e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30516: raise_last_exception doesn't work with exception types with different __init__ signatures

[Django]

#30516: raise_last_exception doesn't work with exception types with different
__init__ signatures
---+--
 Reporter:  alantrick  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.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
---+--
Description changed by alantrick:

Old description:

> How to reproduce:
>
> In apps.py, put the following code, and update __init__.py or the
> settings to have this app config be used.
>
> {{{
> from django.apps import AppConfig
>
> class MyException(Exception):
> def __init__(self, value: str, other_thing: str):
> super().__init__(value)
> self.ot = other_thing
>
> class Config(AppConfig):
> name = "myapp"
> verbose_name = "My App"
>
> def ready(self):
> raise MyException("foo", "bar")
> }}}
>
> The problem is that `django.utils.autoreload.raise_last_exception` tries
> to construct a new exception of the same type, with 1 argument (the
> original exception). Note that this behavior was changed in
> c8720e7696ca41f3262d5369365cc1bd72a216ca, it used to just re-raise the
> exception value. I don't know why it was changed.
>
> I noticed this issue as a result of https://gitlab.com/alantrick/django-
> vox/issues/9

New description:

 How to reproduce:

 In apps.py, put the following code, and update __init__.py or the settings
 to have this app config be used.

 {{{
 from django.apps import AppConfig

 class MyException(Exception):
 def __init__(self, value: str, other_thing: str):
 super().__init__(value)
 self.ot = other_thing

 class Config(AppConfig):
 name = "myapp"
 verbose_name = "My App"

 def ready(self):
 raise MyException("foo", "bar")
 }}}

 The problem is that `django.utils.autoreload.raise_last_exception` tries
 to construct a new exception of the same type, with 1 argument (the
 original exception). The consequence is that you just get a TypeError
 exception about ` __init__() missing 1 required positional argument:
 'other_thing'` and it completely masks the original exception.

 Note that this behavior was changed in
 c8720e7696ca41f3262d5369365cc1bd72a216ca, it used to just re-raise the
 exception value. I don't know why it was changed.

 I noticed this issue as a result of https://gitlab.com/alantrick/django-
 vox/issues/9

--

-- 
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.8180ec8d5dea2a522c5f452c2c3afa0f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30516: raise_last_exception doesn't work with exception types with different __init__ signatures

[Django]

#30516: raise_last_exception doesn't work with exception types with different
__init__ signatures
-+
   Reporter:  alantrick  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.2
   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  |
-+
 How to reproduce:

 In apps.py, put the following code, and update __init__.py or the settings
 to have this app config be used.

 {{{
 from django.apps import AppConfig

 class MyException(Exception):
 def __init__(self, value: str, other_thing: str):
 super().__init__(value)
 self.ot = other_thing

 class Config(AppConfig):
 name = "myapp"
 verbose_name = "My App"

 def ready(self):
 raise MyException("foo", "bar")
 }}}

 The problem is that `django.utils.autoreload.raise_last_exception` tries
 to construct a new exception of the same type, with 1 argument (the
 original exception). Note that this behavior was changed in
 c8720e7696ca41f3262d5369365cc1bd72a216ca, it used to just re-raise the
 exception value. I don't know why it was changed.

 I noticed this issue as a result of https://gitlab.com/alantrick/django-
 vox/issues/9

-- 
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.fa6db57a3af06d36d83b28cf37dd170b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30515: Document django.shortcuts.resolve_url

[Django]

#30515: Document django.shortcuts.resolve_url
+
   Reporter:  sage  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 The documentation for django.shortcuts currently doesn't document
 `resolve_url`. However, the section for
 [https://docs.djangoproject.com/en/2.2/topics/http/shortcuts/#redirect
 redirect] pretty much explains how `resolve_url` works. It would be
 helpful to document `resolve_url` and state that `redirect` uses
 `resolve_url` in its process.

-- 
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.64ef2bf8321dd45761ce44e34d7d4cb1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30485: Unexpected behavior for django.utils.http.urlencode

[Django]

#30485: Unexpected behavior for django.utils.http.urlencode
-+-
 Reporter:  Johan Lübcke |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  2.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
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:"df46b329e0900e9e4dc1d60816c1dce6dfc1094e" df46b329]:
 {{{
 #!CommitTicketReference repository=""
 revision="df46b329e0900e9e4dc1d60816c1dce6dfc1094e"
 Refs #30485 -- Avoided unnecessary instance checks in urlencode.

 Given doseq defaults to False it should avoid an unnecessary instance
 check in most cases.
 }}}

-- 
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.f94493620cf7ac46bfff2f1fdd8de3c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30479: Autoreloader with StatReloader doesn't track changes in manage.py.

[Django]

#30479: Autoreloader with StatReloader doesn't track changes in manage.py.
-+--
 Reporter:  Keryn Knight |Owner:  Tom Forbes
 Type:  Bug  |   Status:  assigned
Component:  Utilities|  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  autoreload   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tom Forbes):

 Patch: https://github.com/django/django/pull/11422

-- 
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.c040ccaa6bf03fff8d69e7e45b6da480%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30479: Autoreloader with StatReloader doesn't track changes in manage.py.

[Django]

#30479: Autoreloader with StatReloader doesn't track changes in manage.py.
-+--
 Reporter:  Keryn Knight |Owner:  Tom Forbes
 Type:  Bug  |   Status:  assigned
Component:  Utilities|  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  autoreload   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Tom Forbes):

 * 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.5c35d4fe8eae97583cdd671ac15065f2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30505: Ordering of Field.choices is significant for makemigrations

[Django]

#30505: Ordering of Field.choices is significant for makemigrations
--+---
 Reporter:  Marnanel Thurman  |Owner:  Caio Ariede
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  master
 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
--+---
Changes (by Caio Ariede):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/11421 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 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.53400765c56ca324159c6d86c2848ca3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30507: Update admin's jQuery to 3.4.X.

[Django]

#30507: Update admin's jQuery to 3.4.X.
-+-
 Reporter:  felixxm  |Owner:
 Type:   |  dulmandakh
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Accepted => Ready for checkin


Comment:

 I'm going to merged this in September.

-- 
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.183c2b67d4b45a3cb58bfe4ca0a480a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29548: Add official support for MariaDB.

[Django]

#29548: Add official support for MariaDB.
-+-
 Reporter:  Tim Graham   |Owner:  felixxm
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 felixxm):

 * 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 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.530a3df1fe8b24229397d355d8e01e9c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29548: Add official support for MariaDB.

[Django]

#29548: Add official support for MariaDB.
-+-
 Reporter:  Tim Graham   |Owner:  felixxm
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 GitHub ):

 In [changeset:"b6c4766f53cf00bcf63cc2aa8be977c8589d083e" b6c4766]:
 {{{
 #!CommitTicketReference repository=""
 revision="b6c4766f53cf00bcf63cc2aa8be977c8589d083e"
 Refs #29548 -- Updated docs for MariaDB support.
 }}}

-- 
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.5521738424b35e2de16228d41b0b6272%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30505: Ordering of Field.choices is significant for makemigrations

[Django]

#30505: Ordering of Field.choices is significant for makemigrations
--+---
 Reporter:  Marnanel Thurman  |Owner:  Caio Ariede
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  master
 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 Caio Ariede):

 * status:  new => assigned
 * owner:  nobody => Caio Ariede


-- 
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.4310b4a307109b7b96009931e30b4f66%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30513: Impossible migration (with a change of model base) is not noticed.

[Django]

#30513: Impossible migration (with a change of model base) is not noticed.
---+--
 Reporter:  Victor Porton  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 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 felixxm):

 Yes, see
 [https://github.com/django/django/pull/11222#pullrequestreview-233821387
 comment].

-- 
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.b82a8b4ed5c332dfc5763044cb677796%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30513: Impossible migration (with a change of model base) is not noticed.

[Django]

#30513: Impossible migration (with a change of model base) is not noticed.
---+--
 Reporter:  Victor Porton  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 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 Victor Porton):

 Adding `migrations.AlterModelBases()` should be done automatically.

-- 
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.ef3bab280af28176b51c58c4fa5315c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23521: removal of concrete Model from bases doesn't remove it from ModelState bases

[Django]

#23521: removal of concrete Model from bases doesn't remove it from ModelState
bases
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Ian Foote
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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
-+-

Comment (by felixxm):

 Another use case of `migrations.AlterModelBases()` is described in #30513.

-- 
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/068.2728d3cd60688930180c2aa2a2074b46%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30513: Impossible migration (with a change of model base) is not noticed. (was: Impossible migration (with a change of model base) is not noticed)

[Django]

#30513: Impossible migration (with a change of model base) is not noticed.
---+--
 Reporter:  Victor Porton  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 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 felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => duplicate


Comment:

 Adding `migrations.AlterModelBases()` to a migration `operations` should
 solve this issue.

 Marking as a duplicate of #23521.

-- 
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.505b4f8f7ca54c9e147c7157812ed6e4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30514: Occasional CSRF cookie not set Django 2.1

[Django]

#30514: Occasional CSRF cookie not set Django 2.1
+
   Reporter:  Yusuf Musleh  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  CSRF  |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 |
+
 Hi all,

 We recently noticed an increase in the number of 403 errors we were
 getting in our server, mainly the `CSRF cookie not set.` We added more
 logging and investigated it to see if they were legitimate errors
 (requests that should cause a 403 error), some are, however we discovered
 that a lot of them aren't. There were normal requests coming from normal
 users, we would get around 30 of these failed requests in a given day, it
 would happen randomly across random devices, browsers and urls and has
 been quite difficult to reproduce.

 We Copy/Pasted the source code of `middleware.csrf` and added it to our
 code base as a custom middleware to add more logging and get a better
 traceback in sentry when the error occurs, to get more insights on issue,
 we learned the following:

 - For some reason the token was not set. `csrf_token =
 request.META.get('CSRF_COOKIE’)` returns `None`,
 - We know that if a user got the error, if they simply refresh the page
 things would work perfectly fine, this means that setting the token works,
 but sometimes it does not
 - We know that it is not a problem with our frontend since we also got
 this error in the django admin including non-login requests
 - We tried clearing all the expired sessions, and set `CSRF_USE_SESSIONS =
 True`, in hopes of it improving the situation, but nothing much has
 changed.

 With all that being said, we narrowed down the problem to the
 `_get_token(self, request)` method, since we set `CSRF_USE_SESSIONS =
 True` it tries to fetch the token from the session using
 `request.session.get(CSRF_SESSION_KEY)`, but that would return `None`. A
 very interesting thing we noticed is that the CSRF token **is** present in
 the actual request's header under `HTTP_X_CSRFTOKEN`. So we modified the
 method to fetch the CSRF token from the header as a fallback to see if it
 would fix the issue:

 {{{
 def _get_token(self, request):
 if settings.CSRF_USE_SESSIONS:
 try:
 token_from_session = request.session.get(CSRF_SESSION_KEY)
 except AttributeError:
 raise ImproperlyConfigured(
 'CSRF_USE_SESSIONS is enabled, but request.session is not
 '
 'set. SessionMiddleware must appear before
 CsrfViewMiddleware '
 'in MIDDLEWARE%s.' % ('_CLASSES' if settings.MIDDLEWARE is
 None else '')
 )
 else:
 try:
 cookie_token = request.COOKIES[settings.CSRF_COOKIE_NAME]
 except KeyError:
 return None

 csrf_token = _sanitize_token(cookie_token)
 if csrf_token != cookie_token:
 # Cookie token needed to be replaced;
 # the cookie needs to be reset.
 request.csrf_cookie_needs_reset = True
 return csrf_token

 # Fallback code we added to fetch the token from the header
 if token_from_session is None:
 token_from_session = request.META.get(settings.CSRF_HEADER_NAME)

 return token_from_session
 }}}

 Fortunately after this change was made, we haven't gotten any `CSRF cookie
 not set.` errors since then because the `_get_token` method now returns a
 token, and the `process_request` method goes smoothly:

 {{{
 def process_request(self, request):
 csrf_token = self._get_token(request)
 if csrf_token is not None:
 # Use same token next time.
 request.META['CSRF_COOKIE'] = csrf_token
 }}}

 the `request.META.get('CSRF_COOKIE’)` no longer returns `None`.

 We also tested sending bogus requests, ones with no csrf tokens set and
 ones with incorrect ones just to make sure that the CSRF functionality
 still works properly, and we get the `CSRF cookie not set.` and `CSRF
 token missing or incorrect.` respectively as expected.

 The question still remains, we're not sure why this bug happens. The
 problem is since django would consider these requests as bogus and handles
 them accordingly, we were not aware of the issue for a while. Until it
 randomly happened to a few people on our team, where they would open a
 fresh page on our website and click on a button that would make a request,
 and the error would occur, thats when we began the investigation.

 Could it be possible that due of the nature of this bug, it is occurring
 to others as well, but they are just not aware of it? I tried to 

Re: [Django] #30372: Django (moderately) High CPU usage at Idle

[Django]

#30372: Django (moderately) High CPU usage at Idle
-+-
 Reporter:  Benjamin Schollnick  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  2.2
 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 Tom Forbes):

 * cc: Tom Forbes (added)


Comment:

 Hey Benjamin,
 It seems some dependencies you have do not work with Django master. That's
 really annoying.

 I really hope the underlying issue is fixed in the new point release.
 Django 2.2.1 has been released, can you please test with that and let us
 know if it still has elevated CPU usage?

 We've also increased the quality and amount of logs that are produced with
 the autoreloader, if you could configure the `django.utils.autoreload`
 logger to be 'DEBUG' and attach the logs here it would be increadibly
 helpful in diagnosing this issue.

 Regarding the watchman memory usage, that may not be completely accurate
 representation of the total 'actual' memory being used. Regardless, for
 such a small project the CPU usage for a StatReloader should be very, very
 low.

-- 
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/069.fd08189a9bc68fe754bfdfd7168f27a9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30513: Impossible migration (with a change of model base) is not noticed

[Django]

#30513: Impossible migration (with a change of model base) is not noticed
---+--
 Reporter:  Victor Porton  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  Version:  2.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 Victor Porton):

 * Attachment "bug.tar.gz" added.

 The Git repository with stages of the bug appearance

-- 
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.4c21ff418b5e4da3253100b9c8229260%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30513: Impossible migration (with a change of model base) is not noticed

[Django]

#30513: Impossible migration (with a change of model base) is not noticed
-+
   Reporter:  Victor Porton  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Migrations |Version:  2.2
   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  |
-+
 1. Extract the attached Git repository. (It contains among other
 migrations automatically created with `makemigrations`, one of the
 migrations was made with choosing the option `2) Ignore for now, and let
 me handle existing rows with NULL myself (e.g. because you added a
 RunPython or RunSQL operation to handle NULL values in a previous data
 migration)`.)

 2. Try to migrate.

 You see the error:

 {{{
 django.db.utils.OperationalError: foreign key mismatch - "mytest_project"
 referencing "mytest_token"
 }}}

 The Django bug is that this error is noticed too late: on the stage of
 `migrate` not where it should have been noticed, the stage of
 `makemigrations`.

 The bug appears when I try to replace (in two stages as described by tags
 below, because Django does not allow to do it in one stage):
 {{{
 class Token(models.Model):
  pass
 }}}

 with

 {{{
 class BaseToken(models.Model):
 pass


 class Token(BaseToken):
 base = models.OneToOneField(BaseToken, on_delete=models.CASCADE,
 primary_key=True)
 }}}

 This happens because this change unnoticed by Django replaces what is used
 as the primary key for `Token`.

 Note that sequential stages of change in the Git repository are marked by
 tags `before-change`, `change-middle`, `after-change`.

-- 
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/050.186c4fcce5f5ae1196361e6af1dbc589%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30355: Specifying custom manager doesn't work with prefetch

[Django]

#30355: Specifying custom manager doesn't work with prefetch
-+-
 Reporter:  Kyle Mulka   |Owner:  robinh00d
 Type:  Bug  |   Status:  assigned
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
-+-
Changes (by robinh00d):

 * owner:  nobody => robinh00d
 * 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 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.43457662c607adb8ecd23b95ef083680%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30511: AutoField with postgres10/11 as generated identity.

[Django]

#30511: AutoField with postgres10/11 as generated identity.
-+-
 Reporter:  Michael Kany |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres generated   | Triage Stage:
  identity   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Michael Kany):

 I agree that there is not much value in replacing serial with GENERATED AS
 IDENTITY.

 What I suggest is to add extra fields related to GENERATED AS IDENTITY to
 the PostgreSQL backends as an alternative option to SERIAL since it is an
 option in PostgreSQL and it is actually SQL-standard compliant compared to
 SERIAL.

 Since PostgreSQL 10 there is the option to use GENERATED AS IDENTITY, I
 would like to suggest to make Django compatible with this feature by
 adding two extra AutoField-like fields.

 •   IdentityAutoField with inner workings like AutoField with SERIAL
 but with GENERATED AS IDENTITY
 •   IdentityBigAutoField with inner workings like BigAutoField with
 SERIAL but with GENERATED AS IDENTITY

 These fields would probably be interesting only for Postgres user.

-- 
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/068.04986717e5dc3bcf1290212b2269ce19%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24944: Have password_reset pass extra_context to the email template rendering as well

[Django]

#24944: Have password_reset pass extra_context to the email template rendering 
as
well
--+-
 Reporter:  twelveeighty  |Owner:  Sujay S Kumar
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  1.8
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+-

Comment (by Mariusz Felisiak ):

 In [changeset:"aff61790a326f214f5ea608bac8298c3a8716b1b" aff61790]:
 {{{
 #!CommitTicketReference repository=""
 revision="aff61790a326f214f5ea608bac8298c3a8716b1b"
 Refs #24944 -- Added test for overriding domain in email context in
 PasswordResetView.
 }}}

-- 
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.9b08533edfdb4e1b65fe7a64aa81e770%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30499: PasswordResetView should be allowed to set `domain_override`. (was: PasswordResetView should be allowed to set `domain_override`)

[Django]

#30499: PasswordResetView should be allowed to set `domain_override`.
-+-
 Reporter:  Mattia Procopio  |Owner:  Mattia
 |  Procopio
 Type:  New feature  |   Status:  closed
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:  invalid
 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 felixxm):

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


Comment:

 Mattia, Thanks for your work and sorry, but `domain` can be override
 easily with the current implementation, e.g.
 {{{
 views.PasswordResetView.as_view(extra_email_context={'domain':
 'custom.example.com'}).
 }}}

 I think that providing an extra `kwargs` for that is pointless.

-- 
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/069.f1e3bd4c2e9c5922001c35c6c8011b83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30490: migrations unique_index on (app, name).

[Django]

#30490: migrations unique_index on (app, name).
-+-
 Reporter:  Richard  |Owner:  nobody
  Kojedzinszky   |
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  migrations parallel  | Triage Stage:
  run|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tom Forbes):

 The way we solved this with Kubernetes is to create and launch a Job which
 will run manage.py migrate as part of the deployment pipeline. Once that
 Job is complete, update the Deployment/ReplicaSet as needed.

 As always you have to be completely sure the migration can run
 concurrently with your app, but in genera running migrations as an initpod
 or as part of the web app pod is really not advised, and adding a hack
 like a distributed lock will only bring you pain.

-- 
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/071.63ee7e4d8d49f87057b80d37d28ac5c5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30315: StringAgg with ordering in subquery generates invalid string_agg() SQL function call

[Django]

#30315: StringAgg with ordering in subquery generates invalid string_agg() SQL
function call
--+---
 Reporter:  Reupen Shah   |Owner:  Caio Ariede
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  master
 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 felixxm):

 * severity:  Normal => Release blocker


Comment:

 Bumped to the `release blocker` since it is a bug in a 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 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/064.3eb68b194db36de9df841e5105eb5648%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30490: migrations unique_index on (app, name).

[Django]

#30490: migrations unique_index on (app, name).
-+-
 Reporter:  Richard  |Owner:  nobody
  Kojedzinszky   |
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  migrations parallel  | Triage Stage:
  run|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * cc: Adam (Chainz) Johnson (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 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/071.41e38bd8e68e095cde4013328f410c68%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30490: migrations unique_index on (app, name).

[Django]

#30490: migrations unique_index on (app, name).
-+-
 Reporter:  Richard  |Owner:  nobody
  Kojedzinszky   |
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  migrations parallel  | Triage Stage:
  run|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Adam (Chainz) Johnson):

 You don't need to use Redis for distributed locking, you can use advisory
 locking in your database server. They can live outside of transactions.

 In PostgreSQL they are called advisory locks -
 https://hashrocket.com/blog/posts/advisory-locks-in-postgres . They are by
 an integer key.

 In MySQL/MariaDB they are called user locks -
 https://mariadb.com/kb/en/library/get_lock/  . They are by a string key.

 I don't know about SQLite or Oracle. Quick internet searches don't reveal
 anything

 Potentially Django could use these advisory locks.

-- 
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/071.94432595c96d26a6cc57641a68d1a72f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30511: AutoField with postgres10/11 as generated identity. (was: AutoField with postgres10/11 as generated identity)

[Django]

#30511: AutoField with postgres10/11 as generated identity.
-+-
 Reporter:  Michael Kany |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres generated   | Triage Stage:
  identity   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * version:  2.2 => master


Old description:

> We are currently working on a Django / Postgresql 11 project. We needed
> an adjustment for the postgres module because of its compatibility with
> .NET Framework and dataset generation.
> In postgres 10/11 there is the new feature identity column called
> GENERATED AS IDENTITY instead of serial.
> column_name type GENERATED {ALWAYS | BY DEFAULT} AS IDENTITY
> [(sequence_option)]
> We have created a module based on db.backends.postgres that adds 2 new
> django model fields. I would like implement the new feature into pyodbc
> module or new module for postgres 10/11 useful for later versions of
> django.
>
> Adjustments only in base.py (line 70ff):
> data_types = {
> 'IdentityAutoField': 'integer',
> 'IdentityBigAutoField': 'bigint',
>
> and schema.py, def column_sql () (line 178ff):
> # Primary key / unique outputs
> if field.primary_key:
> sql + = "PRIMARY KEY"
> if field.get_internal_type () in ("IdentityAutoField",
> "IdentityBigAutoField"):
> sql + = "GENERATED ALWAYS AS IDENTITY"
> elif field.unique:
> sql + = "UNIQUE"
>
> I can also send our code
>
> best regards
> Michael Kany

New description:

 We are currently working on a Django / Postgresql 11 project. We needed an
 adjustment for the postgres module because of its compatibility with .NET
 Framework and dataset generation.
 In postgres 10/11 there is the new feature identity column called
 GENERATED AS IDENTITY instead of serial.
 column_name type GENERATED {ALWAYS | BY DEFAULT} AS IDENTITY
 [(sequence_option)]
 We have created a module based on db.backends.postgres that adds 2 new
 django model fields. I would like implement the new feature into pyodbc
 module or new module for postgres 10/11 useful for later versions of
 django.

 Adjustments only in base.py (line 70ff):
 {{{
 data_types = {
 'IdentityAutoField': 'integer',
 'IdentityBigAutoField': 'bigint',
 }}}
 and schema.py, def column_sql () (line 178ff):
 {{{
 # Primary key / unique outputs
 if field.primary_key:
 sql + = "PRIMARY KEY"
 if field.get_internal_type () in ("IdentityAutoField",
 "IdentityBigAutoField"):
 sql + = "GENERATED ALWAYS AS IDENTITY"
 elif field.unique:
 sql + = "UNIQUE"
 }}}
 I can also send our code

 best regards
 Michael Kany

--

Comment:

 Thanks for the report. Can you provide more details about your use case?
 Can you also clarify what are you proposing? e.g.
 - using `GENERATED AS IDENTITY` instead of `serial` on PostgreSQL (I don't
 see much value in this),
 - adding extra fields to the PostgreSQL backends.

 In Oracle we used `GENERATED AS IDENTITY` because there is no other way to
 create `serial`-like columns on Oracle which is not the case on
 PostgreSQL.

-- 
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/068.ea4f352abbe31e9b260855435c394b77%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30475: Use of i18n_patterns and a buggy 404 template trigger internal server error without a backtrace. (was: Use of i18n_patterns and a buggy 404 template trigger internal server error

[Django]

#30475: Use of i18n_patterns and a buggy 404 template trigger internal server 
error
without a backtrace.
-+--
 Reporter:  Erik Stein   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  master
 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 felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => invalid


Comment:

 Thanks for the sample project. IMO everything works properly. In `DEBUG`
 mode Django doesn't use your custom `404.html` page that's why it also
 doesn't propagate any errors in this page (you've already described this
 as a correct behavior). When `DEBUG=False` Django handles exception by
 [https://docs.djangoproject.com/en/stable/ref/urls/#handler500 handler500]
 view and logges them in
 [https://docs.djangoproject.com/en/stable/topics/logging/#django-request-
 logger django.request] logger. If you want to skip this and propagate
 exceptions upwards when `DEBUG=False` you can use
 [https://docs.djangoproject.com/en/2.2/ref/settings/#debug-propagate-
 exceptions DEBUG_PROPAGATE_EXCEPTIONS] setting.

-- 
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.bd283559ac66423d3012d176ce453b36%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.