Re: [Django] #23740: Cannot drop unique_together constraint on a single field with its own unique=True constraint

[Django]

#23740: Cannot drop unique_together constraint on a single field with its own
unique=True constraint
-+-
 Reporter:  Mihail Milushev  |Owner:  David Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  unique_together  | 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


-- 
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/01070180f9f4e189-bd816129-e769-4bff-b2ba-4c7a78135f3e-00%40eu-central-1.amazonses.com.

Re: [Django] #33723: DEBUG_PROPAGATE_EXCEPTIONS is not honored by runserver

[Django]

#33723: DEBUG_PROPAGATE_EXCEPTIONS is not honored by runserver
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * status:  new => closed
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * resolution:   => needsinfo


Comment:

 Hey Daniel. Interesting idea. I'm not sure of the benefit… maybe it's
 worth it, but I've always found setting a breakpoint in an erroring view
 to be sufficient. 🤔

 Can I ask you to follow-up on the DevelopersMailingList to see what others
 think, and to canvas suggestions on the implementation (as it seems a bit
 first pass).

 Just as a question: what happens with the `handle_error()` under normal
 usage if I have `DEBUG_PROPAGATE_EXCEPTIONS` set? (It seems like a
 probable can of worms…) 🤔

-- 
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/01070180f9e1bfdf-857f4b53-c131-45f4-8fff-6c32f6056609-00%40eu-central-1.amazonses.com.

Re: [Django] #22078: views.Feed methods cannot be decorated

[Django]

#22078: views.Feed methods cannot be decorated
-+-
 Reporter:  Germano Gabbianelli  |Owner:  Marcelo
 |  Galigniana
 Type:  Bug  |   Status:  assigned
Component:  contrib.syndication  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * needs_tests:  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/01070180f9cefe25-94046fe6-5828-453e-9984-1ca641053a4e-00%40eu-central-1.amazonses.com.

Re: [Django] #33741: Transaction Management inside PROCEDURE

[Django]

#33741: Transaction Management inside PROCEDURE
-+-
 Reporter:  Victor Vieux |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  database procedure   | Triage Stage:
  transaction|  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:   => invalid


Old description:

> Hello,
>
> I have a PROCEDURE that uses [Transaction
> Management](https://www.postgresql.org/docs/current/plpgsql-
> transactions.html) from postgres (meaning there are COMMITs inside the
> procedure itself)
> It runs fine in postgres, but when trying to invoke it from django either
> via
>
> {{{
> with connection.cursor() as c:
> c.execute(...)
> }}}
>
> or
>
> {{{
> cursor.callproc
> }}}
>
> I get the following error:
>
> {{{
> django.db.utils.InternalError: invalid transaction termination
> CONTEXT:  PL/pgSQL function xxx() line xx at COMMIT
> }}}
>
> I think that's because when executing raw queries with execute, they are
> run inside a transaction?
> Is there a way to bypass this?
>
> Thanks.

New description:

 Hello,

 I have a PROCEDURE that uses [https://www.postgresql.org/docs/current
 /plpgsql-transactions.html Transaction Management] from postgres (meaning
 there are COMMITs inside the procedure itself)
 It runs fine in postgres, but when trying to invoke it from django either
 via

 {{{
 with connection.cursor() as c:
 c.execute(...)
 }}}

 or

 {{{
 cursor.callproc
 }}}

 I get the following error:

 {{{
 django.db.utils.InternalError: invalid transaction termination
 CONTEXT:  PL/pgSQL function xxx() line xx at COMMIT
 }}}

 I think that's because when executing raw queries with execute, they are
 run inside a transaction?
 Is there a way to bypass this?

 Thanks.

--

Comment:

 Please see TicketClosingReasons/UseSupportChannels for places to ask usage
 questions.

-- 
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/01070180f8bab137-b65b8e8d-4b7b-411b-8f2e-e6e9ed8973e0-00%40eu-central-1.amazonses.com.

[Django] #33741: Transaction Management inside PROCEDURE

[Django]

#33741: Transaction Management inside PROCEDURE
-+-
   Reporter:  vieux  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.0
  layer (models, ORM)|   Keywords:  database procedure
   Severity:  Normal |  transaction
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,

 I have a PROCEDURE that uses [Transaction
 Management](https://www.postgresql.org/docs/current/plpgsql-
 transactions.html) from postgres (meaning there are COMMITs inside the
 procedure itself)
 It runs fine in postgres, but when trying to invoke it from django either
 via

 {{{
 with connection.cursor() as c:
 c.execute(...)
 }}}

 or

 {{{
 cursor.callproc
 }}}

 I get the following error:

 {{{
 django.db.utils.InternalError: invalid transaction termination
 CONTEXT:  PL/pgSQL function xxx() line xx at COMMIT
 }}}

 I think that's because when executing raw queries with execute, they are
 run inside a transaction?
 Is there a way to bypass this?

 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/01070180f84adca6-3d915fe3-6413-480b-afa0-e76133dcec5d-00%40eu-central-1.amazonses.com.

Re: [Django] #33733: inspect.signature() returns incorrect signature on manager methods.

[Django]

#33733: inspect.signature() returns incorrect signature on manager methods.
-+-
 Reporter:  Shiva Kumar  |Owner:  Shiva
 Type:   |  Kumar
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (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):

 * needs_tests:  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/01070180f7479ebd-b6df43f2-e863-4bd5-9165-36e28bddf36c-00%40eu-central-1.amazonses.com.

Re: [Django] #22078: views.Feed methods cannot be decorated

[Django]

#22078: views.Feed methods cannot be decorated
-+-
 Reporter:  Germano Gabbianelli  |Owner:  Marcelo
 |  Galigniana
 Type:  Bug  |   Status:  assigned
Component:  contrib.syndication  |  Version:  1.6
 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 Marcelo Galigniana):

 * 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/01070180f6770309-58b4b40b-df4e-460a-b405-56f15b0e5632-00%40eu-central-1.amazonses.com.

Re: [Django] #23740: Cannot drop unique_together constraint on a single field with its own unique=True constraint

[Django]

#23740: Cannot drop unique_together constraint on a single field with its own
unique=True constraint
-+-
 Reporter:  Mihail Milushev  |Owner:  David Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  unique_together  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * cc: David Wobrock (added)
 * owner:  nobody => David Wobrock
 * has_patch:  0 => 1
 * status:  new => assigned


Comment:

 Hey there,

 It's indeed still (mostly) relevant.
 I've tried to tackle the issue, here is a first draft of the
 [https://github.com/django/django/pull/15732 PR].

 "Mostly" because I couldn't reproduce the part that Matt is describing
 about adding a `unique_together`:
 > Another way this manifests itself is to perform the following steps, in
 separate migrations:
 >
 > * create a model
 > * add unique=True to one if its fields
 > * add a unique_together constraint for that same field
 >
 > This results in two identical calls to _create_unique_sql, leading to a
 'relation "foo_bar_name_1e64ed8ec8cfa1c7_uniq" already exists' error.

 For the rest, removing the `unique_together` on a PK field and on a
 `unique=True` field should work now, when we base the constraint checking
 on how the `unique_together` names are generated by default.
 However, this will break dropping such a constraint if it has been renamed
 manually. I think this should be fine, as the name is generated by Django
 and never really exposed - so I guess it's okay to regard this name as
 internals of Django, and we can rely on it.

 Feel free to tell me what you think of the 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/01070180f6644637-c401837f-b8f9-4e89-8116-9fdb4c1522e7-00%40eu-central-1.amazonses.com.

Re: [Django] #33733: inspect.signature() returns incorrect signature on manager methods.

[Django]

#33733: inspect.signature() returns incorrect signature on manager methods.
-+-
 Reporter:  Shiva Kumar  |Owner:  Shiva
 Type:   |  Kumar
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (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 Shiva Kumar):

 * has_patch:  0 => 1


Comment:

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

-- 
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/01070180f659e954-bbc59ac3-543f-4c68-a442-b8c68016cdc6-00%40eu-central-1.amazonses.com.

Re: [Django] #33739: Migration on the test database doesn't work

[Django]

#33739: Migration on the test database doesn't work
---+--
 Reporter:  ThalusA|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  4.0
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  postgres unittest  | 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):

 > My project is quite complex so I can give you its structure and database
 configuration

 Thanks, unfortunately it's not enough to confirm a bug in Django. Your
 issue may be related with lack of support for database schemas, see #6148,
 but it's hard to say without a reproducible scenario. Please reopen the
 ticket if you can debug your issue and provide a minimal project that
 reproduces 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/01070180f5dba3c8-710fe5d6-d07a-4a22-b839-e13aacf899d3-00%40eu-central-1.amazonses.com.

Re: [Django] #33739: Migration on the test database doesn't work

[Django]

#33739: Migration on the test database doesn't work
---+--
 Reporter:  ThalusA|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  4.0
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  postgres unittest  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by ThalusA):

 Replying to [comment:1 Mariusz Felisiak]:
 > Can you provide a sample project with your database configuration?

 My project is quite complex so I can give you its structure and database
 configuration


 {{{
 .
 ├── aact
 │   ├── apps.py
 │   ├── __init__.py
 │   ├── management
 │   │   ├── commands
 │   │   │   ├── extract_transform_load.py
 │   │   │   └── __init__.py
 │   │   └── __init__.py
 │   ├── models
 │   │   ├── brief_summary.py
 │   │   ├── calculated_values.py
 │   │   ├── central_contact.py
 │   │   ├── condition.py
 │   │   ├── contact.py
 │   │   ├── detailed_description.py
 │   │   ├── eligibility.py
 │   │   ├── facility.py
 │   │   ├── __init__.py
 │   │   ├── intervention.py
 │   │   ├── investigator.py
 │   │   ├── sponsor.py
 │   │   └── trial.py
 │   └── transformer
 │   ├── age.py
 │   ├── calculated_properties.py
 │   ├── fields.py
 │   ├── gender.py
 │   ├── __init__.py
 │   ├── links.py
 │   ├── phase.py
 │   ├── recruiting_status.py
 │   └── trial.py
 ├── Aptfile
 ├── back
 │   ├── __init__.py
 │   ├── settings.py
 │   ├── urls.py
 │   └── wsgi.py
 ├── docker-compose.yml
 ├── launch.sh
 ├── manage.py
 ├── medical
 │   ├── admin.py
 │   ├── apps.py
 │   ├── fixtures
 │   │   ├── alterations.json
 │   │   ├── biomarkers.json
 │   │   ├── histologies.json
 │   │   ├── __init__.py
 │   │   ├── mechanisms_of_action.json
 │   │   ├── molecule_types.json
 │   │   ├── organs.json
 │   │   ├── routes_of_administrationorgans.json
 │   │   ├── situations.json
 │   │   └── specialities.json
 │   ├── __init__.py
 │   ├── managers
 │   │   ├── __init__.py
 │   │   └── medical_alias_manager.py
 │   ├── migrations
 │   │   ├── 0001_initial.py
 │   │   └── __init__.py
 │   ├── models
 │   │   ├── alteration.py
 │   │   ├── biomarker.py
 │   │   ├── histology.py
 │   │   ├── __init__.py
 │   │   ├── mechanism_of_action.py
 │   │   ├── molecule_type.py
 │   │   ├── organ.py
 │   │   ├── route_of_administration.py
 │   │   ├── situation.py
 │   │   └── speciality.py
 │   ├── serializers
 │   │   ├── alteration.py
 │   │   ├── biomarker.py
 │   │   ├── histology.py
 │   │   ├── __init__.py
 │   │   ├── mechanism_of_action.py
 │   │   ├── molecule_type.py
 │   │   ├── organ.py
 │   │   ├── route_of_administration.py
 │   │   ├── situation.py
 │   │   └── speciality.py
 │   ├── tests.py
 │   ├── translation.py
 │   ├── urls.py
 │   └── views
 │   ├── alteration.py
 │   ├── biomarker.py
 │   ├── histology.py
 │   ├── __init__.py
 │   ├── mechanism_of_action.py
 │   ├── molecule_type.py
 │   ├── organ.py
 │   ├── route_of_administration.py
 │   ├── situation.py
 │   └── speciality.py
 ├── organization
 │   ├── admin.py
 │   ├── apps.py
 │   ├── enums
 │   │   ├── __init__.py
 │   │   ├── recruiting_status.py
 │   │   └── slots.py
 │   ├── __init__.py
 │   ├── migrations
 │   │   ├── 0001_initial.py
 │   │   └── __init__.py
 │   ├── models
 │   │   ├── facility.py
 │   │   ├── __init__.py
 │   │   └── sponsor.py
 │   ├── serializers
 │   │   ├── facility.py
 │   │   ├── __init__.py
 │   │   └── sponsor.py
 │   ├── tests.py
 │   ├── urls.py
 │   └── views
 │   ├── facility.py
 │   ├── __init__.py
 │   └── sponsor.py
 ├── patient
 │   ├── admin.py
 │   ├── apps.py
 │   ├── __init__.py
 │   ├── migrations
 │   │   ├── 0001_initial.py
 │   │   ├── 0002_initial.py
 │   │   └── __init__.py
 │   ├── models
 │   │   ├── __init__.py
 │   │   ├── patient_form.py
 │   │   └── pre_screening_decision.py
 │   ├── serializers
 │   │   ├── __init__.py
 │   │   ├── patient_form.py
 │   │   └── pre_screening_decision.py
 │   ├── tests.py
 │   ├── urls.py
 │   └── views
 │   ├── __init__.py
 │   └── patient_form.py
 ├── Procfile
 ├── README.md
 ├── requirements.txt
 ├── resources
 │   ├── apps.py
 │   ├── fixtures
 │   │   ├── cancer_synonyms.json
 │   │   ├── cities.json
 │   │   ├── facilities_aliases.json
 │   │   ├── line_synonyms.json
 │   │   ├── organs_specialities.json
 │   │   ├── prioritized_terms.json
 │   │   └── standard_facilities.json
 │   ├── __init__.py
 │   ├── managers
 │   │   ├── alias_manager.py
 │   │   ├── __init__.py
 │   │   └── prio

Re: [Django] #33733: inspect.signature() returns incorrect signature on manager methods. (was: Incorrect signature information when using inspect.signature on queryset methods)

[Django]

#33733: inspect.signature() returns incorrect signature on manager methods.
-+-
 Reporter:  Shiva Kumar  |Owner:  Shiva
 Type:   |  Kumar
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (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 Mariusz Felisiak):

 * status:  new => assigned
 * easy:  1 => 0
 * owner:  nobody => Shiva Kumar
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Tentatively 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/01070180f5a02f21-99a31fe3-d0f7-411e-81ac-73b99202d5d0-00%40eu-central-1.amazonses.com.

Re: [Django] #33739: Migration on the test database doesn't work

[Django]

#33739: Migration on the test database doesn't work
---+--
 Reporter:  ThalusA|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  4.0
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  postgres unittest  | 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):

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


-- 
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/01070180f58e8541-d3504f5f-8119-4b33-9378-2383a3a4b7bb-00%40eu-central-1.amazonses.com.

Re: [Django] #33565: makemessages command skips the nl-nl-x-informal folder

[Django]

#33565: makemessages command skips the nl-nl-x-informal folder
-+-
 Reporter:  Ronnie van den   |Owner:  Ronnie
  Crommenacker   |  van den Crommenacker
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  3.2
  Internationalization   |
 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 Carlton Gibson):

 * needs_tests:  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/01070180f585cfef-66b38541-181f-42a1-af59-cf7bd88804d2-00%40eu-central-1.amazonses.com.

Re: [Django] #33740: Flatpages should allow multiple pages per site when registration_required is different

[Django]

#33740: Flatpages should allow multiple pages per site when 
registration_required
is different
---+--
 Reporter:  Peter Tillema  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.flatpages  |  Version:  4.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 Carlton Gibson):

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


Comment:

 Hi Peter.

 This kind of discussion is best targeted to the DevelopersMailingList. I
 suggest explaining your issue fully in order to encourage a response. If
 there's an agreement then we can reopen the ticket here. (My initial
 concern would be complicating the page lookup by factors such as the
 current user — some suggestion as to what that change might look like
 would be useful to help make an assessment.)

 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/01070180f5753b35-16739e47-4d58-42bb-af7a-cec7f04c9a68-00%40eu-central-1.amazonses.com.

Re: [Django] #33739: Migration on the test database doesn't work

[Django]

#33739: Migration on the test database doesn't work
---+--
 Reporter:  ThalusA|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords:  postgres unittest  | 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):

 * severity:  Release blocker => Normal


Comment:

 Can you provide a sample project with your database configuration?

-- 
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/01070180f5684662-57f6c2f8-4b59-471d-956c-acd36c163879-00%40eu-central-1.amazonses.com.

[Django] #33740: Flatpages should allow multiple pages per site when registration_required is different

[Django]

#33740: Flatpages should allow multiple pages per site when 
registration_required
is different
-+
   Reporter:  Peter Tillema  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.flatpages  |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  |
-+
 It might happen that there are 2 flatpages with the same URL and site, but
 one is for guest users and the other for logged in users. Currently the
 form throws an error, but in my opinion this could be very useful. If I
 have some time I might create a PR, but I'm curious to what other people
 think!

-- 
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/01070180f564e417-1409fec1-a0f1-4010-bac1-fe6890e2c80f-00%40eu-central-1.amazonses.com.

[Django] #33739: Migration on the test database doesn't work

[Django]

#33739: Migration on the test database doesn't work
-+-
   Reporter:  ThalusA|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing|Version:  4.0
  framework  |
   Severity:  Release|   Keywords:  postgres unittest
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 "Any migrations will also be applied in order to keep it up to date."
 https://docs.djangoproject.com/en/4.0/topics/testing/overview/#the-test-
 database-1

 The statement above is false, I will explain why.
 First of all, here are all my versions:
 - PostgreSQL 14.2 (with PostGIS 3.2)
 - Django 4.0.4

 I'm using unitary tests for my app using Django's TestCase. It is detected
 nicely, everything works according to plan except for one thing.

 When I run `./manage.py test`, Django creates another database called
 `test_administrator` because my database name is `administrator` but in
 this database, there is only the table for PostGIS data, and not all the
 models from `administrator` which are created using `./manage.py migrate`.

 My temporary fix is to run `./manage.py migrate` on the database
 `test_administrator` and run the command `./manage.py test` with the flag
 to keep the database because it deletes it each time I run it, elsewhere.

 It would be lovely to have a fix on this 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/01070180f55fb3b1-8ad2c608-50a7-4f8f-888d-f3376cbdbfc0-00%40eu-central-1.amazonses.com.

Re: [Django] #33738: ASGI http.disconnect not handled on requests with body.

[Django]

#33738: ASGI http.disconnect not handled on requests with body.
+
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  HTTP handling   |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  ASGI| 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):

 * type:  New feature => Bug


-- 
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/01070180f52fe245-10e00506-82f3-41d1-83cf-f8a86e8ddd00-00%40eu-central-1.amazonses.com.

Re: [Django] #33738: ASGI http.disconnect not handled on requests with body.

[Django]

#33738: ASGI http.disconnect not handled on requests with body.
+
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  HTTP handling   |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  ASGI| Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Carlton Gibson):

 > Don't you think it's a bug? 🤔

 I had it down as such, but it's never worked, and once I started thinking
 about the **fix** I thought it's probably a non-minor adjustment so...
 (But happy if you want to re-classify :)

-- 
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/01070180f52eeb05-20fffb4e-77ed-419b-9799-913a0dcc84cc-00%40eu-central-1.amazonses.com.

Re: [Django] #33738: ASGI http.disconnect not handled on requests with body.

[Django]

#33738: ASGI http.disconnect not handled on requests with body.
+
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  HTTP handling   |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  ASGI| 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):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks! Don't you think it's a bug? 🤔

-- 
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/01070180f5200c1e-577a477e-569b-4000-ba0d-8df5d8cf8ffd-00%40eu-central-1.amazonses.com.

Re: [Django] #33724: Changing from list to set in `exclude` raises errors, and is not documented.

[Django]

#33724: Changing from list to set in `exclude` raises errors, and is not
documented.
-+-
 Reporter:  אורי |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"3d4bab28de16c56e7fcd94a26a570f5bc730e691" 3d4bab2]:
 {{{
 #!CommitTicketReference repository=""
 revision="3d4bab28de16c56e7fcd94a26a570f5bc730e691"
 [4.1.x] Fixed #33724 -- Doc'd exclude argument changes in model
 validation.

 Thanks אורי for the report.

 Follow up to 1ea7e3157d1f9b4db71e768d75ea57e47dbd49f9.
 Backport of 90aabd730a2a434c227faf8a927b0e2ccd67e291 from main
 }}}

-- 
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/01070180f518001b-dcccf38c-8907-4edd-a652-1cd49902b55a-00%40eu-central-1.amazonses.com.

Re: [Django] #33724: Changing from list to set in `exclude` raises errors, and is not documented.

[Django]

#33724: Changing from list to set in `exclude` raises errors, and is not
documented.
-+-
 Reporter:  אורי |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 GitHub ):

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


Comment:

 In [changeset:"90aabd730a2a434c227faf8a927b0e2ccd67e291" 90aabd73]:
 {{{
 #!CommitTicketReference repository=""
 revision="90aabd730a2a434c227faf8a927b0e2ccd67e291"
 Fixed #33724 -- Doc'd exclude argument changes in model validation.

 Thanks אורי for the report.

 Follow up to 1ea7e3157d1f9b4db71e768d75ea57e47dbd49f9.
 }}}

-- 
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/01070180f517a53a-793dccd4-b451-4c0b-9f23-a3718f3d164d-00%40eu-central-1.amazonses.com.

Re: [Django] #32234: inspectdb should inform about composite keys.

[Django]

#32234: inspectdb should inform about composite keys.
-+-
 Reporter:  Damien   |Owner:  Anvesh
 Type:   |  Mishra
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  3.1
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_docs:  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/01070180f5156f0b-c57c3e22-60f5-49c3-ab46-e31f7e68501c-00%40eu-central-1.amazonses.com.

[Django] #33738: ASGI http.disconnect not handled on requests with body.

[Django]

#33738: ASGI http.disconnect not handled on requests with body.
--+
   Reporter:  Carlton Gibson  |  Owner:  nobody
   Type:  New feature | Status:  new
  Component:  HTTP handling   |Version:  4.0
   Severity:  Normal  |   Keywords:  ASGI
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 Noticed whilst reviewing [https://github.com/django/django/pull/15704 PR
 15704] for #33699, we're not handling the ASGI `http.disconnect` message
 correctly. Since it's only dealt with whilst reading the request body,
 `http.disconnect` is not processed on a request that includes a body.

 
https://github.com/django/django/blob/241fe59b74bb6031fa644f3ad55e6ad6a9187510/django/core/handlers/asgi.py#L189

 {{{
 async def read_body(self, receive):
 """Reads an HTTP body from an ASGI connection."""
 # Use the tempfile that auto rolls-over to a disk file as it fills
 up.
 body_file = tempfile.SpooledTemporaryFile(
 max_size=settings.FILE_UPLOAD_MAX_MEMORY_SIZE, mode="w+b"
 )
 while True:
 message = await receive()
 if message["type"] == "http.disconnect":# This is the only
 place `http.disconnect` is handled.
 body_file.close()
 # Early client disconnect.
 raise RequestAborted()
 # Add a body chunk from the message, if provided.
 if "body" in message:
 body_file.write(message["body"])
 # Quit out if that's the end.
 if not message.get("more_body", False):
 break
 body_file.seek(0)
 return body_file
 }}}

 `http.disconnect` is designed for long-polling — so we imagine a client
 opening a request, with a request body, and then disconnecting before the
 response is generated.

 The protocol server (Daphne/uvicorn/...) will send the `http.diconnect`
 message, but it's not handled.

 This test fails on main (at 9f5548952906c6ea97200c016734b4f519520a64 — 4.2
 pre-alpha)

 {{{
 diff --git a/tests/asgi/tests.py b/tests/asgi/tests.py
 index ef7b55724e..a68ca8a473 100644
 --- a/tests/asgi/tests.py
 +++ b/tests/asgi/tests.py
 @@ -188,6 +188,18 @@ class ASGITest(SimpleTestCase):
  with self.assertRaises(asyncio.TimeoutError):
  await communicator.receive_output()

 +async def test_disconnect_with_body(self):
 +application = get_asgi_application()
 +scope = self.async_request_factory._base_scope(path="/")
 +communicator = ApplicationCommunicator(application, scope)
 +await communicator.send_input({
 +"type": "http.request",
 +"body": b"some body",
 +})
 +await communicator.send_input({"type": "http.disconnect"})
 +with self.assertRaises(asyncio.TimeoutError):
 +await communicator.receive_output()
 +
  async def test_wrong_connection_type(self):
  application = get_asgi_application()
  scope = self.async_request_factory._base_scope(path="/",
 type="other")
 }}}


 To handle this correctly it looks like we'd need something like Channel's
 
[https://github.com/django/channels/blob/ae60a7d86f3655a1cc35cd9198e61fe5dcc5d1a1/channels/utils.py#L32
 `await_many_dispatch()`] to keep receiving from the input queue whilst
 dispatching the request. 🤔

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180f50c3d9f-321e8423-08c6-4b6b-8a53-ea07aa1871e1-00%40eu-central-1.amazonses.com.