Re: [Django] #31177: Use "raise from" where appropriate

[Django]

#31177: Use "raise from" where appropriate
--+
 Reporter:  Ram Rachum|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  3.0
 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 Claude Paroz):

 * status:  closed => new
 * resolution:  wontfix =>
 * stage:  Unreviewed => Accepted


Comment:

 I think 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/064.1786829796633e36a1271a58cf22d531%40djangoproject.com.

Re: [Django] #30846: postgis backend doesn't respect custom index names.

[Django]

#30846: postgis backend doesn't respect custom index names.
-+-
 Reporter:  Thomas Steen |Owner:
  Rasmussen  |  Pratik1999
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  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 Pratik1999):

 * owner:  Ahisahar Pretel => Pratik1999


Comment:

 This ticket seems inactive. So I am assigning it to myself

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

Re: [Django] #29095: QuerySet.count() with Sum window function generates invalid SQL on PostgreSQL

[Django]

#29095: QuerySet.count() with Sum window function generates invalid SQL on
PostgreSQL
-+-
 Reporter:  Shadi Akiki  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  window   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by clickonchris):

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


Comment:

 Hi There!  I ran across this old bug and have some additional information
 to share.  In my case the "missing ingredient"  is when you join to
 another table and then include a column from the join table in the window
 function's ORDER BY clause.

 I created a test to show the problem here:

 
https://github.com/clickonchris/django/commit/29feb51531ac4d1a65a40003d609295b3d88c001

 The .count() function generates SQL as below.  I've included a code
 comment above the problematic GROUP BY at the end

 {{{
 SELECT COUNT(*) FROM (
   SELECT
 "expressions_window_employee"."id" AS Col1,
 SUM("expressions_window_employee"."salary")
 OVER (PARTITION BY "expressions_window_employee"."department" ORDER BY
 "expressions_window_employee"."hire_date",
 "expressions_window_employeeclassification"."description") AS
 "department_sum"
   FROM "expressions_window_employee" INNER JOIN
 "expressions_window_employeeclassification" ON
 ("expressions_window_employee"."classification_id" =
 "expressions_window_employeeclassification"."code")
   -- This GROUP BY seems unnecessary
  GROUP BY "expressions_window_employee"."id"
 ) subquery
 }}}

-- 
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/072.9e96c4d5384a52c5bc10810548946339%40djangoproject.com.

[Django] #31189: django.contrib.auth: Password field help text generates invalid html

[Django]

#31189: django.contrib.auth: Password field help text generates invalid html
--+
   Reporter:  Marc Nieper-Wißkirchen  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  contrib.auth|Version:  3.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   |
--+
 The help text for the password field of, say, the UserCreationForm, is
 generated here:
 
https://github.com/django/django/blob/master/django/contrib/auth/password_validation.py#L78
 and is an html list. The form methods, `as_table' and `as_p', however,
 wrap the help text into a span tag. In the resulting rendered HTML, there
 will thus be a ul tag inside a span tag, which is invalid html.

 To solve this problem, the span tag needs to be a div.

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

Re: [Django] #31177: Use "raise from" where appropriate

[Django]

#31177: Use "raise from" where appropriate
-+-
 Reporter:  Ram Rachum   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ram Rachum):

 Are we good for reopening the 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/064.0ceb87c5fe5601013c864815524cfc35%40djangoproject.com.

Re: [Django] #24535: Make "manage.py migrate" atomic, i.e. rolling back any migrations on failure

[Django]

#24535: Make "manage.py migrate" atomic, i.e. rolling back any migrations on
failure
---+--
 Reporter:  Daniel Hahler  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Migrations |  Version:  1.7
 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
---+--

Comment (by Simon Charette):

 Even if this limitation is now lifted it would still be impossible in the
 case of non-atomic migrations/operations
 [https://docs.djangoproject.com/en/3.0/howto/writing-migrations/#non-
 atomic-migrations either explicit] or implicit because the database
 backend doesn't support transactional DDL. The framework also defers quite
 of bit of operations (search for usage of `deferred_sql` in the code base)
 and some are
 [https://docs.djangoproject.com/en/3.0/ref/contrib/postgres/operations
 /#index-concurrent-operations simply unsupported in a transaction].

 If you really want to give this a go you can easily override the `migrate`
 command by wrapping it's `handle` in an `atomic` block for the specified
 `--database` but you have to keep in mind that'll likely break under
 certain circumstances and it has the potential to take your side database
 down if the transaction is held because of a long running operation.

 If you really want to roll back on failure you can easily emulate such
 thing by keeping track of where you are before performing migrating and
 migrating to the previous state if any exception is raised. This is
 something you can easily achieve with the commands the migration framework
 currently exposes.

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

Re: [Django] #30923: Out of date examples in docs that call render() with a Context instance instead of regular dict

[Django]

#30923: Out of date examples in docs that call render() with a Context instance
instead of regular dict
-+-
 Reporter:  Alasdair Nicol   |Owner:  Daniel
 Type:   |  Rios
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  Context render   | Triage Stage:  Accepted
  template   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Daniel Rios):

 * owner:  nobody => Daniel Rios
 * 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/071.497488524298b48a0566d49e9e2ec388%40djangoproject.com.

Re: [Django] #31186: Error updating unique field

[Django]

#31186: Error updating unique field
-+-
 Reporter:  Kailegh  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  migration,   | Triage Stage:
  TextField, CharField   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * type:  Uncategorized => Bug


Old description:

> Hi, I think I have discovered a bug, if you have a field like the
> following:
> audio_name = models.CharField(blank=False, max_length=255)
> and decide to change it to the following one:
>
> audio_name = models.TextField(blank=False)
>
> it generates the following migration code:
>
>operations = [
> migrations.AlterModelOptions(
> name='s3_bucket_audios',
> options={},
> ),
> migrations.AlterField(
> model_name='s3_bucket_audios',
> name='audio_name',
> field=models.TextField(help_text='name of the audio in the s3
> bucket'),
> ),
> migrations.AlterUniqueTogether(
> name='s3_bucket_audios',
> unique_together=set(),
> ),
> ]
>
> However it that field was being use in a unique condition:
>  class Meta:
>ordering = [ "audio_name"]
>unique_together = ('audio_name')
>
> you get the following error:
> django.db.utils.OperationalError: (1170, "BLOB/TEXT column 'audio_name'
> used in key specification without a key length")
>
> That is because it changes the field type before changing the unique
> condition, I think the order should be handled automatically, I had to
> change the code manually to:
>
>operations = [
> migrations.AlterModelOptions(
> name='s3_bucket_audios',
> options={},
> ),
> migrations.AlterUniqueTogether(
> name='s3_bucket_audios',
> unique_together=set(),
> ),
> migrations.AlterField(
> model_name='s3_bucket_audios',
> name='audio_name',
> field=models.TextField(help_text='name of the audio in the s3
> bucket'),
> ),
> ]
>
> It is not a big issue anyway...
> Thanks a lot for your amazing work!!

New description:

 Hi, I think I have discovered a bug, if you have a field like the
 following:
 {{{
 audio_name = models.CharField(blank=False, max_length=255)
 }}}
 and decide to change it to the following one:
 {{{
 audio_name = models.TextField(blank=False)
 }}}
 it generates the following migration code:
 {{{
operations = [
 migrations.AlterModelOptions(
 name='s3_bucket_audios',
 options={},
 ),
 migrations.AlterField(
 model_name='s3_bucket_audios',
 name='audio_name',
 field=models.TextField(help_text='name of the audio in the s3
 bucket'),
 ),
 migrations.AlterUniqueTogether(
 name='s3_bucket_audios',
 unique_together=set(),
 ),
 ]
 }}}
 However it that field was being use in a unique condition:
 {{{
 class Meta:
ordering = [ "audio_name"]
unique_together = ('audio_name')
 }}}
 you get the following error:
 {{{
 django.db.utils.OperationalError: (1170, "BLOB/TEXT column 'audio_name'
 used in key specification without a key length")
 }}}
 That is because it changes the field type before changing the unique
 condition, I think the order should be handled automatically, I had to
 change the code manually to:
 {{{
operations = [
 migrations.AlterModelOptions(
 name='s3_bucket_audios',
 options={},
 ),
 migrations.AlterUniqueTogether(
 name='s3_bucket_audios',
 unique_together=set(),
 ),
 migrations.AlterField(
 model_name='s3_bucket_audios',
 name='audio_name',
 field=models.TextField(help_text='name of the audio in the s3
 bucket'),
 ),
 ]
 }}}

 It is not a big issue anyway...
 Thanks a lot for your amazing work!!

--

-- 
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 

Re: [Django] #31183: Add a feature flag for "PostgreSQL only supports UNBOUNDED together with PRECEDING and FOLLOWING"

[Django]

#31183: Add a feature flag for "PostgreSQL only supports UNBOUNDED together with
PRECEDING and FOLLOWING"
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"227d0c7365cfd0a64d021cb9bdcf77bed2d3f170" 227d0c73]:
 {{{
 #!CommitTicketReference repository=""
 revision="227d0c7365cfd0a64d021cb9bdcf77bed2d3f170"
 Fixed #31183 -- Added a feature flag for " only supports UNBOUNDED
 together with PRECEDING and FOLLOWING".
 }}}

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

Re: [Django] #31188: Query param values got converted to lists. (was: Query param values got converted to lists when using Client from django.test)

[Django]

#31188: Query param values got converted to lists.
-+--
 Reporter:  Davit Tovmasyan  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.0
 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 felixxm):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Testing framework => HTTP handling


Comment:

 This is an expected and [https://docs.djangoproject.com/en/3.0/ref
 /request-response/#querydict-objects documented] behavior.

-- 
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/071.83d86743da61d171969151d905008959%40djangoproject.com.

Re: [Django] #31187: Detection of existing total ordering in admin changelist should take into account UniqueConstraints without conditions. (was: ChangeList._get_deterministic_ordering() should inspe

[Django]

#31187: Detection of existing total ordering in admin changelist should take 
into
account UniqueConstraints without conditions.
-+-
 Reporter:  Fabio Sangiovanni|Owner:  Fabio
 |  Sangiovanni
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  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 felixxm):

 * type:  New feature => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Agreed, we need to remember to ignore `UniqueConstraint`'s with
 `condition`'s.

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

[Django] #31188: Query param values got converted to lists when using Client from django.test

[Django]

#31188: Query param values got converted to lists when using Client from
django.test
-+
   Reporter:  Davit Tovmasyan|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  3.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  |
-+
 Steps to reproduce:

 1. Create a simple view

 {{{
 #!python
 class SomeView(View):
 def get(self, request, *args, **kwargs):
 ...
 print(request.GET)
 ...
 }}}

 2. Create URL pattern for the view as usual

 {{{
 #!python
 ...
 path('some/', SomeView.as_view()),
 ...
 }}}

 3. Do a GET request with query param using Client from `django.test`

 {{{
 #!python
 ...
 c = Client()
 c.get('some/', {'param': 1})
 ...
 }}}

 Remember this `print(request.GET)` code in CBV ?
 The value is `` and not `` as expected.

 The same output when doing this way

 {{{
 #!python
 ...
 c = Client()
 c.get('some/?param=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/056.9646b860436a26aa0d846d4b3fa72598%40djangoproject.com.

Re: [Django] #31187: ChangeList._get_deterministic_ordering() should inspect UniqueConstraint

[Django]

#31187: ChangeList._get_deterministic_ordering() should inspect UniqueConstraint
-+-
 Reporter:  Fabio Sangiovanni|Owner:  Fabio
 |  Sangiovanni
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Fabio Sangiovanni):

 * owner:  nobody => Fabio Sangiovanni
 * 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/065.37f2732ce4d8cba2173b1c6e1698cce7%40djangoproject.com.

Re: [Django] #24535: Make "manage.py migrate" atomic, i.e. rolling back any migrations on failure

[Django]

#24535: Make "manage.py migrate" atomic, i.e. rolling back any migrations on
failure
---+--
 Reporter:  Daniel Hahler  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Migrations |  Version:  1.7
 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
---+--

Comment (by Andrew Badr):

 Replying to [comment:1 Tim Graham]:
 > I'm not sure it's feasible. For example, in PostgreSQL you cannot update
 a table (data migration) and then alter the table schema in one
 transaction.

 That's not true (anymore?). I just tried it in a local shell and it
 worked. Maybe there are certain sequences of alter/updates that don't
 work. Haven't been able to find docs spelling it out.

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

[Django] #31187: ChangeList._get_deterministic_ordering() should inspect UniqueConstraint

[Django]

#31187: ChangeList._get_deterministic_ordering() should inspect UniqueConstraint
-+
   Reporter:  Fabio Sangiovanni  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 I've been fiddling with db indexes lately to improve the performance of an
 admin view.
 Eventually I found this PR https://github.com/django/django/pull/10692
 which ensures the records displayed by `ChangeList` are deterministically
 ordered.
 Among other things, the code looks for the presence of a `unique_together`
 attribute on the `Meta` class of the model to determine if the model is
 already totally ordered.

 I think that `_get_deterministic_ordering()` should check for the presence
 of `UniqueConstraints` as well, which currently aren’t considered by the
 discovery algorithm.

 I noticed the docs currently advise against using `unique_together` in
 favor of `UniqueConstraint`, suggesting the former may be deprecated in
 the future, so this fix would change that part of the code accordingly.

 I'm willing to submit a PR for this.

 Cheers,
 Fabio

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

[Django] #31186: Error updating unique field

[Django]

#31186: Error updating unique field
-+-
   Reporter:  Kailegh|  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  2.2
  Migrations |   Keywords:  migration,
   Severity:  Normal |  TextField, CharField
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi, I think I have discovered a bug, if you have a field like the
 following:
 audio_name = models.CharField(blank=False, max_length=255)
 and decide to change it to the following one:

 audio_name = models.TextField(blank=False)

 it generates the following migration code:

operations = [
 migrations.AlterModelOptions(
 name='s3_bucket_audios',
 options={},
 ),
 migrations.AlterField(
 model_name='s3_bucket_audios',
 name='audio_name',
 field=models.TextField(help_text='name of the audio in the s3
 bucket'),
 ),
 migrations.AlterUniqueTogether(
 name='s3_bucket_audios',
 unique_together=set(),
 ),
 ]

 However it that field was being use in a unique condition:
  class Meta:
ordering = [ "audio_name"]
unique_together = ('audio_name')

 you get the following error:
 django.db.utils.OperationalError: (1170, "BLOB/TEXT column 'audio_name'
 used in key specification without a key length")

 That is because it changes the field type before changing the unique
 condition, I think the order should be handled automatically, I had to
 change the code manually to:

operations = [
 migrations.AlterModelOptions(
 name='s3_bucket_audios',
 options={},
 ),
 migrations.AlterUniqueTogether(
 name='s3_bucket_audios',
 unique_together=set(),
 ),
 migrations.AlterField(
 model_name='s3_bucket_audios',
 name='audio_name',
 field=models.TextField(help_text='name of the audio in the s3
 bucket'),
 ),
 ]

 It is not a big issue anyway...
 Thanks a lot for your amazing work!!

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

Re: [Django] #23916: makemigrations does not detect/like model name case changes

[Django]

#23916: makemigrations does not detect/like model name case changes
-+-
 Reporter:  Sven Coenye  |Owner:  Adam
 |  (Chainz) Johnson
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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
-+-

Comment (by Adam (Chainz) Johnson):

 Yes, there's a pull request - see the "Pull Requests" row in the table at
 the top describing the issue.

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

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

Re: [Django] #23916: makemigrations does not detect/like model name case changes

[Django]

#23916: makemigrations does not detect/like model name case changes
-+-
 Reporter:  Sven Coenye  |Owner:  Adam
 |  (Chainz) Johnson
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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
-+-

Comment (by Daniel S):

 Pardon my ignorance, but does this recent activity mean something is being
 done about this bug? I've only just run into it (changed a model name in
 casing only and now have infinite migration detection), so I'd be
 interested in finding a workaround. Replying to [comment:8 felixxm]:

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

Re: [Django] #31185: fields.E310-E311 should take into account UniqueConstraints without conditions. (was: UniqueConstraint rises fields.E310 error because of issue with no backward compatibility with

[Django]

#31185: fields.E310-E311 should take into account UniqueConstraints without
conditions.
-+-
 Reporter:  Pavel Garkin |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  UniqueConstraint | Triage Stage:  Accepted
  unique_together E310 E311  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * keywords:  UniqueConstraint unique_together E310 => UniqueConstraint
 unique_together E310 E311
 * version:  2.2 => master


Comment:

 Agreed, both checks should take into `UniqueConstraint`'s without
 `condition`'s.

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

Re: [Django] #31185: UniqueConstraint rises fields.E310 error because of issue with no backward compatibility with unique_together

[Django]

#31185: UniqueConstraint rises fields.E310 error because of issue with no 
backward
compatibility with unique_together
-+-
 Reporter:  Pavel|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  2.2
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  UniqueConstraint | Triage Stage:  Accepted
  unique_together E310   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * keywords:  UniqueConstraint, unique_together => UniqueConstraint
 unique_together E310
 * component:  Migrations => Core (System checks)
 * stage:  Unreviewed => Accepted


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

Re: [Django] #31180: Deprecate default_app_config. (was: Deprecate default_app_config)

[Django]

#31180: Deprecate default_app_config.
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  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 felixxm):

 * component:  Core (Serialization) => Core (Other)
 * stage:  Unreviewed => Accepted


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

Re: [Django] #31117: ThreadTests fails due to double test_ prefix caused by TestDbCreationTests.

[Django]

#31117: ThreadTests fails due to double test_ prefix caused by 
TestDbCreationTests.
-+-
 Reporter:  Matthijs Kooijman|Owner:  Matthijs
 |  Kooijman
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"2a2ea4ee18fdcf2c95bf6435bc63b74623e3085b" 2a2ea4ee]:
 {{{
 #!CommitTicketReference repository=""
 revision="2a2ea4ee18fdcf2c95bf6435bc63b74623e3085b"
 Refs #31117 -- Made various tests properly handle unexpected databases
 aliases.

 - Used selected "databases" instead of django.db.connections.
 - Made routers in tests.migrations skip migrations on unexpected
   databases.
 - Added DiscoverRunnerGetDatabasesTests.assertSkippedDatabases() hook
   which properly asserts messages about skipped databases.
 }}}

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

[Django] #31185: UniqueConstraint rises fields.E310 error because of issue with no backward compatibility with unique_together

[Django]

#31185: UniqueConstraint rises fields.E310 error because of issue with no 
backward
compatibility with unique_together
-+-
   Reporter:  Pavel  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  2.2
  Migrations |   Keywords:  UniqueConstraint,
   Severity:  Normal |  unique_together
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,

 I'm trying to create migration with this kind of model.

 {{{
 class AppUsers(models.Model):
 name = models.CharField(...)
 uid = models.CharField(...)
 source = models.ForeignKey(...)

 class Meta:
 constraints = [models.UniqueConstraint(fields=['uid', 'source'],
 name='appusers_uniqueness')]
 }}}

 When I start ''makemigrations'' command in manage.py I've faced
 fields.E310 [https://docs.djangoproject.com/en/2.2/ref/checks/#related-
 fields] error

 It says that I should add unique_together field in Meta options:
 **app_name.AppUsers.field: (fields.E310) No subset of the fields 'uid',
 'source' on model 'AppUsers' is unique.
 HINT: Add unique=True on any of those fields or add at least a subset of
 them to a unique_together constraint.**

 If I change Meta options to unique_together constraint migration passes
 with no errors.


 {{{
 class AppUsers(models.Model):
 name = models.CharField(...)
 uid = models.CharField(...)
 source = models.ForeignKey(...)

 class Meta:
 unique_together = [['uid', 'source']]
 }}}


 As mentioned in docs
 [https://docs.djangoproject.com/en/2.2/ref/models/options/#unique-
 together] ''unique_together'' may be deprecated in the future. So I think
 nobody wants to face this issue when this will be deprecated :)

 Thanks,
 Pavel

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

Re: [Django] #31117: ThreadTests fails due to double test_ prefix caused by TestDbCreationTests.

[Django]

#31117: ThreadTests fails due to double test_ prefix caused by 
TestDbCreationTests.
-+-
 Reporter:  Matthijs Kooijman|Owner:  Matthijs
 |  Kooijman
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"f34be5294d8bd9530079525fb56e661816a63e20" f34be52]:
 {{{
 #!CommitTicketReference repository=""
 revision="f34be5294d8bd9530079525fb56e661816a63e20"
 Refs #31117 -- Moved get_connection_copy() test hook to a module level.
 }}}

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

Re: [Django] #31117: ThreadTests fails due to double test_ prefix caused by TestDbCreationTests.

[Django]

#31117: ThreadTests fails due to double test_ prefix caused by 
TestDbCreationTests.
-+-
 Reporter:  Matthijs Kooijman|Owner:  Matthijs
 |  Kooijman
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"b64b1b2e1a17da3fd702cde4bfc2b6e0689b4348" b64b1b2e]:
 {{{
 #!CommitTicketReference repository=""
 revision="b64b1b2e1a17da3fd702cde4bfc2b6e0689b4348"
 Fixed #31117 -- Isolated backends.base.test_creation.TestDbCreationTests.

 Previously, this test could modify global state by changing
 connection.settings_dict. This dict is a reference to the same dict as
 django.db.connections.databases['default'], which is thus also changed.
 The cleanup of this test would replace connection.settings_dic` with a
 saved copy, which would leave the dict itself modified.

 Additionally, create_test_db() would also modify these same dicts, as
 well as settings.databases['default']['NAME'] by adding a "test_"
 prefix, which is what can cause problems later.

 This patch:
  - makes a complete copy of the connection and work on that, to improve
isolation.
  - calls destroy_test_db() to let that code clean up anything done by
create_test_db().
 }}}

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

Re: [Django] #31142: MakeValid() polygon to multi-polygon raises error in GEOS C function "GEOSGetNumInteriorRings_r".

[Django]

#31142: MakeValid() polygon to multi-polygon raises error in GEOS C function
"GEOSGetNumInteriorRings_r".
-+-
 Reporter:  Eran Keydar  |Owner:  Sergey Fedoseev
 Type:  Bug  |   Status:  closed
Component:  GIS  |  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
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"a920c0b852371d7cae4aacd5c67b62fe3c4e2d55" a920c0b8]:
 {{{
 #!CommitTicketReference repository=""
 revision="a920c0b852371d7cae4aacd5c67b62fe3c4e2d55"
 Fixed #31142 -- Fixed MakeValid.output_field when geometry type is
 changed.

 Regression in 2ef4b4795e29be8c33a6de9cc0c05b59025d13a5.
 }}}

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

Re: [Django] #28296: Add support for aggregation through subqueries

[Django]

#28296: Add support for aggregation through subqueries
-+-
 Reporter:  László Károlyi   |Owner:  B
 |  Martsberger
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1


Comment:

 Marking as "needs improvement" due to Simon's comments.

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