Re: [Django] #33335: Django admin error when adding new object, when using Django 4 functional unique constraints on model

[Django]

#5: Django admin error when adding new object, when using Django 4 
functional
unique constraints on model
---+--
 Reporter:  Hervé Le Roy   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  4.0
 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
---+--

Comment (by Claude Paroz):

 Note you should also be able to test outside the admin with `tag =
 Tag(...); tag.full_clean()`.

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

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

Re: [Django] #30398: Check database connection's health before it is reused

[Django]

#30398: Check database connection's health before it is reused
-+-
 Reporter:  Przemysław Suliga|Owner:
 |  Przemysław Suliga
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"4ce59f602ed28320caf3035212cb4d1c5430da2b" 4ce59f60]:
 {{{
 #!CommitTicketReference repository=""
 revision="4ce59f602ed28320caf3035212cb4d1c5430da2b"
 Fixed #30398 -- Added CONN_HEALTH_CHECKS database setting.

 The CONN_HEALTH_CHECKS setting can be used to enable database
 connection health checks for Django's persistent DB connections.

 Thanks Florian Apolloner for reviews.
 }}}

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

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

Re: [Django] #33334: Alphabetize form and model fields in docs. (was: TypedChoiceField misplaced in form fields docs)

[Django]

#4: Alphabetize form and model fields in docs.
--+
 Reporter:  Claude Paroz  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 In models fields only `GenericIPAddressField` is unsorted, I think we
 should also alphabetize it.

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

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

Re: [Django] #33282: django.db.utils.ProgrammingError: more than one row returned by a subquery used as an expression

[Django]

#33282: django.db.utils.ProgrammingError: more than one row returned by a 
subquery
used as an expression
-+-
 Reporter:  Antonio Terceiro |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (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
-+-
Changes (by Simon Charette):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


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

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

Re: [Django] #33333: Models with a BinaryField fail to deepcopy in setUpTestData() on PostgreSQL.

[Django]

#3: Models with a BinaryField fail to deepcopy in setUpTestData() on
PostgreSQL.
-+-
 Reporter:  Adam Zimmerman   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak):

 > Should we submit a patch meant to be backported to 3.2 and 4.0 in
 setUpTestData that solely deals with this particular edge case of models
 and queryset with a BinaryField on Postgres to circumvent #27813?

 Yes, it should be feasible by juggling with `__getstate__()/__reduce__()`
 hooks 樂 I think we should treat this as a release blocker because
 `BinaryField` is built-in into Django and
 3cf80d3fcf7446afdde16a2be515c423f720e54d broke previously working tests.

 > What if we get other reports of users who ignored the deprecation
 warning for other non-pickleable objects assigned during setUpTestData?

 That would not be a release blocker, IMO, unless any other built-in is
 non-pickleable.

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

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

Re: [Django] #25947: Query's str() method fails when 'default' database is empty

[Django]

#25947: Query's str() method fails when 'default' database is empty
-+-
 Reporter:  liboz|Owner:  Teddy Ni
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (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
-+-
Changes (by Teddy Ni):

 * has_patch:  0 => 1


Comment:

 Patch is provided in https://github.com/django/django/pull/15142.

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

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

Re: [Django] #25947: Query's str() method fails when 'default' database is empty

[Django]

#25947: Query's str() method fails when 'default' database is empty
-+-
 Reporter:  liboz|Owner:  Teddy Ni
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (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 Teddy Ni):

 * owner:  nobody => Teddy Ni
 * status:  new => assigned


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

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

Re: [Django] #33330: Printing QuerySet.query from non-default DB can throw an error

[Django]

#0: Printing QuerySet.query from non-default DB can throw an error
-+-
 Reporter:  Teddy Ni |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 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 Teddy Ni):

 Thank you for finding and linking to the duplicate ticket!

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

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

Re: [Django] #33335: Django admin error when adding new object, when using Django 4 functional unique constraints on model

[Django]

#5: Django admin error when adding new object, when using Django 4 
functional
unique constraints on model
---+--
 Reporter:  Hervé Le Roy   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  4.0
 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 Tim Graham):

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


Comment:

 See TicketClosingReasons/UseSupportChannels for ways to get help debugging
 the issue. Feel free to reopen if you confirm Django is at fault.

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

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

[Django] #33335: Django admin error when adding new object, when using Django 4 functional unique constraints on model

[Django]

#5: Django admin error when adding new object, when using Django 4 
functional
unique constraints on model
-+
   Reporter:  Hervé Le Roy   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  contrib.admin  |Version:  4.0
   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  |
-+
 When creating a new object from Django Administration site, I'm getting an
 error "Tag with this already exists.". (Tag is my model name)

 I'm using on this model the new functional unique constraints introducted
 in Django 4.0
 
(https://docs.djangoproject.com/en/dev/ref/models/constraints/#django.db.models.UniqueConstraint).

 I suppose this is related to the contraints put on the model. However,
 creating a Tag object with code - e.g. `Tag.objects.create(...)` - works
 fine. It only fails in Django admin. I'm not sure if it's a bug or
 misunderstanding/misconfiguration on my side?


 This is my model:
 {{{
 class Tag(models.Model):
 """Basic tag model."""
 # When using get_or_create, we need to pass tag name as a default
 value, like this:
 # Tag.objects.get_or_create(defaults={'name': tag}, name__iexact=tag,
 user=request.user)
 user = models.ForeignKey(settings.AUTH_USER_MODEL,
 on_delete=models.CASCADE, verbose_name=_('user'))
 name = models.CharField(max_length=50, db_index=False,
 verbose_name=_('name'),
 blank=False,  # It's the default behavior, but
 let's be explicit
 validators=[RegexValidator(regex=r'[A-z0-9À-ž\s]+',
message='This field
 accepts only letters, digits and space.')])
 slug = models.SlugField(max_length=50, verbose_name=_('slug'))

 class Meta:
 ordering = ['name']
 # Make sure tag name:
 # - are unique per user
 # - are case insensitive (prevent adding "test" if "Test" already
 exists)
 # - aren't empty
 constraints = [models.UniqueConstraint(fields=['user', 'name'],
 name='%(app_label)s_%(class)s_name_unique_per_user'),
models.UniqueConstraint(Lower('name'),
 name='%(app_label)s_%(class)s_name_case_insensitive'),
 models.CheckConstraint(check=models.Q(name__length__gt=0),
 name='%(app_label)s_%(class)s_name_not_empty')]
 (snip)
 }}}

 This is the admin configuration:
 {{{
 @admin.register(Tag)
 class TagAdmin(admin.ModelAdmin):
 list_display = ('pk', 'user', 'name', 'slug')
 list_display_links = ['pk']
 fields = ('user', 'name',)
 list_filter = ('user__email',)
 search_fields = ('name',)
 }}}

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

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

Re: [Django] #33334: TypedChoiceField misplaced in form fields docs

[Django]

#4: TypedChoiceField misplaced in form fields docs
-+-
 Reporter:  Claude Paroz |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 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 Tim Graham):

 There are some others out of order. Similar to TypedChoiceField following
 ChoieField, TypedMultipleChoiceField follows MultipleChoiceField. Also
 GenericIPAddressField is out of order. It probably followed IPAddressField
 before its removal.

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

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

Re: [Django] #33333: Models with a BinaryField fail to deepcopy in setUpTestData() on PostgreSQL.

[Django]

#3: Models with a BinaryField fail to deepcopy in setUpTestData() on
PostgreSQL.
-+-
 Reporter:  Adam Zimmerman   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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):

 > considering changing memoryview to bytes might have serious memory
 implications not plainly visible in tests.

 Fixing #27813 would be somewhat of a breaking change on PostgreSQL as a
 different type would be returned but I doubt it would have memory
 implications in the sense of elevated memory usage.

 In the end `memoryview` is a pointer to a sequence of bytes but these
 bytes have to live somewhere when returned from the database backend and
 made available to the client. Returning them proxied by a `memoryview`
 instance or not should not make a significant difference in memory usage
 beyond the size of the `memoryview` instance itself.

 ---

 Mariusz, how do you want to proceed here? I have to admit I'm not sure how
 to navigate the current state of things.

 Should we submit a patch meant to be backported to 3.2 and 4.0 in
 `setUpTestData` that solely deals with this particular edge case of models
 and queryset with a `BinaryField` on Postgres to circumvent #27813? What
 if we get other reports of users who ignored the deprecation warning for
 other non-pickleable objects assigned during `setUpTestData`?

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

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

[Django] #33334: TypedChoiceField misplaced in form fields docs

[Django]

#4: TypedChoiceField misplaced in form fields docs
+
   Reporter:  Claude Paroz  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  dev
   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 |
+
 Form fields are alphabetically sorted in the
 [https://docs.djangoproject.com/en/dev/ref/forms/fields/ reference for
 form fields], except for TypedChoiceField.

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

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

Re: [Django] #33333: Models with a BinaryField fail to deepcopy in setUpTestData() on PostgreSQL.

[Django]

#3: Models with a BinaryField fail to deepcopy in setUpTestData() on
PostgreSQL.
-+-
 Reporter:  Adam Zimmerman   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak):

 We have also a ticket about `BinaryField` inconsistency, see #27813.

 > What about writing a workaround for setuptestData in 4.0 ...

 For me it is a 3.2 release blocker.

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

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

Re: [Django] #33333: Models with a BinaryField fail to deepcopy in setUpTestData() on PostgreSQL.

[Django]

#3: Models with a BinaryField fail to deepcopy in setUpTestData() on
PostgreSQL.
-+-
 Reporter:  Adam Zimmerman   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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):

 Given we're pretty close to the 4.0 release date I'm not against including
 a limited hack for `setUpTestData` that special cases `Model` and
 `QuerySet` instances.

 It does feel weird that we're treating this as a release blocker now
 thought given it has been broken since `BinaryField` was introduced and
 `setUpTestData`
 
[https://github.com/django/django/commit/3cf80d3fcf7446afdde16a2be515c423f720e54d
 #diff-
 7833da5b45a68d00834388d97dd5c4413e3796497c7bc5e0cc2621b08a2d0df1R1108-R1120
 has been emitting deprecation warnings about it since Django 3.2].

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

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

Re: [Django] #30398: Check database connection's health before it is reused

[Django]

#30398: Check database connection's health before it is reused
-+-
 Reporter:  Przemysław Suliga|Owner:
 |  Przemysław Suliga
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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 Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #33333: Models with a BinaryField fail to deepcopy in setUpTestData() on PostgreSQL.

[Django]

#3: Models with a BinaryField fail to deepcopy in setUpTestData() on
PostgreSQL.
-+-
 Reporter:  Adam Zimmerman   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Claude Paroz):

 Simon, your diagnostic might be right, but I think it's late in the 4.0
 release cycle to make such changes now, also considering changing
 `memoryview` to `bytes` might have serious memory implications not plainly
 visible in tests.

 What about writing a workaround for `setuptestData` in 4.0, and make a
 more proper and thorough fix in 4.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.23c4081b625dd448dbb5c20b78a4079b%40djangoproject.com.

Re: [Django] #33333: Models with a BinaryField fail to deepcopy in setUpTestData() on PostgreSQL.

[Django]

#3: Models with a BinaryField fail to deepcopy in setUpTestData() on
PostgreSQL.
-+-
 Reporter:  Adam Zimmerman   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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):

 My first instinct would be to have `BinaryField.from_db_value` use
 `force_bytes` to store `bytes` instead of `memoryview` in `_state` or
 introduce a hook to allow `Field` subclass to define a hook using during
 serialization and have the model machinery

 To me that's more of a long standing issue with `BinaryField` and less of
 a regression cause by 3cf80d3fcf7446afdde16a2be515c423f720e54d.

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

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

Re: [Django] #33333: Models with a BinaryField fail to deepcopy in setUpTestData() on PostgreSQL.

[Django]

#3: Models with a BinaryField fail to deepcopy in setUpTestData() on
PostgreSQL.
-+-
 Reporter:  Adam Zimmerman   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Simon Charette):

 * stage:  Unreviewed => Accepted


Comment:

 Feels like the issue should be solved at the model level because while it
 break `setupTestData` (3cf80d3fcf7446afdde16a2be515c423f720e54d) it also
 breaks any form of `QuerySet` or `Model` pickling


 {{{#!python
 MyModel.objects.create(binary=b'y')
 pickle.dumps(MyModel.objects.all())
 }}}

 This can be reproduced by adding a `BinaryField` to
 
[https://github.com/django/django/blob/ca9872905559026af82000e46cde6f7dedc897b6/tests/queryset_pickle/models.py#L48
 models] in the test `queryset_pickle` apps.

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

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

Re: [Django] #33047: CheckConstraint crashes with GIS lookup and PostGIS, MySQL, and Oracle backends.

[Django]

#33047: CheckConstraint crashes with GIS lookup and PostGIS, MySQL, and Oracle
backends.
-+-
 Reporter:  Daniel Swain |Owner:  Claude
 |  Paroz
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  constraint,  | Triage Stage:  Ready for
  postgres, postgis, geos,   |  checkin
  attributeerror, migration, |
  schema_editor, getquoted,  |
  quote_value|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"64c3f049ea3bcb1c82f35ae09f1dd5349a826a5c" 64c3f049]:
 {{{
 #!CommitTicketReference repository=""
 revision="64c3f049ea3bcb1c82f35ae09f1dd5349a826a5c"
 Fixed #33047 -- Fixed CheckConstraint crash with GIS lookups on PostGIS
 and MySQL GIS backends.

 Thanks Daniel Swain for the report and Arsalan Ghassemi for the initial
 patch.

 Co-authored-by: Mariusz Felisiak 
 }}}

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

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

Re: [Django] #33333: Models with a BinaryField fail to deepcopy in setUpTestData() on PostgreSQL. (was: Models with a BinaryField fail to deepcopy)

[Django]

#3: Models with a BinaryField fail to deepcopy in setUpTestData() on
PostgreSQL.
-+-
 Reporter:  Adam Zimmerman   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak):

 * cc: Simon Charette (added)
 * severity:  Normal => Release blocker


Comment:

 Thanks for the report! Regression in
 3cf80d3fcf7446afdde16a2be515c423f720e54d. I was able to reproduce this
 issue on PostgreSQL with the following test:
 {{{#!python
 class MyTests(TestCase):
 @classmethod
 def setUpTestData(cls):
 MyModel.objects.create(binary=b'y')
 cls.my_binary = MyModel.objects.get()

 def test_1(self):
 self.my_binary.binary = b'z'
 self.my_binary.save()
 }}}

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

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

Re: [Django] #33332: Writing your first Django app, part 5 - error please help me.

[Django]

#2: Writing your first Django app, part 5 - error please help me.
---+--
 Reporter:  seoyule|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Testing framework  |  Version:  3.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Mariusz Felisiak):

 It looks that you're using docs for a wrong version of Django.

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

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

Re: [Django] #33333: Models with a BinaryField fail to deepcopy

[Django]

#3: Models with a BinaryField fail to deepcopy
-+-
 Reporter:  Adam Zimmerman   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Adam Zimmerman):

 For anyone who finds this ticket and wants to work around it before it's
 fixed in Django, here's the mixin I'm currently using:

 {{{#!python
 class ContainsBinaryField:
 """A mixin for model classes that contain BinaryField fields

 Django 3.2 has started using deepcopy() to isolate changes to data
 created in
 setUpTestData(). This seems to cause issues with models that have a
 BinaryField in
 them. This implements the __getstate__() method in a way that converts
 any
 memoryview data to bytes, which seems to fix the issue."""

 def __getstate__(self):
 state = super().__getstate__()
 for key, value in state.items():
 if isinstance(value, memoryview):
 state[key] = bytes(value)
 return state
 }}}

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

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

[Django] #33333: Models with a BinaryField fail to deepcopy

[Django]

#3: Models with a BinaryField fail to deepcopy
-+-
   Reporter:  Adam   |  Owner:  nobody
  Zimmerman  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  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  |
-+-
 While using Postgres, models with a BinaryField fail to deepcopy, due to
 Django returning these field values as `memoryview` objects. This causes
 issues when creating instances in `setUpTestData()` during tests.

 The specific errors seem to be fairly inconsistent and hard to reproduce.
 But often the exception complains about a missing `_state` field, or that
 `_state` has no attribute `db`.

 I've currently worked around this by implementing a mixin for models where
 the `__getstate__()` method converts any `memoryview`s to `bytes`. But I
 don't know if that's the correct solution for Django generally.

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

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

Re: [Django] #33332: Writing your first Django app, part 5 - error please help me.

[Django]

#2: Writing your first Django app, part 5 - error please help me.
---+--
 Reporter:  seoyule|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Testing framework  |  Version:  3.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

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


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

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

Re: [Django] #33332: Writing your first Django app, part 5 - error please help me.

[Django]

#2: Writing your first Django app, part 5 - error please help me.
---+--
 Reporter:  seoyule|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Testing framework  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 Hi, you'll need to post on one of the support channels, such as the forum:
 https://forum.djangoproject.com

 See TicketClosingReasons/UseSupportChannels.

 (It's hard to see from the code posted but it looks like you have a string
 value rather than the object in your `context`... — Good luck.)

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

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

[Django] #33332: Writing your first Django app, part 5 - error please help me.

[Django]

#2: Writing your first Django app, part 5 - error please help me.
-+
   Reporter:  seoyule|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Testing framework  |Version:  3.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  |
-+
 Hi Thank you for the great tutorial.

 I'm shadowing this tutorial but keep encountering the following error:
 AssertionError: Lists differ: ? != []

 **Below is the related code

 def test_past_question(self):
 question = create_question(question_text="Past question.",
 days=-30)
 response = self.client.get(reverse('polls:index'))
 self.assertQuerysetEqual(
 response.context['latest_question_list'],
 [question]
 )

 ** And below is the error message.
 ==
 FAIL: test_past_question (polls.tests.QuestionIndexViewTests)
 ==
 Traceback (most recent call last):
   File "/Users/seoyulejo/projects/mysite3/polls/tests.py", line 50, in
 test_past_question
 self.assertQuerysetEqual(
   File "/Users/seoyulejo/venvs/mysite/lib/python3.8/site-
 packages/django/test/testcases.py", line 1052, in assertQuerysetEqual
 return self.assertEqual(list(items), values, msg=msg)
 AssertionError: Lists differ: [''] !=
 []

 First differing element 0:
 ''
 

 - ['']
 ?  -  -

 + []

 Could anyone help me find out the reason of the error?

 Thank you so much

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

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

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

[Django]

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

 * cc: Julien Palard (added)


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

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

Re: [Django] #33331: Improve exception handling with `cursor.close()` after errors

[Django]

#1: Improve exception handling with `cursor.close()` after errors
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Daniel Hahler):

 * has_patch:  0 => 1


Old description:

> `cursor.close()` is explicitly after Exceptions with `cursor.execute()`,
> and has a comment already that it might fail:
> https://github.com/django/django/blob/322a1a037d4d2f18744c5d1a1efc2e84d4c5e94b/django/db/models/sql/compiler.py#L1210-L1215
>
> {{{
> try:
> cursor.execute(sql, params)
> except Exception:
> # Might fail for server-side cursors (e.g. connection closed)
> cursor.close()
> }}}
>
> The code there was changed to ignore any exception in
> https://github.com/django/django/commit/6b6be692fcd102436c7abef1d7b3fa1d37ad4bdf
> (Refs #16614), but then changed to the current code in
> https://github.com/django/django/commit/d170c63351944fd91b2206d10f89e7ff75b53b76
> (https://github.com/django/django/commit/d170c63351944fd91b2206d10f89e7ff75b53b76
> #diff-f58de2deaccecd2d53199c5ca29e3e1050ec2adb80fb057cdfc0b4e6accdf14f).
>
> The current approach however will create a chained exception always, and
> especially will add it as context, and not as cause (see
> https://blog.ram.rachum.com/post/621791438475296768/improving-python-
> exception-chaining-with).
>
> I suggest that exceptions in `cursor.close()` should get ignored as being
> expected in a lot / most cased, and it being done only to ensure the
> connection gets closed really, and should get `raised from` otherwise.
>
> The main motivation here is that it makes it hard/confusing to see the
> real error, e.g. when running tests or doing development, and the DB is
> out of sync.

New description:

 `cursor.close()` is explicitly after Exceptions with `cursor.execute()`,
 and has a comment already that it might fail:
 
https://github.com/django/django/blob/322a1a037d4d2f18744c5d1a1efc2e84d4c5e94b/django/db/models/sql/compiler.py#L1210-L1215

 {{{
 try:
 cursor.execute(sql, params)
 except Exception:
 # Might fail for server-side cursors (e.g. connection closed)
 cursor.close()
 }}}

 The code there was changed to ignore any exception in
 
https://github.com/django/django/commit/6b6be692fcd102436c7abef1d7b3fa1d37ad4bdf
 (Refs #16614), but then changed to the current code in
 
https://github.com/django/django/commit/d170c63351944fd91b2206d10f89e7ff75b53b76
 
(https://github.com/django/django/commit/d170c63351944fd91b2206d10f89e7ff75b53b76
 #diff-f58de2deaccecd2d53199c5ca29e3e1050ec2adb80fb057cdfc0b4e6accdf14f).

 The current approach however will create a chained exception always, and
 especially will add it as context, and not as cause (see
 https://blog.ram.rachum.com/post/621791438475296768/improving-python-
 exception-chaining-with).

 I suggest that exceptions in `cursor.close()` should get ignored as being
 expected in a lot / most cased, and it being done only to ensure the
 connection gets closed really, and should get `raised from` otherwise.

 The main motivation here is that it makes it hard/confusing to see the
 real error, e.g. when running tests or doing development, and the DB is
 out of sync.

 PR: https://github.com/django/django/pull/15141

--

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

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

[Django] #33331: Improve exception handling with `cursor.close()` after errors

[Django]

#1: Improve exception handling with `cursor.close()` after errors
-+-
   Reporter:  Daniel |  Owner:  nobody
  Hahler |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  3.2
  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  |
-+-
 `cursor.close()` is explicitly after Exceptions with `cursor.execute()`,
 and has a comment already that it might fail:
 
https://github.com/django/django/blob/322a1a037d4d2f18744c5d1a1efc2e84d4c5e94b/django/db/models/sql/compiler.py#L1210-L1215

 {{{
 try:
 cursor.execute(sql, params)
 except Exception:
 # Might fail for server-side cursors (e.g. connection closed)
 cursor.close()
 }}}

 The code there was changed to ignore any exception in
 
https://github.com/django/django/commit/6b6be692fcd102436c7abef1d7b3fa1d37ad4bdf
 (Refs #16614), but then changed to the current code in
 
https://github.com/django/django/commit/d170c63351944fd91b2206d10f89e7ff75b53b76
 
(https://github.com/django/django/commit/d170c63351944fd91b2206d10f89e7ff75b53b76
 #diff-f58de2deaccecd2d53199c5ca29e3e1050ec2adb80fb057cdfc0b4e6accdf14f).

 The current approach however will create a chained exception always, and
 especially will add it as context, and not as cause (see
 https://blog.ram.rachum.com/post/621791438475296768/improving-python-
 exception-chaining-with).

 I suggest that exceptions in `cursor.close()` should get ignored as being
 expected in a lot / most cased, and it being done only to ensure the
 connection gets closed really, and should get `raised from` otherwise.

 The main motivation here is that it makes it hard/confusing to see the
 real error, e.g. when running tests or doing development, and the DB is
 out of sync.

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

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

Re: [Django] #33324: Missing static file errors with manifest storage are particularly hard to debug (no error email)

[Django]

#33324: Missing static file errors with manifest storage are particularly hard 
to
debug (no error email)
-+-
 Reporter:  Michael  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  contrib.staticfiles  |  Version:  3.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  static manifest  | Triage Stage:
  storage|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Michael.

 I'm likely being slow here but, I'm struggling to see exactly what the
 issue is you're encountering here.

 I'm expecting manifest errors to come up during the `collectstatic` run,
 rather than in the request-response cycle.
 Also, debug error pages are only used when `DEBUG=True`, so exactly when
 file names are not hashed.

 Can you put a sample project together that shows the issue exactly? — It's
 much easier if I can see it in play, rather than trying to guess what
 you're seeing.
 Thanks!

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

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

Re: [Django] #25947: Query's str() method fails when 'default' database is empty

[Django]

#25947: Query's str() method fails when 'default' database is empty
-+-
 Reporter:  liboz|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (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 Egor R):

 * cc: Egor R (added)


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

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

Re: [Django] #33321: Django admin doesn't render "add another / modify" icons next to ForeignKey fields that are declared in the ModelForm

[Django]

#33321: Django admin doesn't render "add another / modify" icons next to 
ForeignKey
fields that are declared in the ModelForm
---+--
 Reporter:  James Pic  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 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:  1
---+--
Changes (by Carlton Gibson):

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


Comment:

 Hi James.

 > BUT, it won't if my field is declared in the ModelForm...

 Yes. So, this is the standard (and expected) behaviour for this kind of
 generation: if you declare the field yourself, then that's what you get.

 The same applies to ModelForms, DRF serialisers, django-filter FilterSets,
 and I would expect everything else similar: it comes up on DRF as ''Why
 was my `read_only_field` not applied to my explicitly defined serialiser
 field?''

 The relevant docs are the extended note in the
 [https://docs.djangoproject.com/en/3.2/topics/forms/modelforms
 /#overriding-the-default-fields Overriding the default fields section of
 the ModelForms topic docs]. It says more but:

 > The fields that are automatically generated depend on the content of the
 Meta class and on which fields have already been defined declaratively.
 Basically, ModelForm will only generate fields that are missing from the
 form, or in other words, fields that weren’t defined declaratively.

 To me, it would be deeply surprising if we were to change the behaviour
 for the admin here: ''You get the field you declare except in this case''
 is going to be more difficult to reason about in aggregate.

 If I wanted to address this in my project, I'd probably look overriding
 `ModelAdmin.get_form()`, rather than pulling knowledge of
 `RelatedFieldWidgetWrapper ` into `forms/models.py`.

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

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