Re: [Django] #32355: Drop support for Python 3.6 & 3.7.

[Django]

#32355: Drop support for Python 3.6 & 3.7.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  4.0
 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 Carlton Gibson):

 * 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.a4f1273e55857c9a241998d3e82e5ff7%40djangoproject.com.

Re: [Django] #32243: Clarify docs on manually setting and saving a FileField.

[Django]

#32243: Clarify docs on manually setting and saving a FileField.
-+-
 Reporter:  Gordon Wrigley   |Owner:  Hasanul
 Type:   |  Islam
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 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 Jesse):

 Replying to [comment:5 Hasanul Islam]:
 > Hi Carlton,
 > As the file is not being saved without the `name` attribute of the file,
 shouldn't we generate the `name` property randomly if not provided by the
 user?
 >
 > If yes, I will update the relevant codes implementing random name
 generation, otherwise, I will update the documentation mentioning `name`
 is required. However, I think we should not enforce the user to provide
 the `name` attribute. I would prefer to update the code.
 **TL;DR:** Allow ContentFiles with a blank/None name. In
 `FileField.save()`, add a check after the `generate_filename()` call to
 make sure the file actually has a name once we're ready to save it to
 disk.

 When saving the model it seems to still use the `upload_to` argument. If
 you pass something for `upload_to` it will overwrite whatever was passed
 for `name`.

 Here's an example of my use case. A user can upload a picture through the
 admin panel. Whenever a new picture is uploaded I create a thumbnail for
 it.

 {{{
 def photo_upload_path(instance, original_filename):
 filename =
 hashlib.sha256(str(time.time()).encode("utf-8")).hexdigest()
 filename = filename[:16]
 return f"photos/{filename}.jpg"


 def thumbnail_upload_path(instance, original_filename):
 filename = os.path.basename(instance.photo.name)
 return f"photos/thumbnails/{filename}"


 class MyModel(models.Model):
 photo = models.ImageField(upload_to=photo_upload_path)

 # Hidden in Django admin. Managed by us.
 photo_thumbnail = models.ImageField(upload_to=thumbnail_upload_path)

 def save(self):
 img = Image.open(self.photo.path)
 img.thumbnail(settings.THUMBNAIL_SIZE)

 contents = io.BytesIO()
 img.save(contents, "JPEG")

 self.photo_thumbnail = ContentFile(contents.getvalue(),
 name="foo")

 super.save()
 }}}


 In this case, the photo gets renamed to `photos/.jpg`, and I want
 thumbnails to go to `photos/thumbnails/.jpg`.

 I resize the image, save its contents to a BytesIO object, and create the
 ContentFile object. However I have to pass in a bogus name for the
 ContentFile even though it will use the `upload_to` to overwrite it. If I
 pass an empty name Django seems to throw the file away and it doesn't get
 saved.

-- 
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.79004614098234381290f1ffb0eab36f%40djangoproject.com.

Re: [Django] #26834: MinValueValidator/MaxValueValidator not forwarded to form field for ModelForm

[Django]

#26834: MinValueValidator/MaxValueValidator not forwarded to form field for
ModelForm
-+-
 Reporter:  Sergei Maertens  |Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  MaxValueValidator,   | Triage Stage:  Accepted
  MinValueValidator, ModelForm,  |
  IntegerField   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 The proposed solution has some side-effects. We should reach a wider
 audience and consensus on DevelopersMailingList before moving this
 forward.

-- 
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/073.a5b9e9e2e21bd74f98bbd61ac9213177%40djangoproject.com.

Re: [Django] #32434: Using a RadioSelect widget with ModelChoiceField results in no empty option

[Django]

#32434: Using a RadioSelect widget with ModelChoiceField results in no empty 
option
-+-
 Reporter:  Matthew Rowbottom|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  modelchoicefield | Triage Stage:
  radioselect|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * resolution:  invalid => wontfix


-- 
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.d6c015f4294e898215000e62cc707a10%40djangoproject.com.

Re: [Django] #32434: Using a RadioSelect widget with ModelChoiceField results in no empty option

[Django]

#32434: Using a RadioSelect widget with ModelChoiceField results in no empty 
option
-+-
 Reporter:  Matthew Rowbottom|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  modelchoicefield | Triage Stage:
  radioselect|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 An empty option for `RadioSelect()` without `blank=True` in Django < 3.1
 was a bug (see #26813 and da79ee472d803963dc3ea81ee67767dc06068aac).
 That's why release notes are not included. You can add `blank=True` to
 restore an empty option.

-- 
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.eb2e448501160ec1f9a67de177e660eb%40djangoproject.com.

Re: [Django] #32433: Delete distinct produces an unexpected and potentially harmful SQL

[Django]

#32433: Delete distinct produces an unexpected and potentially harmful SQL
-+-
 Reporter:  egism|Owner:  egism
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, delete, | Triage Stage:  Accepted
  distinct   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.00106c6af2a87bba38ec66c1f3e8803a%40djangoproject.com.

Re: [Django] #32434: Using a RadioSelect widget with ModelChoiceField results in no empty option

[Django]

#32434: Using a RadioSelect widget with ModelChoiceField results in no empty 
option
-+-
 Reporter:  Matthew Rowbottom|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  modelchoicefield | Triage Stage:
  radioselect|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Matthew Rowbottom):

 * Attachment "Screen Shot 2021-02-06 at 2.25.47 pm.png" added.

 Example of how the fileds are rendered

-- 
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.a1b7726f76e99cf6ec159b90f4b5bda7%40djangoproject.com.

[Django] #32434: Using a RadioSelect widget with ModelChoiceField results in no empty option

[Django]

#32434: Using a RadioSelect widget with ModelChoiceField results in no empty 
option
-+-
   Reporter:  Matthew|  Owner:  nobody
  Rowbottom  |
   Type:  Bug| Status:  new
  Component:  Forms  |Version:  3.1
   Severity:  Normal |   Keywords:  modelchoicefield
   Triage Stage: |  radioselect
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+-
 Prior to Django v3.1, both of the fields in the following form would be
 rendered with an empty option, labelled as '-':

 {{{#!python
 from django import forms
 from .models import Animal

 class AnimalForm(forms.Form):
 animal_select = forms.ModelChoiceField(
 queryset=Animal.objects.all(),
 required=False,
 )
 animal_radio = forms.ModelChoiceField(
 queryset=Animal.objects.all(),
 required=False,
 widget=forms.RadioSelect()
 )
 }}}

 Since Django v3.1, the field using the RadioSelect widget no longer
 displays the empty option.

 I've tested it with the following versions:

 3.0works
 3.0.12works
 3.1broken
 3.1.6 broken
 3.2a1broken

 I can't find anything in the docs or the v3.1 release notes
 (https://docs.djangoproject.com/en/dev/releases/3.1/#forms) to explain the
 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.b3908f474d97ff29ef2ec0038270c19d%40djangoproject.com.

Re: [Django] #32433: Delete distinct produces an unexpected and potentially harmful SQL

[Django]

#32433: Delete distinct produces an unexpected and potentially harmful SQL
-+-
 Reporter:  egism|Owner:  egism
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, delete, | Triage Stage:  Accepted
  distinct   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by egism):

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

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

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

Re: [Django] #32145: Unclear error raised by makemessages when /locale does not exist under app directory

[Django]

#32145: Unclear error raised by makemessages when /locale does not exist under 
app
directory
-+-
 Reporter:  boxed|Owner:  Josh
 Type:   |  Santos
  Cleanup/optimization   |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |
 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:"9c6ba876928fd20194ac3238dc06aeae66d7bd50" 9c6ba876]:
 {{{
 #!CommitTicketReference repository=""
 revision="9c6ba876928fd20194ac3238dc06aeae66d7bd50"
 Fixed #32145 -- Improved makemessages error message when app's locale
 directory doesn't exist.
 }}}

-- 
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.0f6e242f5a4084656660ba9ee8cb3112%40djangoproject.com.

Re: [Django] #32114: Workaround for subtest issue with parallel test runner

[Django]

#32114: Workaround for subtest issue with parallel test runner
-+-
 Reporter:  Jordan Ephron|Owner:  Jordan
 Type:   |  Ephron
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  Test subtest | Triage Stage:  Accepted
  parallel   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


-- 
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.22b2e1cb261ce4d9c27c25207225c512%40djangoproject.com.

Re: [Django] #32145: Unclear error raised by makemessages when /locale does not exist under app directory

[Django]

#32145: Unclear error raised by makemessages when /locale does not exist under 
app
directory
-+-
 Reporter:  boxed|Owner:  Josh
 Type:   |  Santos
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 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):

 * needs_better_patch:  1 => 0
 * 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/063.66cdd45d3668c9771adf352cbf5afcba%40djangoproject.com.

Re: [Django] #32433: Delete distinct produces an unexpected and potentially harmful SQL

[Django]

#32433: Delete distinct produces an unexpected and potentially harmful SQL
-+-
 Reporter:  egism|Owner:  egism
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, delete, | Triage Stage:  Accepted
  distinct   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by egism):

 * owner:  nobody => egism
 * 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.df4c3928b214d6e2bf64bfc773c88d82%40djangoproject.com.

Re: [Django] #32433: Delete distinct produces an unexpected and potentially harmful SQL

[Django]

#32433: Delete distinct produces an unexpected and potentially harmful SQL
-+-
 Reporter:  egism|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, delete, | Triage Stage:  Accepted
  distinct   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by egism):

 Hi Simon,

 Sounds very simple, I will give it a go. Will be a good opportunity to
 make my first contribution. Thanks for directions.

-- 
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.f2a387b97b372b4ff57e685f3839c114%40djangoproject.com.

Re: [Django] #32433: Delete distinct produces an unexpected and potentially harmful SQL

[Django]

#32433: Delete distinct produces an unexpected and potentially harmful SQL
-+-
 Reporter:  egism|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, delete, | Triage Stage:  Accepted
  distinct   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * keywords:  orm, delete, distinct, postgresql => orm, delete, distinct
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 I think we should start by failing loudly when `distinct().delete()` is
 used as adding support for it would require a subquery pushdown (`DELETE
 FROM table WHERE field IN (SELECT DISTINCT field FROM table`) which would
 require a non negligible amount of work and additional complexity for the
 rare cases where this is useful and a manual `__in` subquery lookup can be
 used to achieve the same results e.g.

 {{{#!python
 Comment.objects.filter(
 post_id__in=Comment.objects.order_by('post_id',
 'created_at').distinct('post_id').values('post_id')
 ).delete()
 }}}

 **egism** if you want to work on a patch you should raise a `TypeError` in
 `QuerySet.delete` if `self.query.distinct or self.query.distinct_fields`.
 A regression test can then be added to `delete_regress/tests`
 
([https://github.com/django/django/blob/5fcfe5361e5b8c9738b1ee4c1e9a6f293a7dda40/tests/delete_regress/tests.py
 source]).

-- 
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.05083ef1e0fe14fbd798d7ef7dded111%40djangoproject.com.

Re: [Django] #32433: Delete distinct produces an unexpected and potentially harmful SQL

[Django]

#32433: Delete distinct produces an unexpected and potentially harmful SQL
-+-
 Reporter:  egism|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, delete, | Triage Stage:
  distinct, postgresql   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by egism:

Old description:

> I was looking for a way to delete the first Comment of each Post (a
> sample domain). Since I know that every new Post starts with a system
> generated comment I decided to go with:
>
> `Comment.objects.order_by('post_id',
> 'created_at').distinct('post_id').delete()`
>
> Before proceeding I tested it with:
>
> `Comment.objects.order_by('post_id',
> 'created_at').distinct('post_id').count()`
>
> Made sure the result actually contains what I needed and proceeded with
> the `delete()`. The result was rather surprising. I was notified that the
> whole table was wiped clean. I then checked the actual SQL that was
> executed and it was a simple `DELETE FROM comments;`.
>
> As an ORM user, I would say it is the worst outcome possible and I would
> at least expect an error in such a case or ideally a SQL of what I was
> trying to achieve. At the same time, `count` and `delete` produces an
> inconsistent result which is even more mistaking.
>
> Potential solutions:
> * raise an error with a decent explanation
> * produce a desired SQL according to the query

New description:

 I was looking for a way to delete the first Comment of each Post (a sample
 domain). Since I know that every new Post starts with a system generated
 comment I decided to go with:

 `Comment.objects.order_by('post_id',
 'created_at').distinct('post_id').delete()`

 Before proceeding I tested it with:

 `Comment.objects.order_by('post_id',
 'created_at').distinct('post_id').count()`

 Made sure the result actually contains what I needed and proceeded with
 the `delete()`. The result was rather surprising. I was notified that the
 whole table was wiped clean. I then checked the actual SQL that was
 executed and it was a simple `DELETE FROM comments;`.

 As an ORM user, I would say it is the worst outcome possible and I would
 at least expect an error in such a case or ideally a SQL of what I was
 trying to achieve. At the same time, `count` and `delete` produces an
 inconsistent result which is even more mistaking.

 Potential solutions:
 * raise an error with a decent explanation
 * produce a desired SQL according to the query

 Since I have never submitted a change to Django, I have a very limited
 knowledge of the ORM and its intricacies. I could give it a try and issue
 a patch for this with some guidance.

--

-- 
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.be279b0c0a729f3207d285623c31abc1%40djangoproject.com.

[Django] #32433: Delete distinct produces an unexpected and potentially harmful SQL

[Django]

#32433: Delete distinct produces an unexpected and potentially harmful SQL
-+-
   Reporter:  egism  |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  3.1
  layer (models, ORM)|   Keywords:  orm, delete,
   Severity:  Normal |  distinct, postgresql
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I was looking for a way to delete the first Comment of each Post (a sample
 domain). Since I know that every new Post starts with a system generated
 comment I decided to go with:

 `Comment.objects.order_by('post_id',
 'created_at').distinct('post_id').delete()`

 Before proceeding I tested it with:

 `Comment.objects.order_by('post_id',
 'created_at').distinct('post_id').count()`

 Made sure the result actually contains what I needed and proceeded with
 the `delete()`. The result was rather surprising. I was notified that the
 whole table was wiped clean. I then checked the actual SQL that was
 executed and it was a simple `DELETE FROM comments;`.

 As an ORM user, I would say it is the worst outcome possible and I would
 at least expect an error in such a case or ideally a SQL of what I was
 trying to achieve. At the same time, `count` and `delete` produces an
 inconsistent result which is even more mistaking.

 Potential solutions:
 * raise an error with a decent explanation
 * produce a desired SQL according to the query

-- 
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.4429781fe8896983dca2738564978f28%40djangoproject.com.

Re: [Django] #32428: [Feature Request] Allow DeleteView to override the redirect to use 303

[Django]

#32428: [Feature Request] Allow DeleteView to override the redirect to use 303
---+--
 Reporter:  kimsia |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Generic views  |  Version:  3.1
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

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


Comment:

 Hi, no sorry — I don't think any extra API is worth the added complexity
 here. Override `delete()` and return the response you want. It's four
 lines.

 See also the discussion on #21936 — the interplay between `DeleteView` and
 `DeletionMixin` is already too complicated and confused. We want to
 (radically) simplify that (if we're able to given backwards compatibility
 concerns) before we'll consider any expansions. I hope that makes sense.

-- 
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.a6773f5136d39d956ed6969439023618%40djangoproject.com.

Re: [Django] #32431: Consider listing the history of security issues in reverse chronological order

[Django]

#32431: Consider listing the history of security issues in reverse chronological
order
--+
 Reporter:  Jaap Roes |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 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 Carlton Gibson):

 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Hey Jaap, OK yes, I guess :) (I've half thought this myself at times
 so...)

-- 
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.a12000c42c74c6a8cbdb0c9f0b1b1c2b%40djangoproject.com.

Re: [Django] #24472: Define internal types explicitly for related fields

[Django]

#24472: Define internal types explicitly for related fields
-+-
 Reporter:  Andriy Sokolovskiy   |Owner:  (none)
 Type:  New feature  |   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 Mariusz Felisiak):

 * owner:  Andriy Sokolovskiy => (none)
 * status:  assigned => new


-- 
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.a201c937e9f4d6e7c1af8978bcfa25da%40djangoproject.com.

Re: [Django] #24472: Define internal types explicitly for related fields

[Django]

#24472: Define internal types explicitly for related fields
-+-
 Reporter:  Andriy Sokolovskiy   |Owner:  Andriy
 |  Sokolovskiy
 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:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/066.eb01f37c3e2ae0c3f396923070c1f725%40djangoproject.com.

Re: [Django] #20749: Add validation for type of Field.choices arguments

[Django]

#20749: Add validation for type of Field.choices arguments
--+
 Reporter:  ellisd23@…|Owner:  (none)
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  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 Mariusz Felisiak):

 * owner:  ellisd23 => (none)
 * status:  assigned => new


-- 
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/076.74fc223868f31b82b380646321ca8982%40djangoproject.com.

Re: [Django] #32256: squashmigrations optimizer crashes when fields' names are swapped using a temporary name

[Django]

#32256: squashmigrations optimizer crashes when fields' names are swapped using 
a
temporary name
-+-
 Reporter:  InvalidInterrupt |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


Comment:

 > I am not sure about the solution proposed by @InvalidInterrupt.

 Sounds reasonable.

-- 
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/074.086ce2ce8752dedc14f94f0ce47f7617%40djangoproject.com.