Re: [Django] #35167: JSONField get_db_prep_value being called with `Cast` types

[Django]

#35167: JSONField get_db_prep_value being called with `Cast` types
-+-
 Reporter:  Samantha Hughes  |Owner:
 |  HeejunShin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by HeejunShin):

 Replying to [comment:15 Simon Charette]:

 thank you for  youre response.
-- 
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/0107018ea25d659d-c1f6f1e3-b099-48ff-9fcc-fee0d09436ed-00%40eu-central-1.amazonses.com.

Re: [Django] #35167: JSONField get_db_prep_value being called with `Cast` types

[Django]

#35167: JSONField get_db_prep_value being called with `Cast` types
-+-
 Reporter:  Samantha Hughes  |Owner:
 |  HeejunShin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by HeejunShin):

 * owner:  (none) => HeejunShin
 * 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/0107018ea25cdc4e-899362f9-432a-496b-946f-7311e84684bc-00%40eu-central-1.amazonses.com.

Re: [Django] #35167: JSONField get_db_prep_value being called with `Cast` types

[Django]

#35167: JSONField get_db_prep_value being called with `Cast` types
-+-
 Reporter:  Samantha Hughes  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by HeejunShin):

 Thank you for  youre response.
-- 
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/0107018ea25c1b2d-5e4e2a78-d7de-4bb0-83e2-352a042928b5-00%40eu-central-1.amazonses.com.

Re: [Django] #35167: JSONField get_db_prep_value being called with `Cast` types

[Django]

#35167: JSONField get_db_prep_value being called with `Cast` types
-+-
 Reporter:  Samantha Hughes  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by HeejunShin):

 Replying to [comment:15 Simon Charette]:
 > Replying to [comment:14 HeejunShin]:
 > > Is this ticket solved?
 >
 > No. While it has an inline tentative patch no one
 [https://docs.djangoproject.com/en/5.0/internals/contributing/writing-code
 /submitting-patches/#claiming-tickets has opened a PR on Github with the
 proposed changes] including a regression test yet.

 > thank you for  youre response.
-- 
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/0107018ea25adf9f-b79d8b2f-b536-4910-a123-10fe43719e25-00%40eu-central-1.amazonses.com.

Re: [Django] #35330: The update of related objects fails in the admin when the related model is camel case.

[Django]

#35330: The update of related objects fails in the admin when the related model 
is
camel case.
-+-
 Reporter:  devin13cox   |Owner:
 |  devin13cox
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  5.0
 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:  1|UI/UX:  1
-+-
Changes (by GitHub ):

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

Comment:

 In [changeset:"8665cf03d79c4b6222514c5943ccf3863a19cf08" 8665cf03]:
 {{{#!CommitTicketReference repository=""
 revision="8665cf03d79c4b6222514c5943ccf3863a19cf08"
 Fixed #35330 -- Fixed the update of related widgets when the referenced
 model is camel case named.

 Co-authored-by: Natalia <124304+ness...@users.noreply.github.com>
 }}}
-- 
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/0107018ea178d048-c0447eef-9738-4c61-8caa-31904b6a55e1-00%40eu-central-1.amazonses.com.

Re: [Django] #35332: Bad performance in django.template.load.render_to_string

[Django]

#35332: Bad performance in django.template.load.render_to_string
-+-
 Reporter:  Zeyad Moustafa   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  performance  | Triage Stage:
  templates jinja|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Zeyad Moustafa):

 OK. I opened a discussion here https://forum.djangoproject.com/t/getting-a
 -low-performance-in-django-template-loader-render-to-string/29488 and the
 person I was talking with told me the same thing that the benchmarking is
 not that good.

 and I decided to make this template engine in rust. but I don't plan to
 integrate it into Django directly. I will start by building a standalone
 package and when I get a good community of people who are using it and
 testing it I might open a PR and integrate it to Django. but thanks for
 letting me know that you are interested in this idea.
-- 
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/0107018ea14c8fa2-2788df43-4bc5-4b9b-89a8-3a3b1414ff0b-00%40eu-central-1.amazonses.com.

Re: [Django] #35347: Clarify choice_set attribute in tutorial 2 (was: Clarify choice_set function in tutorial 2)

[Django]

#35347: Clarify choice_set attribute in tutorial 2
-+-
 Reporter:  Lang Tran|Owner:  Lang Tran
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin
 * summary:  Clarify choice_set function in tutorial 2 => Clarify choice_set
 attribute in tutorial 2

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018ea119a5b7-fbe58806-e7fb-48d3-a11e-f531670b168c-00%40eu-central-1.amazonses.com.

Re: [Django] #35349: Transaction API does not respect the DATABASE_ROUTERS configuration

[Django]

#35349: Transaction API does not respect the DATABASE_ROUTERS configuration
-+-
 Reporter:  Vitaliy Diachkov |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  transaction, db, | Triage Stage:
  database routers   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Adam Johnson):

 Forum discussion: https://forum.djangoproject.com/t/use-database-routers-
 to-pick-a-database-connection-for-transaction-api-by-default/29744
-- 
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/0107018ea0daed98-f90f98d8-4497-468a-a904-8e904a9576bc-00%40eu-central-1.amazonses.com.

Re: [Django] #35336: Adding GeneratedField fails with ProgrammingError when using When on CharField

[Django]

#35336: Adding GeneratedField fails with ProgrammingError when using When on
CharField
-+-
 Reporter:  Adrian Garcia|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  postgres,| Triage Stage:  Ready for
  generatedfield, contains   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Natalia Bidart):

 Adrian, the release is planned for tomorrow. Thank you for your 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/0107018ea08d4ef7-17ee42f7-84f2-419a-96db-a0efea94bb6b-00%40eu-central-1.amazonses.com.

Re: [Django] #35330: The update of related objects fails in the admin when the related model is camel case.

[Django]

#35330: The update of related objects fails in the admin when the related model 
is
camel case.
-+-
 Reporter:  devin13cox   |Owner:
 |  devin13cox
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Natalia Bidart):

 * 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/0107018ea088e14d-bff3f8a6-d783-41ae-9299-a28c5b291a61-00%40eu-central-1.amazonses.com.

Re: [Django] #35336: Adding GeneratedField fails with ProgrammingError when using When on CharField

[Django]

#35336: Adding GeneratedField fails with ProgrammingError when using When on
CharField
-+-
 Reporter:  Adrian Garcia|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  postgres,| Triage Stage:  Ready for
  generatedfield, contains   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

 * 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/0107018ea0888396-11b590f4-cf16-4ef2-80d0-7d5643b27708-00%40eu-central-1.amazonses.com.

Re: [Django] #35336: Adding GeneratedField fails with ProgrammingError when using When on CharField

[Django]

#35336: Adding GeneratedField fails with ProgrammingError when using When on
CharField
-+-
 Reporter:  Adrian Garcia|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  postgres,| Triage Stage:  Accepted
  generatedfield, contains   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Natalia <124304+nessita@…>):

 In [changeset:"fead2dd52303505f30007df5e3c198b48b3ce9ae" fead2dd]:
 {{{#!CommitTicketReference repository=""
 revision="fead2dd52303505f30007df5e3c198b48b3ce9ae"
 [5.0.x] Fixed #35336 -- Addressed crash when adding a GeneratedField with
 % literals.

 A longer term solution is likely to have a better separation of
 parametrized
 DDL altogether to handle checks, constraints, defaults, and generated
 fields
 but such a change would require a significant refactor that isn't suitable
 for a backport.

 Thanks Adrian Garcia for the report.

 Backport of 888b9042b3598bab6557c62de82505eec9ea62ed 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/0107018ea085bfd2-8cca19d2-737e-4ee3-b068-22d7dbd85e1c-00%40eu-central-1.amazonses.com.

Re: [Django] #35336: Adding GeneratedField fails with ProgrammingError when using When on CharField

[Django]

#35336: Adding GeneratedField fails with ProgrammingError when using When on
CharField
-+-
 Reporter:  Adrian Garcia|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  postgres,| Triage Stage:  Accepted
  generatedfield, contains   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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

Comment:

 In [changeset:"888b9042b3598bab6557c62de82505eec9ea62ed" 888b9042]:
 {{{#!CommitTicketReference repository=""
 revision="888b9042b3598bab6557c62de82505eec9ea62ed"
 Fixed #35336 -- Addressed crash when adding a GeneratedField with %
 literals.

 A longer term solution is likely to have a better separation of
 parametrized
 DDL altogether to handle checks, constraints, defaults, and generated
 fields
 but such a change would require a significant refactor that isn't suitable
 for a backport.

 Thanks Adrian Garcia for the report.
 }}}
-- 
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/0107018ea0846e55-a58b93bc-67f0-4159-ba6f-7eac714892e4-00%40eu-central-1.amazonses.com.

Re: [Django] #35344: GeneratedField get_col output_field bug

[Django]

#35344: GeneratedField get_col output_field bug
-+-
 Reporter:  Johannes Westphal|Owner:  Johannes
 |  Westphal
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (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 Johannes Westphal):

 Thank you Natalia and Simon for the fast processing of my bug report and
 pull 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/0107018ea05cb424-696a86cd-34d4-4cab-9448-932c1f0e3985-00%40eu-central-1.amazonses.com.

Re: [Django] #35347: Clarify choice_set function in tutorial 2

[Django]

#35347: Clarify choice_set function in tutorial 2
-+-
 Reporter:  Lang Tran|Owner:  Lang Tran
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Comment (by Lang Tran):

 That was pretty much my experience going through the tutorial. The link
 between `choice_set` and "the set" wasn't explicit enough for me to make
 the connection, particularly when you're skimming comments as people
 typically do. Another benefit is that if we explicitly mention it within
 the comment then if somebody is ctrl+f-ing through the docs then they'll
 see it mentioned in the comment and be able to make the connection.
-- 
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/0107018ea041f0ce-f464dff6-bf65-4feb-8a2d-facf4a264e86-00%40eu-central-1.amazonses.com.

Re: [Django] #35332: Bad performance in django.template.load.render_to_string

[Django]

#35332: Bad performance in django.template.load.render_to_string
-+-
 Reporter:  Zeyad Moustafa   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  performance  | Triage Stage:
  templates jinja|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Adam Johnson):

 Yeah, there’s no bug here. 30 times slowness is about right for a
 Rust/Python comparison. Also the benchmark is minimal and unrealistic, the
 margin should be less (maybe not much) for a typical template that has far
 fewer nodes.

 This would be an interesting forum discussion - not a bug in the bug
 tracker. I’d be interested in seeing more. And if you want to get into
 optimizing specific parts of the template engine, I’d be up for reviewing
 some PRs. My recent work on the system checks may be a nice guide:
 https://adamj.eu/tech/2024/03/23/django-optimizing-system-checks/
-- 
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/0107018ea0396449-42a9f547-09d5-418f-94ea-1d3c984e7fbe-00%40eu-central-1.amazonses.com.

Re: [Django] #35347: Clarify choice_set function in tutorial 2

[Django]

#35347: Clarify choice_set function in tutorial 2
-+-
 Reporter:  Lang Tran|Owner:  Lang Tran
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Comment (by Natalia Bidart):

 Replying to [comment:7 Tim Graham]:
 > I doubt it's a common source of confusion. "Django creates a set...
 which can be accessed via the API." does all but name the set. We could
 say something like, "Django creates a choice_set attribute on Question
 instances..." but it feels a bit unnecessary when example usage follows
 two lines later.

 My understanding from the original report is that for someone new to
 Django, it's not easy to make the connection that "''the set''" is
 actually named `choice_set`. I know both things have the word "set" in it,
 but I fear we may be too involved already in the project to not see the
 connection (but newcomers may easily miss it).

 I remember when I was learning Django, and seeing references to the
 magical `something_set` attribute, and given my lack of experience and the
 inevitable language barrier, I assume it to be a "weirdly named thing that
 was like that just because a core dev did not like plurals" and not
 because `_set` actually meant "''the set of [related] somethings''". More
 so, when you read the tutorial in another language, "set" could be
 translated to the proper term in that language so the connection is quite
 challenging to be made, or worse, is not translated at all (because it's a
 code comment) and the explanation is totally missed if the reader does not
 understand English!
-- 
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/0107018ea02abc2b-66ae6a73-6bc8-464a-9f51-a066691589f4-00%40eu-central-1.amazonses.com.

Re: [Django] #35347: Clarify choice_set function in tutorial 2

[Django]

#35347: Clarify choice_set function in tutorial 2
-+-
 Reporter:  Lang Tran|Owner:  Lang Tran
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Comment (by Tim Graham):

 I doubt it's a common source of confusion. "Django creates a set... which
 can be accessed via the API." does all but name the set. We could say
 something like, "Django creates a choice_set attribute on Question
 instances..." but it feels a bit unnecessary when example usage follows
 two lines later.
-- 
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/0107018ea00ff7db-2d4e7c43-72c2-4bed-92e5-19797a753124-00%40eu-central-1.amazonses.com.

Re: [Django] #35269: GeneratedFields can't be defined on RelatedFields

[Django]

#35269: GeneratedFields can't be defined on RelatedFields
-+-
 Reporter:  Perrine L.   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 Natalia Bidart):

 * type:  Bug => New feature

-- 
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/0107018e9fe849d3-96bac56b-db33-4b9e-b258-a940955041f0-00%40eu-central-1.amazonses.com.

Re: [Django] #35269: GeneratedFields can't be defined on RelatedFields

[Django]

#35269: GeneratedFields can't be defined on RelatedFields
-+-
 Reporter:  Perrine L.   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 Sarah Boyce):

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

Comment:

 Hi Perrine, this ticket should only be re-opened if you do as Mariusz
 requested and provide a valid column DDL definition that you believe is
 not currently supported.
 I believe this will not be possible as
 [https://www.postgresql.org/docs/current/ddl-generated-columns.html the
 linked documentation states] and Mariusz mentioned, `GeneratedFields`
 cannot reference anything other than the current row in **any way** and
 being a `ForeignKey` is a reference to an external model.

 Thank you for the sample project and I can see what you're trying to do.
 As what you're suggesting would be a new feature to Django, the
 recommended path forward is to first propose and discuss the idea with the
 community and gain consensus that this would be a desirable addition to
 Django. To do that, please consider starting a new conversation on the
 [https://forum.djangoproject.com/c/internals/5 Django Forum], where you'll
 reach a wider audience and likely get extra feedback.

 I'll close this ticket, but if there is a community agreement for the
 feature request, you are welcome to create a ticket for the new feature
 and point to the forum topic. For more details, please see
 [https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
 features/#requesting-features the documented guidelines for requesting
 features].
-- 
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/0107018e9fb0a1ff-483746ea-e033-4ea1-82c5-a9a8fd878280-00%40eu-central-1.amazonses.com.

Re: [Django] #35336: Adding GeneratedField fails with ProgrammingError when using When on CharField

[Django]

#35336: Adding GeneratedField fails with ProgrammingError when using When on
CharField
-+-
 Reporter:  Adrian Garcia|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  postgres,| Triage Stage:  Accepted
  generatedfield, contains   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Simon Charette):

 > are there plans for a more unified SQL translator in a future release

 I think the many regressions we've run into in the past releases in
 escaping DDL (the subset of SQL for defining objects) in the schema editor
 (the component behind migrations) warrants spending time having a less
 convoluted approach.

 I think that we should experiment with having backends denote whether or
 not they support parametrized DDL (the ability to call
 `Cursor.execute(ddl: str, params: tuple)` over having the schema editor do
 the `%` formatting itself), make sure all parts of the scheme editor
 return `(str, tuple)` and never simply `str`, and then adjust
 `SchemaEditor.execute` to do `cursor.execute(ddl, params)` when
 `connection.features.support_parametrized_dll` and do `cursor.execute(ddl
 % map(self.quote_value, params), None)` otherwise.
-- 
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/0107018e9f8105d6-641eed1b-7078-4aba-9793-ee74590b4484-00%40eu-central-1.amazonses.com.

Re: [Django] #35336: Adding GeneratedField fails with ProgrammingError when using When on CharField

[Django]

#35336: Adding GeneratedField fails with ProgrammingError when using When on
CharField
-+-
 Reporter:  Adrian Garcia|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  postgres,| Triage Stage:  Accepted
  generatedfield, contains   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Adrian Garcia):

 Thanks for the rundown, it really helped me understand what was going on
 when I followed the execution with a debugger. The ORM is easily my
 favorite part of Django and it's no surprise that it is complicated as
 hell, are there plans for a more unified SQL translator in a future
 release? I'd be interested in following the progress of that.

 I tested the fix and it works great, might not even need to use the
 workaround if 5.0.4 gets released in the next few weeks. Thanks for the
 speedy patch.
-- 
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/0107018e9f16c044-45fa7c91-c151-44fb-91f6-10db7bdaa0f5-00%40eu-central-1.amazonses.com.

Re: [Django] #35349: Transaction API does not respect the DATABASE_ROUTERS configuration

[Django]

#35349: Transaction API does not respect the DATABASE_ROUTERS configuration
-+-
 Reporter:  Vitaliy Diachkov |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  transaction, db, | Triage Stage:
  database routers   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

 * resolution:  fixed => wontfix

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e9ef3c612-6ce40cc8-744a-47e2-bec0-f8f988aabb99-00%40eu-central-1.amazonses.com.

Re: [Django] #35349: Transaction API does not respect the DATABASE_ROUTERS configuration

[Django]

#35349: Transaction API does not respect the DATABASE_ROUTERS configuration
-+-
 Reporter:  Vitaliy Diachkov |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  transaction, db, | Triage Stage:
  database routers   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

 * resolution:   => fixed
 * status:  new => closed
 * type:  Bug => New feature


Old description:

> Using the transaction API from `django.db.transaction` module directly
> does not respect the DATABASE_ROUTERS configuration and it does not grab
> the db_for_write() database alias by default. Instead, it always falls
> down to django.db.utils.DEFAULT_DB_ALIAS. The expected behaviour for this
> case would either use db_for_write() or introduce a new
> db_for_transaction() method for database routers as was proposed in
> [https://groups.google.com/g/django-developers/c/clzg6MiixFc this
> discussion]. The discussion itself has no resolution in a two years, so I
> have decided to create a dedicated issue for that.
>
> What I mean, if that whenever in code you use:
>
> {{{
> from django.db import trasnaction
>
> @transaction.atomic()
> def foo(...):
>  # ... do stuff ...
>  transaction.commit()
> }}}
>

> The `atomic()`, `commit()` and other functions should access the
> write/transaction database under the hood.
> 
> ** Note **: I am developing an application that switches the database
> connection on per-tenant bases. The database configurations are added to
> settings.DATABASES at runtime in a middleware and then, using the
> `contextvars.ContextVar` thread-local variable, I am passing the database
> alias to use from a middleware to my custom database router. It works
> fine for reading and writing data outside the transactions, but it fails
> when it comes to transaction. I could potentially pass the value of
> `ContextVar` as an argument to all Transaction API calls, but it still
> fails for the third-party libraries that are mostly calling this
> functions without arguments. I have patched globally
> `django.db.transaction.DEFAULT_DB_ALIAS` to a stub string-like object
> that resolves dynamically in a runtime to a value of `ContextVar`, but
> that solution seems to be weird and I wish I could make it through
> configuring `DATABASE_ROUTERS`.

New description:

 Using the transaction API from `django.db.transaction` module directly
 does not respect the DATABASE_ROUTERS configuration and it does not grab
 the db_for_write() database alias by default. Instead, it always falls
 down to django.db.utils.DEFAULT_DB_ALIAS. The expected behaviour for this
 case would either use db_for_write() or introduce a new
 db_for_transaction() method for database routers as was proposed in
 [https://groups.google.com/g/django-developers/c/clzg6MiixFc this
 discussion]. The discussion itself has no resolution in a two years, so I
 have decided to create a dedicated issue for that.

 What I mean, if that whenever in code you use:

 {{{
 from django.db import transaction

 @transaction.atomic()
 def foo(...):
  # ... do stuff ...
  transaction.commit()
 }}}


 The `atomic()`, `commit()` and other functions should access the
 write/transaction database under the hood.
 
 ** Note **: I am developing an application that switches the database
 connection on per-tenant bases. The database configurations are added to
 settings.DATABASES at runtime in a middleware and then, using the
 `contextvars.ContextVar` thread-local variable, I am passing the database
 alias to use from a middleware to my custom database router. It works fine
 for reading and writing data outside the transactions, but it fails when
 it comes to transaction. I could potentially pass the value of
 `ContextVar` as an argument to all Transaction API calls, but it still
 fails for the third-party libraries that are mostly calling this functions
 without arguments. I have patched globally
 `django.db.transaction.DEFAULT_DB_ALIAS` to a stub string-like object that
 resolves dynamically in a runtime to a value of `ContextVar`, but that
 solution seems to be weird and I wish I could make it through configuring
 `DATABASE_ROUTERS`.

--
Comment:

 Hi Vitaliy, thank you for your report.

 > Using the transaction API from django.db.transaction module directly
 does not respect the DATABASE_ROUTERS configuration and it does not grab
 the db_for_write() database alias 

Re: [Django] #35349: Transaction API does not respect the DATABASE_ROUTERS configuration

[Django]

#35349: Transaction API does not respect the DATABASE_ROUTERS configuration
-+-
 Reporter:  diachkow |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  transaction, db, | Triage Stage:
  database routers   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by diachkow:

Old description:

> Using the transaction API from `django.db.transaction` module directly
> does not respect the DATABASE_ROUTERS configuration and it does not grab
> the db_for_write() database alias by default. Instead, it always falls
> down to django.db.utils.DEFAULT_DB_ALIAS. The expected behaviour for this
> case would either use db_for_write() or introduce a new
> db_for_transaction() method for database routers as was proposed in
> [https://groups.google.com/g/django-developers/c/clzg6MiixFc this
> discussion]. The discussion itself has no resolution in a two years, so I
> have decided to create a dedicated issue for that.
>
> What I mean, if that whenever in code you use:
>
> {{{
> from django.db import trasnaction
>
> @transaction.atomic()
> def foo(...):
>  # ... do stuff ...
>  transaction.commit()
> }}}
>

> The `atomic()`, `commit()` and other functions should get the
> write/transaction database under the hood.
> 
> ** Note **: I am developing an application that switches the database
> connection on per-tenant bases. The database configurations are added to
> settings.DATABASES at runtime in a middleware and then, using the
> `contextvars.ContextVar` thread-local variable, I am passing the database
> alias to use from a middleware to my custom database router. It works
> fine for reading and writing data outside the transactions, but it fails
> when it comes to transaction. I could potentially pass the value of
> `ContextVar` as an argument to all Transaction API calls, but it still
> fails for the third-party libraries that are mostly calling this
> functions without arguments. I have patched globally
> `django.db.transaction.DEFAULT_DB_ALIAS` to a stub string-like object
> that resolves dynamically in a runtime to a value of `ContextVar`, but
> that solution seems to be weird and I wish I could make it through
> configuring `DATABASE_ROUTERS`.

New description:

 Using the transaction API from `django.db.transaction` module directly
 does not respect the DATABASE_ROUTERS configuration and it does not grab
 the db_for_write() database alias by default. Instead, it always falls
 down to django.db.utils.DEFAULT_DB_ALIAS. The expected behaviour for this
 case would either use db_for_write() or introduce a new
 db_for_transaction() method for database routers as was proposed in
 [https://groups.google.com/g/django-developers/c/clzg6MiixFc this
 discussion]. The discussion itself has no resolution in a two years, so I
 have decided to create a dedicated issue for that.

 What I mean, if that whenever in code you use:

 {{{
 from django.db import trasnaction

 @transaction.atomic()
 def foo(...):
  # ... do stuff ...
  transaction.commit()
 }}}


 The `atomic()`, `commit()` and other functions should access the
 write/transaction database under the hood.
 
 ** Note **: I am developing an application that switches the database
 connection on per-tenant bases. The database configurations are added to
 settings.DATABASES at runtime in a middleware and then, using the
 `contextvars.ContextVar` thread-local variable, I am passing the database
 alias to use from a middleware to my custom database router. It works fine
 for reading and writing data outside the transactions, but it fails when
 it comes to transaction. I could potentially pass the value of
 `ContextVar` as an argument to all Transaction API calls, but it still
 fails for the third-party libraries that are mostly calling this functions
 without arguments. I have patched globally
 `django.db.transaction.DEFAULT_DB_ALIAS` to a stub string-like object that
 resolves dynamically in a runtime to a value of `ContextVar`, but that
 solution seems to be weird and I wish I could make it through configuring
 `DATABASE_ROUTERS`.

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

[Django] #35349: Transaction API does not respect the DATABASE_ROUTERS configuration

[Django]

#35349: Transaction API does not respect the DATABASE_ROUTERS configuration
-+-
   Reporter:  diachkow   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:
  layer (models, ORM)|   Keywords:  transaction, db,
   Severity:  Normal |  database routers
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Using the transaction API from `django.db.transaction` module directly
 does not respect the DATABASE_ROUTERS configuration and it does not grab
 the db_for_write() database alias by default. Instead, it always falls
 down to django.db.utils.DEFAULT_DB_ALIAS. The expected behaviour for this
 case would either use db_for_write() or introduce a new
 db_for_transaction() method for database routers as was proposed in
 [https://groups.google.com/g/django-developers/c/clzg6MiixFc this
 discussion]. The discussion itself has no resolution in a two years, so I
 have decided to create a dedicated issue for that.

 What I mean, if that whenever in code you use:

 {{{
 from django.db import trasnaction

 @transaction.atomic()
 def foo(...):
  # ... do stuff ...
  transaction.commit()
 }}}


 The `atomic()`, `commit()` and other functions should get the
 write/transaction database under the hood.
 
 ** Note **: I am developing an application that switches the database
 connection on per-tenant bases. The database configurations are added to
 settings.DATABASES at runtime in a middleware and then, using the
 `contextvars.ContextVar` thread-local variable, I am passing the database
 alias to use from a middleware to my custom database router. It works fine
 for reading and writing data outside the transactions, but it fails when
 it comes to transaction. I could potentially pass the value of
 `ContextVar` as an argument to all Transaction API calls, but it still
 fails for the third-party libraries that are mostly calling this functions
 without arguments. I have patched globally
 `django.db.transaction.DEFAULT_DB_ALIAS` to a stub string-like object that
 resolves dynamically in a runtime to a value of `ContextVar`, but that
 solution seems to be weird and I wish I could make it through configuring
 `DATABASE_ROUTERS`.
-- 
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/0107018e9e835642-9859c19d-be39-4b81-a954-6b13e64a66ad-00%40eu-central-1.amazonses.com.

Re: [Django] #35348: Inconsistent behaviour with annotate using concat and GenericIPAddressField

[Django]

#35348: Inconsistent behaviour with annotate using concat and 
GenericIPAddressField
-+-
 Reporter:  Lorenzo Morandini|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

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

Comment:

 Hi Lorenzo, thank you for this report.

 I am struggling to replicate this locally and need a few more details. To
 help me, please provide:
 - what database are you using
 - what version of Python are you using
 - did you upgrade Python when upgrading from Django 3.2 to 4.2

 We use
 [https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Network
 ipaddress] from the Python standard library and `/32` is documented as a
 default mask for `IPv4Network`, hence the version of Python might be
 important here and whether this changed while upgrading.

 If you want to make my day, you could
 [https://docs.djangoproject.com/en/5.0/internals/contributing/writing-code
 /unit-tests/#unit-tests write a regression test] which will help verify
 the issue and make sure it gets resolved quickly.
-- 
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/0107018e9e6ffe76-773515e0-cd5e-42d9-90fa-2f922dda2e1a-00%40eu-central-1.amazonses.com.

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

[Django]

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

 GitHub PR https://github.com/django/django/pull/18039
-- 
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/0107018e9e3bda20-71b87e26-4730-4b18-bac8-51137334a606-00%40eu-central-1.amazonses.com.

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

[Django]

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

 * needs_better_patch:  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/0107018e9e305a2c-4c2c5f5a-e973-4fae-9840-495cd1407cc1-00%40eu-central-1.amazonses.com.

[Django] #35348: Inconsistent behaviour with annotate using concat and GenericIPAddressField

[Django]

#35348: Inconsistent behaviour with annotate using concat and 
GenericIPAddressField
-+-
   Reporter:  Lorenzo|  Owner:  nobody
  Morandini  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Concat function behaviour changed from django 3 to django 4 together with
 GenericIPAddressField. In django 3 it would output only the ip address,
 now a /32 is included too by default

 Example model

 {{{
 class Example(models.Model):
 ip_address = models.GenericIPAddressField(
 _('ip address'), db_index=True, protocol='IPv4'
 )
 mask = models.PositiveIntegerField(
 _('mask'),
 )

 Example.objects.all()
 .annotate(
 main_ip=Concat(
 'ip_address',
 V('/')
 'mask'
 )
 )
 }}}

 With an example item with ip 192.168.1.1 and mask 30 the output would be:

 in django 3 main_ip: 192.168.1.1/30
 in django 4 main_ip: 192.168.1.1/32/30

 Is this an expected behaviour? Happens only with concat, an annotate of
 the ip_address field only produces the output '192.168.1.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/0107018e9e1dbda5-2b8588fd-b053-458e-a060-376d925f4272-00%40eu-central-1.amazonses.com.

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

[Django]

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

 Passing `QuseySet` to `Query` will make `QuerySet` object be evaluated
 when pickling `Query` object and make pickle results big.

 Related ticket #27159

 It should have some reason why `Query` will be pickled. I will come up
 with another approch to solve 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/0107018e9de75f94-39424d31-01cf-47bd-9356-d109c01297ac-00%40eu-central-1.amazonses.com.

Re: [Django] #35269: GeneratedFields can't be defined on RelatedFields

[Django]

#35269: GeneratedFields can't be defined on RelatedFields
-+-
 Reporter:  Perrine L.   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by fero):

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e9de521d4-532de178-23bb-4f8f-986c-89d6a6174c70-00%40eu-central-1.amazonses.com.

Re: [Django] #35269: GeneratedFields can't be defined on RelatedFields

[Django]

#35269: GeneratedFields can't be defined on RelatedFields
-+-
 Reporter:  Perrine L.   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by fero):

 Hello, I think I have developed something that would do for this bug. With
 RelatedField on a GeneratedField it is possible to use all wonderful
 Django ORM lookup features.

 https://github.com/feroda/play-django-generatedfk

 Now my implementation requires a separate field (I have called
 NoopForeignKey https://github.com/feroda/play-django-
 generatedfk/blob/main/noopfk/fields.py), in addition to the
 GeneratedField, but I think it is not too much work to integrate the
 feature in a dedicated field to be used as `output_field` (maybe:
 models.GeneratedForeignKey?) and I am almost confident that it could be a
 benefit also for referencing F() foreign key fields that should not
 provide only the value of the foreign key, but also the RelatedManager
 too.

 What do you think about it?
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e9de46f63-8501d835-272d-4d5b-bf45-6de5b332cf96-00%40eu-central-1.amazonses.com.