Re: [Django] #35082: AsyncRequestFactory doesn't pass REMOTE_ADDR when set

2024-01-02 Thread Django
#35082: AsyncRequestFactory doesn't pass REMOTE_ADDR when set
---+--
 Reporter:  alex   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  5.0
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

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


Comment:

 According to the [https://asgi.readthedocs.io/en/latest/specs/main.html
 ASGI spec], `REMOTE_ADDR` is based on the `client` in the connection
 scope, so you can override it with:
 {{{#!python
 >>> afactory = AsyncRequestFactory(client=("127.0.1.1", "88"))
 >>> request = afactory.get("/somewhere")
 >>> request.META["REMOTE_ADDR"]
 "127.0.1.1"
 }}}

 If you're having trouble understanding how Django works, see
 TicketClosingReasons/UseSupportChannels for ways to get help.

-- 
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/0107018ccd9d901d-97fb636a-7744-456d-ab7e-0fb12026fe3e-00%40eu-central-1.amazonses.com.


Re: [Django] #35079: Meta indexes/constraints with OpClass on expressions crash.

2024-01-02 Thread Django
#35079: Meta indexes/constraints with OpClass on expressions crash.
-+--
 Reporter:  Andra Antariksa  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  migration| Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Andra Antariksa):

 Thanks for your response. It fixes my problem, too bad I didn't notice
 that thing.

-- 
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/0107018ccd1c2547-908e6c01-08bc-4dd9-ac13-a3f507932e2d-00%40eu-central-1.amazonses.com.


Re: [Django] #35082: AsyncRequestFactory doesn't pass REMOTE_ADDR when set

2024-01-02 Thread Django
#35082: AsyncRequestFactory doesn't pass REMOTE_ADDR when set
---+--
 Reporter:  alex   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  5.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by alex):

 Workaround: often it is enough to use RequestFactory even it is incorrect

-- 
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/0107018ccd17f08c-93453cfa-3447-45ec-8431-949a370c9aba-00%40eu-central-1.amazonses.com.


[Django] #35082: AsyncRequestFactory doesn't pass REMOTE_ADDR when set

2024-01-02 Thread Django
#35082: AsyncRequestFactory doesn't pass REMOTE_ADDR when set
-+
   Reporter:  alex   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  5.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  |
-+
 I can describe this bug easily with an example:


 {{{
 from django.test import RequestFactory, AsyncRequestFactory
 factory = RequestFactory()
 afactory = AsyncRequestFactory()
 request = factory.get("/customer/details", REMOTE_ADDR="127.0.1.1")
 assert request.META["REMOTE_ADDR"] == "127.0.1.1"
 request = afactory.get("/customer/details", REMOTE_ADDR="127.0.1.1")
 # will fail
 assert request.META["REMOTE_ADDR"] == "127.0.1.1"
 }}}

 I think there are some other variables also affected. I tested it only
 with django 5.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/0107018ccd175c9c-c8b5a8e6-cf15-4fec-8031-2ca10ee8daac-00%40eu-central-1.amazonses.com.


Re: [Django] #14831: Django Template Style Guide

2024-01-02 Thread Django
#14831: Django Template Style Guide
-+-
 Reporter:  Simon Meers  |Owner:  Ryan
 |  Cheley
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  template, style, | Triage Stage:  Accepted
  format |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Natalia Bidart):

 Hello Ryan, thanks for going thru these old tickets to try to make a
 decision about them.

 Given that the ticket is already accepted, I would suggest to push this
 ticket forward by pursuing the 3 tasks detailed in the first comment (with
 the only caveat that the Django Forum would be preferred instead of the
 Django Developers list), which I agree are the first steps before making
 any docs changes:

 1. An overview of the various styles found in the current templates,
 2. A draft patch based on whatever the most common/best practice seems to
 be,
 3. A thread on the Django Forum to let folks debate the options.

 Looking forward to your forum post!

-- 
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/0107018ccbe4f63e-f7c0c310-82d2-4544-b309-4e7f8c58ca0d-00%40eu-central-1.amazonses.com.


Re: [Django] #16752: Multi-db without a 'default' database

2024-01-02 Thread Django
#16752: Multi-db without a 'default' database
-+-
 Reporter:  Jeremy Dunck |Owner:  Ryan
 |  Cheley
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Natalia Bidart):

 Hey Ryan, while I agree that the docs have changed/improved, I think this
 ticket is about doing the cleanup to actually remove the need to declare a
 `default` database (which should also avoid the need to define a `default`
 key, even if empty, in the `DATABASES` dict).

 So from my understanding, this ticket is still valid and needs addressing.

-- 
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/0107018ccbb12d97-85c7d3f5-c823-4dbf-8d66-3ca263271de2-00%40eu-central-1.amazonses.com.


Re: [Django] #35079: Meta indexes/constraints with OpClass on expressions crash.

2024-01-02 Thread Django
#35079: Meta indexes/constraints with OpClass on expressions crash.
-+--
 Reporter:  Andra Antariksa  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  migration| 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:   => duplicate
 * stage:  Accepted => Unreviewed


Comment:

 Ahh, right 🤦  Duplicate of #32770.

-- 
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/0107018ccba1f135-d8c2de74-1e7f-4d37-a792-2446d04b7bc2-00%40eu-central-1.amazonses.com.


Re: [Django] #35079: Meta indexes/constraints with OpClass on expressions crash.

2024-01-02 Thread Django
#35079: Meta indexes/constraints with OpClass on expressions crash.
-+
 Reporter:  Andra Antariksa  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  migration| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Hannes Ljungberg):

 Pretty sure that this is caused by not having `django.contrib.postgres` in
 `INSTALLED_APPS` as documented at
 https://docs.djangoproject.com/en/5.0/ref/contrib/postgres/indexes
 /#opclass-expressions.

-- 
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/0107018ccb914709-7b81b884-ac2c-4ac2-89c8-7fa310ea07df-00%40eu-central-1.amazonses.com.


Re: [Django] #35081: Bug when customized login issue

2024-01-02 Thread Django
#35081: Bug when customized login issue
+--
 Reporter:  Ibrahim Luqman  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Uncategorized   |  Version:  5.0
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  login, cbv  | 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:   => invalid


Comment:

 Please don't use Trac as a support channel. Closing per
 TicketClosingReasons/UseSupportChannels.

-- 
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/0107018ccad05e35-6f6a3035-54cd-4d78-9eea-b416d856d253-00%40eu-central-1.amazonses.com.


Re: [Django] #35081: Bug when customized login issue

2024-01-02 Thread Django
#35081: Bug when customized login issue
+--
 Reporter:  Ibrahim Luqman  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Uncategorized   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  login, cbv  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Ibrahim Luqman):

 * Attachment "DatabaseError at _auth_login.png" added.

 This is the error

-- 
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/0107018ccab87f87-444ca107-8b5a-4499-94f9-f0541070200d-00%40eu-central-1.amazonses.com.


[Django] #35081: Bug when customized login issue

2024-01-02 Thread Django
#35081: Bug when customized login issue
--+
   Reporter:  Ibrahim Luqman  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Uncategorized   |Version:  5.0
   Severity:  Normal  |   Keywords:  login, cbv
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 Hello,
 I have an issue, I want to know what is the issue in my customized login
 view. The login was working perfectly on version 4.2.8, after I upgrade to
 django 5.0 this issue appears. BTW I am working on another Django project
 and the version is 5 the login is working.

-- 
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/0107018ccab7b02b-4bc5be3e-396a-4931-9f79-0ec097e3c0f9-00%40eu-central-1.amazonses.com.


Re: [Django] #35033: EmailMessage repeats header if provided via the headers kwargs

2024-01-02 Thread Django
#35033: EmailMessage repeats header if provided via the headers kwargs
+-
 Reporter:  Aalekh Patel|Owner:  Salvo Polizzi
 Type:  Bug |   Status:  assigned
Component:  Core (Mail) |  Version:  dev
 Severity:  Normal  |   Resolution:
 Keywords:  email, headers  | 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/0107018cca47d53d-c117fed7-b0c2-4459-8e8d-6c3f4e11d57a-00%40eu-central-1.amazonses.com.


Re: [Django] #35075: Add support for deduplicate_items option to BTreeIndex for PostgreSQL 13+.

2024-01-02 Thread Django
#35075: Add support for deduplicate_items option to BTreeIndex for PostgreSQL 
13+.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  postgresql,  | Triage Stage:  Ready for
  indexes, btree, deduplication  |  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:"45f778eded9dff59cfdd4dce8720daf87a08cfac" 45f778e]:
 {{{
 #!CommitTicketReference repository=""
 revision="45f778eded9dff59cfdd4dce8720daf87a08cfac"
 Fixed #35075 -- Added deduplicate_items parameter to BTreeIndex.
 }}}

-- 
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/0107018cca2f9bdb-619f8e42-ec7b-483e-84e2-a296eb498365-00%40eu-central-1.amazonses.com.


Re: [Django] #35075: Add support for deduplicate_items option to BTreeIndex for PostgreSQL 13+.

2024-01-02 Thread Django
#35075: Add support for deduplicate_items option to BTreeIndex for PostgreSQL 
13+.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql,  | Triage Stage:  Ready for
  indexes, btree, deduplication  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018cca083f48-0a2cb8cd-e6e0-4d57-b675-3f781deb8441-00%40eu-central-1.amazonses.com.


Re: [Django] #35080: Reconsideration of HTTP Method Integration in Django for Enhanced HTMX Compatibility and similar frontend expe

2024-01-02 Thread Django
#35080: Reconsideration of HTTP Method Integration in Django for Enhanced HTMX
Compatibility and similar frontend expe
-+-
 Reporter:  code-on  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Uncategorized|  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  htmx, hx-delete, | Triage Stage:
  hx-post, request.POST, |  Unreviewed
  request.DELETE, request.PATCH  |
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:   => wontfix


Comment:

 Thanks for this ticket, however, as far as I'm aware, you're proposing a
 (potentially backward incompatible) change in the way how Django handles
 HTTP request/response cycle. Such changes should first be discussed in
 detail on the Django Forum (or DevelopersMailingList), where you'll reach
 a wider audience and see what other think. Moreover, you should have a
 plan how to implement this, what kind of changes are needed, and how to
 implement them without violating out stability policy. Also, please
 [https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
 features/#requesting-features follow the guidelines with regards to
 requesting features].

 I've noticed that you also created an [https://github.com/adamchainz
 /django-htmx/issues/408 issue] in `django-htmx`. For the future, I'd
 recommend waiting for a reply instead of creating upstream tickets.

 > "By supporting these HTTP methods more explicitly"

 For example, I'm not really sure what do you mean by that.

-- 
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/0107018cc9cfb0df-f15ff41a-9281-46c5-8a4d-bf455a0cfe22-00%40eu-central-1.amazonses.com.


[Django] #35080: Reconsideration of HTTP Method Integration in Django for Enhanced HTMX Compatibility and similar frontend expe

2024-01-02 Thread Django
#35080: Reconsideration of HTTP Method Integration in Django for Enhanced HTMX
Compatibility and similar frontend expe
-+-
   Reporter:  code-on|  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component: |Version:  dev
  Uncategorized  |   Keywords:  htmx, hx-delete,
   Severity:  Normal |  hx-post, request.POST,
   Triage Stage: |  request.DELETE, request.PATCH
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I am reaching out to propose a reconsideration of Django's current
 handling of HTTP methods, specifically in the context of modern web
 development practices and the growing adoption of libraries such as HTMX.

 I understand that a similar request was previously declined (referenced in
 Django Ticket #12635 https://code.djangoproject.com/ticket/12635).
 However, the landscape of web development has significantly evolved since
 then. The integration of explicit HTTP methods such as DELETE, POST,
 PATCH, and PUT could greatly enhance Django's compatibility with HTMX and
 similar libraries.

 At present, Django views support methods like post, get, delete, and
 patch. However, integrating these methods with HTMX often leads to a
 suboptimal experience. This is partly due to the necessity of parsing
 request.body to access the transmitted values. Frameworks like Django Rest
 Framework (DRF) and other frontend libraries provide a more direct
 handling of these HTTP methods.

 By supporting these HTTP methods more explicitly, Django could enable
 cleaner and more efficient code, particularly in the context of class-
 based views. This change would reduce the need for creating multiple URLs
 and separate functions for different HTTP methods.

 Als for new people to django it makes things more clear if the missing
 request.DELETE and request.PATCH, PUT are there.

-- 
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/0107018cc9beeecc-392eaa47-3bba-469d-9df3-05305997d3e9-00%40eu-central-1.amazonses.com.


Re: [Django] #35079: Meta indexes/constraints with OpClass on expressions crash. (was: Django Migration with OpClass and varchar_pattern_ops creates an invalid migration SQL)

2024-01-02 Thread Django
#35079: Meta indexes/constraints with OpClass on expressions crash.
+
 Reporter:  andraantariksa  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  4.2
 Severity:  Normal  |   Resolution:
 Keywords:  migration   | 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):

 * cc: Lily Foote, Hannes Ljungberg (added)
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. I'm puzzled because almost
 
[https://github.com/django/django/blob/f412add786dfc18424eee6281ec8cc97220b04fc/tests/postgres_tests/test_constraints.py#L239-L244
 the same works] in our test suite and I confirmed that both `Index` and
 `UniqueConstraint` crash on:
 {{{#!python
 class Location(models.Model):
 name = models.CharField(max_length=255)
 scene = models.TextField(null=True)

 class Meta:
 indexes = [
 models.Index(
 OpClass(Upper('name'), name='varchar_pattern_ops'),
 name='uppercase_name_index'
 ),
 ]
 constraints = [
 models.UniqueConstraint(
 OpClass(Upper("scene"), name="varchar_pattern_ops"),
 name="test_opclass_func",
 )
 ]

 }}}

-- 
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/0107018cc9bb4330-1b26d57c-dce7-4a77-9893-f23f4704c959-00%40eu-central-1.amazonses.com.


Re: [Django] #35079: Django Migration with OpClass and varchar_pattern_ops creates an invalid migration SQL

2024-01-02 Thread Django
#35079: Django Migration with OpClass and varchar_pattern_ops creates an invalid
migration SQL
+--
 Reporter:  andraantariksa  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  4.2
 Severity:  Normal  |   Resolution:
 Keywords:  migration   | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by andraantariksa:

Old description:

> I have this model
>
> {{{
> class Location(models.Model):
> name = models.CharField(max_length=255)
> phone = models.CharField(max_length=255)
> latitude = models.FloatField()
> longitude = models.FloatField()
> address = models.TextField()
> address_notes = models.TextField(blank=True, default='')
> is_active = models.BooleanField(default=True)
>
> class Meta:
> indexes = [
> models.Index(
> OpClass(Upper('name'), name='varchar_pattern_ops'),
> 'phone',
> name='uppercase_name_index'
> ),
> ]
>
> def __str__(self) -> str:
> return self.name
> }}}
>
> And I create a migration using Django makemigration which produce the
> following script
>
> {{{
> # Generated by Django 4.2.7 on 2024-01-02 09:12
>
> import django.contrib.postgres.indexes
> from django.db import migrations, models
> import django.db.models.functions.text
>

> class Migration(migrations.Migration):
> dependencies = [
> ("locations", "0004_providerlocationcode_sub_district"),
> ]
>
> operations = [
> migrations.AddIndex(
> model_name="location",
> index=models.Index(
> django.contrib.postgres.indexes.OpClass(
> django.db.models.functions.text.Upper("name"),
> name="varchar_pattern_ops",
> ),
> name="uppercase_name_index",
> ),
> ),
> ]
> }}}
>
> However I encounter an error when running the migration using
> `./manage.py migrate locations 0005`
>
> {{{
> py manage.py migrate locations
> System check identified some issues:
>
> WARNINGS:
> ?: (urls.W005) URL namespace 'admin' isn't unique. You may not be able to
> reverse all URLs in this namespace
> Operations to perform:
>   Apply all migrations: locations
> Running migrations:
>   Applying locations.0005_location_uppercase_name_index...Traceback (most
> recent call last):
>   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
> packages/django/db/backends/utils.py", line 87, in _execute
> return self.cursor.execute(sql)
> psycopg2.errors.SyntaxError: syntax error at or near
> "varchar_pattern_ops"
> LINE 1: ...me_index" ON "locations_location" ((UPPER("name")
> varchar_pa...
>  ^
>

> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "/home/andra/Projects/fleet/manage.py", line 21, in 
> main()
>   File "/home/andra/Projects/fleet/manage.py", line 17, in main
> execute_from_command_line(sys.argv)
>   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
> packages/django/core/management/__init__.py", line 442, in
> execute_from_command_line
> utility.execute()
>   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
> packages/django/core/management/__init__.py", line 436, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
> packages/django/core/management/base.py", line 412, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
> packages/django/core/management/base.py", line 458, in execute
> output = self.handle(*args, **options)
>   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
> packages/django/core/management/base.py", line 106, in wrapper
> res = handle_func(*args, **kwargs)
>   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
> packages/django/core/management/commands/migrate.py", line 356, in handle
> post_migrate_state = executor.migrate(
>   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
> packages/django/db/migrations/executor.py", line 135, in migrate
> state = self._migrate_all_forwards(
>   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
> packages/django/db/migrations/executor.py", line 167, in
> _migrate_all_forwards
> state = self.apply_migration(
>   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
> packages/django/db/migr

[Django] #35079: Django Migration with OpClass and varchar_pattern_ops creates an invalid migration SQL

2024-01-02 Thread Django
#35079: Django Migration with OpClass and varchar_pattern_ops creates an invalid
migration SQL
--+---
   Reporter:  andraantariksa  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  4.2
   Severity:  Normal  |   Keywords:  migration
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
 I have this model

 {{{
 class Location(models.Model):
 name = models.CharField(max_length=255)
 phone = models.CharField(max_length=255)
 latitude = models.FloatField()
 longitude = models.FloatField()
 address = models.TextField()
 address_notes = models.TextField(blank=True, default='')
 is_active = models.BooleanField(default=True)

 class Meta:
 indexes = [
 models.Index(
 OpClass(Upper('name'), name='varchar_pattern_ops'),
 'phone',
 name='uppercase_name_index'
 ),
 ]

 def __str__(self) -> str:
 return self.name
 }}}

 And I create a migration using Django makemigration which produce the
 following script

 {{{
 # Generated by Django 4.2.7 on 2024-01-02 09:12

 import django.contrib.postgres.indexes
 from django.db import migrations, models
 import django.db.models.functions.text


 class Migration(migrations.Migration):
 dependencies = [
 ("locations", "0004_providerlocationcode_sub_district"),
 ]

 operations = [
 migrations.AddIndex(
 model_name="location",
 index=models.Index(
 django.contrib.postgres.indexes.OpClass(
 django.db.models.functions.text.Upper("name"),
 name="varchar_pattern_ops",
 ),
 name="uppercase_name_index",
 ),
 ),
 ]
 }}}

 However I encounter an error when running the migration using `./manage.py
 migrate locations 0005`

 {{{
 py manage.py migrate locations
 System check identified some issues:

 WARNINGS:
 ?: (urls.W005) URL namespace 'admin' isn't unique. You may not be able to
 reverse all URLs in this namespace
 Operations to perform:
   Apply all migrations: locations
 Running migrations:
   Applying locations.0005_location_uppercase_name_index...Traceback (most
 recent call last):
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/db/backends/utils.py", line 87, in _execute
 return self.cursor.execute(sql)
 psycopg2.errors.SyntaxError: syntax error at or near "varchar_pattern_ops"
 LINE 1: ...me_index" ON "locations_location" ((UPPER("name") varchar_pa...
  ^


 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "/home/andra/Projects/fleet/manage.py", line 21, in 
 main()
   File "/home/andra/Projects/fleet/manage.py", line 17, in main
 execute_from_command_line(sys.argv)
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/core/management/__init__.py", line 442, in
 execute_from_command_line
 utility.execute()
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/core/management/__init__.py", line 436, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/core/management/base.py", line 412, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/core/management/base.py", line 458, in execute
 output = self.handle(*args, **options)
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/core/management/base.py", line 106, in wrapper
 res = handle_func(*args, **kwargs)
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/core/management/commands/migrate.py", line 356, in handle
 post_migrate_state = executor.migrate(
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/db/migrations/executor.py", line 135, in migrate
 state = self._migrate_all_forwards(
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/db/migrations/executor.py", line 167, in
 _migrate_all_forwards
 state = self.apply_migration(
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/db/migrations/executor.py", line 252, in apply_migration
 state = migration.apply(state, schema_editor)
   File "/home/andra/Projects/fleet/venv/lib/python3.9/site-
 packages/django/db/migrations

Re: [Django] #35060: Make Model.save() arguments keyword-only

2024-01-02 Thread Django
#35060: Make Model.save() arguments keyword-only
-+-
 Reporter:  Jacob Walls  |Owner:  Salvo
 Type:   |  Polizzi
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"3915d4c70d0d7673abe675525b58117a5099afd3" 3915d4c]:
 {{{
 #!CommitTicketReference repository=""
 revision="3915d4c70d0d7673abe675525b58117a5099afd3"
 Fixed #35060 -- Deprecated passing positional arguments to
 Model.save()/asave().
 }}}

-- 
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/0107018cc95e858c-39ff563f-4082-4c91-95ad-1be13d0374f0-00%40eu-central-1.amazonses.com.