Re: [Django] #27685: Allow autoreloader to use watchman

[Django]

#27685: Allow autoreloader to use watchman
-+-
 Reporter:  Aymeric Augustin |Owner:  Tom
 Type:   |  Forbes
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  Version:  master
 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:"43f54e136e9282f5c0bfcf1169d0d59b3c365add" 43f54e1]:
 {{{
 #!CommitTicketReference repository=""
 revision="43f54e136e9282f5c0bfcf1169d0d59b3c365add"
 Refs #27685 -- Logged unexpected Watchman autoreloader errors.
 }}}

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

Re: [Django] #30477: Filtering on reverse ForeignKey relation uses get_db_prep_value from a wrong field.

[Django]

#30477: Filtering on reverse ForeignKey relation uses get_db_prep_value from a
wrong field.
-+-
 Reporter:  Michal Petrucha  |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 Michal Petrucha):

 FWIW, the way I discovered this was with a UUID primary key with a
 Postgres backend, which might not be ''that'' unusual, but in Django 1.11.
 However, I had to reproduce it with a different field on master, because
 `UUIDField.to_python` has become a bit less strict since 1.11, and it
 doesn't error out on integers anymore.

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

Re: [Django] #30476: Add introspection of "json" (like "jsonb") data type as JSONField on PostgreSQL. (was: Add detection for PostgreSQL json field, aside from the already existing detection for jsonb

[Django]

#30476: Add introspection of "json" (like "jsonb") data type as JSONField on
PostgreSQL.
-+-
 Reporter:  Héctor Pablos|Owner:  (none)
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  inspectdb,   | Triage Stage:
  JSONField, json, jsonb |  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:   => wontfix


Comment:

 Thanks for the report, however "json" data type would not be fully
 functional (especially in querying and indexing).

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

Re: [Django] #30476: Add detection for PostgreSQL json field, aside from the already existing detection for jsonb field, using inspectdb

[Django]

#30476: Add detection for PostgreSQL json field, aside from the already existing
detection for jsonb field, using inspectdb
-+-
 Reporter:  Héctor Pablos|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  contrib.postgres |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  inspectdb,   | Triage Stage:
  JSONField, json, jsonb |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 There's enough significant differences between `json` and `jsonb` types
 which makes me believe this is not a good idea.

 For example, [https://www.postgresql.org/docs/9.4/datatype-json.html
 containment operators it not supported] on `json` columns while they are
 on `jsonb` ones which breaks the `__contains`
 [https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/fields/#std
 :fieldlookup-hstorefield.contains operator].

-- 
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.f24186139708728077fbbfd690a026c4%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

[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:  new
Component:  Core (URLs)  |  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
-+--

Comment (by Claude Paroz):

 Probably setting up a minimal project to reproduce the issue would be
 great.

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

Re: [Django] #30477: Filtering on reverse ForeignKey relation uses get_db_prep_value from a wrong field. (was: Filtering on reverse ForeignKey relation uses get_db_prep_value from a wrong field)

[Django]

#30477: Filtering on reverse ForeignKey relation uses get_db_prep_value from a
wrong field.
-+-
 Reporter:  Michal Petrucha  |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
-+-
Changes (by felixxm):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks for this report. I was able to reproduce this issue on all backends
 except PostgreSQL. It looks that using foreign keys to models with custom
 primary keys that require preparing DB value is not a common use case.

 Reproduced at 7619a33665ccc138c1583a2cce5a5de6d86c9cb4.

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

Re: [Django] #14365: Make template-rendering signals available also in DEBUG mode

[Django]

#14365: Make template-rendering signals available also in DEBUG mode
---+--
 Reporter:  Carl Meyer |Owner:  Carl Meyer
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   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 felixxm):

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


Comment:

 7 years of silence doesn't mean that this ticket is not valid anymore
 (e.g. few days ago we closed 11 years old ticket). Ticket is targeted to
 master.

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

Re: [Django] #14365: Make template-rendering signals available also in DEBUG mode

[Django]

#14365: Make template-rendering signals available also in DEBUG mode
---+--
 Reporter:  Carl Meyer |Owner:  Carl Meyer
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 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 maribedran):

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


Comment:

 The issue was opened 9 years ago and never revisited after the author
 realized the patch needed more work. It's flagged with the 1.2 version
 which is not supported anymore.

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

Re: [Django] #30422: Temporary files do not get deleted on canceled upload request.

[Django]

#30422: Temporary files do not get deleted on canceled upload request.
-+-
 Reporter:  drutalj  |Owner:  Mattia
 |  Procopio
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  master
  uploads/storage|
 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 Mattia Procopio):

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

Re: [Django] #26368: Order of &-ing Q objects affects results in edge case

[Django]

#26368: Order of &-ing Q objects affects results in edge case
-+-
 Reporter:  Floris den Hengst|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Query Q order| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * cc: Can Sarıgöl (added)


Comment:

 Hi, I'm working on this issue. to fix it and understand deeply. as far as
 I understand:), the problem is
 
[https://github.com/django/django/blob/8aad3321ed6f0b603361767a4fe00d046b5fdd34/django/utils/tree.py#L113
 here]. When we add a {{{combine}}} q node and this q contains
 {{{negated=True}}} clauses, this {{{~Q}}}s are associated with other
 {{{Q}}}. I couldn't find why but if I change the code like this:
 {{{self.children.insert(0, data)}}}, I can see the query is 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/061.478f53a114081cbd887053f184be33ed%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30477: Filtering on reverse ForeignKey relation uses get_db_prep_value from a wrong field

[Django]

#30477: Filtering on reverse ForeignKey relation uses get_db_prep_value from a
wrong field
-+-
   Reporter:  Michal |  Owner:  nobody
  Petrucha   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  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  |
-+-
 Let's start off with a minimal test case.
 {{{
 from django.db import models


 class Local(models.Model):
 id = models.DateTimeField(primary_key=True, auto_now_add=True)


 class Remote(models.Model):
 fk = models.ForeignKey(Local, on_delete=models.CASCADE)
 }}}
 and
 {{{
 from django.test import TestCase

 from . import models


 class ReverseFilterTestCase(TestCase):
 def setUp(self):
 self.local = models.Local.objects.create()
 self.remote = models.Remote.objects.create(fk=self.local)

 def test_reverse_filter(self):
 obj = models.Local.objects.filter(remote=self.remote).get()
 self.assertEqual(obj, self.local)

 def test_reverse_filter_direct_field_reference(self):
 obj = models.Local.objects.filter(remote__pk=self.remote.pk).get()
 self.assertEqual(obj, self.local)
 }}}

 I would expect both tests to have the same result. However, what happens
 is that `test_reverse_filter` fails with the following exception:
 {{{
 ==
 ERROR: test_reverse_filter
 (reverse_fk_test_case.tests.ReverseFilterTestCase)
 --
 Traceback (most recent call last):
   File "/home/konk/env-
 django/reverse_fk_test_case/reverse_fk_test_case/tests.py", line 12, in
 test_reverse_filter
 obj = models.Local.objects.filter(remote=self.remote).get()
   File "/home/konk/repos/git/django/django/db/models/query.py", line
 408, in get
 num = len(clone)
   File "/home/konk/repos/git/django/django/db/models/query.py", line
 258, in __len__
 self._fetch_all()
   File "/home/konk/repos/git/django/django/db/models/query.py", line
 1240, in _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File "/home/konk/repos/git/django/django/db/models/query.py", line
 57, in __iter__
 results = compiler.execute_sql(chunked_fetch=self.chunked_fetch,
 chunk_size=self.chunk_size)
   File "/home/konk/repos/git/django/django/db/models/sql/compiler.py",
 line 1068, in execute_sql
 sql, params = self.as_sql()
   File "/home/konk/repos/git/django/django/db/models/sql/compiler.py",
 line 481, in as_sql
 where, w_params = self.compile(self.where) if self.where is not None
 else ("", [])
   File "/home/konk/repos/git/django/django/db/models/sql/compiler.py",
 line 397, in compile
 sql, params = node.as_sql(self, self.connection)
   File "/home/konk/repos/git/django/django/db/models/sql/where.py",
 line 81, in as_sql
 sql, params = compiler.compile(child)
   File "/home/konk/repos/git/django/django/db/models/sql/compiler.py",
 line 397, in compile
 sql, params = node.as_sql(self, self.connection)
   File
 "/home/konk/repos/git/django/django/db/models/fields/related_lookups.py",
 line 130, in as_sql
 return super().as_sql(compiler, connection)
   File "/home/konk/repos/git/django/django/db/models/lookups.py", line
 162, in as_sql
 rhs_sql, rhs_params = self.process_rhs(compiler, connection)
   File "/home/konk/repos/git/django/django/db/models/lookups.py", line
 257, in process_rhs
 return super().process_rhs(compiler, connection)
   File "/home/konk/repos/git/django/django/db/models/lookups.py", line
 94, in process_rhs
 return self.get_db_prep_lookup(value, connection)
   File "/home/konk/repos/git/django/django/db/models/lookups.py", line
 186, in get_db_prep_lookup
 [get_db_prep_value(value, connection, prepared=True)]
   File
 "/home/konk/repos/git/django/django/db/models/fields/related.py", line
 942, in get_db_prep_value
 return self.target_field.get_db_prep_value(value, connection,
 prepared)
   File
 "/home/konk/repos/git/django/django/db/models/fields/__init__.py",
 line 1429, in get_db_prep_value
 return connection.ops.adapt_datetimefield_value(value)
   File
 "/home/konk/repos/git/django/django/db/backends/sqlite3/operations.py",
 line 218, in adapt_datetimefield_value
 if timezone.is_aware(value):
   File "/home/konk/repos/git/django/django/utils/timezone.py", line
 248, in is_aware
 return 

Re: [Django] #30476: Add detection for PostgreSQL json field, aside from the already existing detection for jsonb field, using inspectdb

[Django]

#30476: Add detection for PostgreSQL json field, aside from the already existing
detection for jsonb field, using inspectdb
-+-
 Reporter:  Héctor Pablos|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  contrib.postgres |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  inspectdb,   | Triage Stage:
  JSONField, json, jsonb |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Héctor Pablos:

Old description:

> Right now, the {{{inspectdb}}} command, when the
> {{{django.contrib.postgres}}} app is added to {{{INSTALLED_APPS}}} in the
> settings, is able to detect {{{jsonb}}} fields and generate a model with
> the right {{{django.contrib.postgres.fields.JSONField}}}, but that's not
> the case for simple {{json}} fields.
>
> [https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/fields/#django.contrib.postgres.fields.JSONField
> The documentation] states that the {{{JSONField}}} uses internally a
> PostgreSQL {{{jsonb}}} field, but I wonder if normal {{{json}}} fields
> could also be detected as a {{{JSONField}}}, as they can perfectly work
> for unmanaged models.
>

> I'm happy to do a patch for this if it's considered necessary, adding an
> additional key to the ones provided by the {{{contrib.postgres}}} module
> inside the
> [https://github.com/django/django/blob/2.2/django/contrib/postgres/apps.py#L49
> data_types_reverse dict] with the following information:
>
> {{{
> 114:  'django.contrib.postgres.fields.JSONField',
> }}}
>
> And the documentation and tests considered being necessary.
>
> The id 114 is the OID of the {{{json}}} data type in PostgreSQL, at least
> in its 11.1 version. You can check this by executing the following query:
>
> {{{#!sql
> SELECT oid, typname
> FROM pg_catalog.pg_type
> WHERE typname='json';
> }}}
>
> Also happy to check other database versions if needed.

New description:

 Right now, the {{{inspectdb}}} command, when the
 {{{django.contrib.postgres}}} app is added to {{{INSTALLED_APPS}}} in the
 settings, is able to detect {{{jsonb}}} fields and generate a model with
 the right {{{django.contrib.postgres.fields.JSONField}}}, but that's not
 the case for simple {{{json}}} fields.

 
[https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/fields/#django.contrib.postgres.fields.JSONField
 The documentation] states that the {{{JSONField}}} uses internally a
 PostgreSQL {{{jsonb}}} field, but I wonder if normal {{{json}}} fields
 could also be detected as a {{{JSONField}}}, as they can perfectly work
 for unmanaged models.


 I'm happy to do a patch for this if it's considered necessary, adding an
 additional key to the ones provided by the {{{contrib.postgres}}} module
 inside the
 [https://github.com/django/django/blob/2.2/django/contrib/postgres/apps.py#L49
 data_types_reverse dict] with the following information:

 {{{
 114:  'django.contrib.postgres.fields.JSONField',
 }}}

 And the documentation and tests considered being necessary.

 The id 114 is the OID of the {{{json}}} data type in PostgreSQL, at least
 in its 11.1 version. You can check this by executing the following query:

 {{{#!sql
 SELECT oid, typname
 FROM pg_catalog.pg_type
 WHERE typname='json';
 }}}

 Also happy to check other database versions if needed.

--

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

[Django] #30476: Add detection for PostgreSQL json field, aside from the already existing detection for jsonb field, using inspectdb

[Django]

#30476: Add detection for PostgreSQL json field, aside from the already existing
detection for jsonb field, using inspectdb
-+-
   Reporter:  Héctor |  Owner:  (none)
  Pablos |
   Type:  New| Status:  new
  feature|
  Component: |Version:  2.2
  contrib.postgres   |   Keywords:  inspectdb,
   Severity:  Normal |  JSONField, json, jsonb
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Right now, the {{{inspectdb}}} command, when the
 {{{django.contrib.postgres}}} app is added to {{{INSTALLED_APPS}}} in the
 settings, is able to detect {{{jsonb}}} fields and generate a model with
 the right {{{django.contrib.postgres.fields.JSONField}}}, but that's not
 the case for simple {{json}} fields.

 
[https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/fields/#django.contrib.postgres.fields.JSONField
 The documentation] states that the {{{JSONField}}} uses internally a
 PostgreSQL {{{jsonb}}} field, but I wonder if normal {{{json}}} fields
 could also be detected as a {{{JSONField}}}, as they can perfectly work
 for unmanaged models.


 I'm happy to do a patch for this if it's considered necessary, adding an
 additional key to the ones provided by the {{{contrib.postgres}}} module
 inside the
 [https://github.com/django/django/blob/2.2/django/contrib/postgres/apps.py#L49
 data_types_reverse dict] with the following information:

 {{{
 114:  'django.contrib.postgres.fields.JSONField',
 }}}

 And the documentation and tests considered being necessary.

 The id 114 is the OID of the {{{json}}} data type in PostgreSQL, at least
 in its 11.1 version. You can check this by executing the following query:

 {{{#!sql
 SELECT oid, typname
 FROM pg_catalog.pg_type
 WHERE typname='json';
 }}}

 Also happy to check other database versions if needed.

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

Re: [Django] #23076: Cascaded deletion of polymorphic models fails

[Django]

#23076: Cascaded deletion of polymorphic models fails
-+-
 Reporter:  jernej@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by wkoot):

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

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

[Django]

#30475: Use of i18n_patterns and a buggy 404 template trigger internal server 
error
without a backtrace
---+
   Reporter:  sha-red  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Core (URLs)  |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|
---+
 – Using i18n_patterns with prefix_default_language=True,
 – trying to get the frontpage URL without a language given in the URL

 works in debug mode, but gives an internal server error without any
 backtrace in production mode.

 This was caused by a buggy 404.html template, but probably buggy 404
 templates should give a backtrace, too, and i18n_patterns shouldn't be
 concerned by this anyway.

 [draft bug report, I'll try to provide more details later or on request]

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

Re: [Django] #30474: Minor change to documentation on many-to-many relationships. (was: Minor change to documentation on many-to-many relationships)

[Django]

#30474: Minor change to documentation on many-to-many relationships.
-+-
 Reporter:  Faheel Ahmad |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  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:  1|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Thanks for the report, however it's correct as is, IMO.

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