date:20211018

Re: [Django] #33197: Renaming field and providing prior field name to db_column should be an SQL noop

2021-10-18 Thread Django

#33197: Renaming field and providing prior field name to db_column should be an 
SQL
noop
-+-
 Reporter:  Jacob Walls  |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  dev
 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:"5896aa8367d545c60bb544c31d7ecaaecc321045" 5896aa8]:
 {{{
 #!CommitTicketReference repository=""
 revision="5896aa8367d545c60bb544c31d7ecaaecc321045"
 Fixed #33197 -- Made field rename with prior matching db_column change a
 noop.

 Thanks Jacob Walls 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/073.1871c987117b0bfb4edefadd4aa97354%40djangoproject.com.

Re: [Django] #33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic Foreign Key

2021-10-18 Thread Django

#33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic
Foreign Key
-+-
 Reporter:  Finn Andersen|Owner:  Jonny
 |  Park
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  fk, gfk, generic | Triage Stage:  Accepted
  foreign key, validation|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:8 wtzhu]:
 > The code I defined is as follows. I have verified that the data already
 exists in the database after I save the object of Grade, but I can not use
 it to save the object of Stu.

 This is not related with `GenericForeignKey` please create a separate
 ticket.

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

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

Re: [Django] #33197: Renaming field and providing prior field name to db_column should be an SQL noop

2021-10-18 Thread Django

#33197: Renaming field and providing prior field name to db_column should be an 
SQL
noop
-+-
 Reporter:  Jacob Walls  |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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

Re: [Django] #32956: Modernise spellings of Web, Email et al

2021-10-18 Thread Django

#32956: Modernise spellings of Web, Email et al
-+-
 Reporter:  David Smith  |Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.2
 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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"6aa917383faaa80e70c6a8a8bc0f52f088434a84" 6aa9173]:
 {{{
 #!CommitTicketReference repository=""
 revision="6aa917383faaa80e70c6a8a8bc0f52f088434a84"
 [4.0.x] Refs #32956 -- Changed docs to treat the acronym HTTP
 phonetically.

 Backport of 69b0736fad1d1f0197409ca025b7bcdf5666ae62 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/066.cf03043dd6564d409fc5873002d1e525%40djangoproject.com.

Re: [Django] #32956: Modernise spellings of Web, Email et al

2021-10-18 Thread Django

#32956: Modernise spellings of Web, Email et al
-+-
 Reporter:  David Smith  |Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.2
 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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"69b0736fad1d1f0197409ca025b7bcdf5666ae62" 69b0736]:
 {{{
 #!CommitTicketReference repository=""
 revision="69b0736fad1d1f0197409ca025b7bcdf5666ae62"
 Refs #32956 -- Changed docs to treat the acronym HTTP phonetically.
 }}}

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

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

Re: [Django] #33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to get a model

2021-10-18 Thread Django

#33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to
get a model
--+--
 Reporter:  Jonas L.  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  3.2
 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
--+--

Comment (by Mariusz Felisiak):

 Replying to [comment:5 Jonas L.]:
 > Oooh, first let me apologize for not noticing the different between an
 App.name and an App.label.
 >
 > I guess I could fix my issue by using a custom App.label, without dot.

 Yes, I proposed a small clarification, see
 [https://github.com/django/django/pull/15006 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/064.c8ec0abdbfd16b2bee83b75ecf40b469%40djangoproject.com.

Re: [Django] #33205: call_command() fails when required mutually exclusive arguments use the same `dest`.

2021-10-18 Thread Django

#33205: call_command() fails when required mutually exclusive arguments use the
same `dest`.
-+-
 Reporter:  Peter Law|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  3.2
  commands)  |
 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 Mariusz Felisiak):

 Replying to [comment:2 Hasan Ramezani]:
 > I don't know do we have to support passing both dest and arg name as
 keyword arguments? in the example of this ticket, if we call
 `management.call_command('pause', until='1')`, it should be considered as
 `until` arg or `for` (because `dest` of `for` is `until` as well)

 We should support option names as
 [https://docs.djangoproject.com/en/3.2/ref/django-
 admin/#django.core.management.call_command documented]:
 > `** options`
 > named options accepted on the command-line.
 so
 * `management.call_command('pause', until='1')` should work the same as
 calling `pause --until 1`
 * `management.call_command('pause', **{'for': '1'})` should work the same
 as calling `pause --for 1`
 * `management.call_command('pause', **{'for': '1', 'until': '1'})` should
 work the same as calling `pause --for 1 --until 1` and raise an exception

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

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

Re: [Django] #32987: Warn user if they attempt to have multiple templatetag libraries with the same name

2021-10-18 Thread Django

#32987: Warn user if they attempt to have multiple templatetag libraries with 
the
same name
-+
 Reporter:  Daniel   |Owner:  Shreya Bamne
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  template, check  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0
 * needs_docs:  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/070.aacf64341eb5253aee8d359013eeffeb%40djangoproject.com.

Re: [Django] #10060: Multiple table annotation failure

2021-10-18 Thread Django

#10060: Multiple table annotation failure
-+-
 Reporter:  svsharma@…   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (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 Matthijs Kooijman):

 For anyone else running into this, a reasonable workaround seems to be to
 use subqueries for aggregating annotations. This is a bit verbose/hacky in
 Django currently, as shown by the multitude of approaches in the
 stackoverflow link from [[comment:69|Antoine's comment]]. However, I've
 successfully used the [[https://github.com/martsberger/django-sql-utils
 |django-sql-utils]] package for this just now. That sounds a bit bulky,
 but it just has two utilities, one of which is a `SubqueryAggregate` class
 (with derived `SubqueryCount`, `SubquerySum`, etc.) that make converting a
 regular joining aggregate into a subquery aggregate easy and concise,
 without changing the structure much.

 For example taking the example from [[comment:66|comment 66]] and
 converting the second annotation to a subquery with django-sql-utils,
 you'd get:

 {{{
 Branch.objects.annotate(
 total=Sum('center__client__loan__amount'),
 
repaid=SubquerySum('center__client__loan__payment_schedule__payments__principal'),
 )
 }}}

-- 
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/081.f2bd649eb8b03b75ac8a135cbef0b98f%40djangoproject.com.

Re: [Django] #32987: Warn user if they attempt to have multiple templatetag libraries with the same name

2021-10-18 Thread Django

#32987: Warn user if they attempt to have multiple templatetag libraries with 
the
same name
-+
 Reporter:  Daniel   |Owner:  Shreya Bamne
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  template, check  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Shreya Bamne):

 Continuing on the previous work done on this ticket, here is the link to
 the new PR: https://github.com/django/django/pull/15005

-- 
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/070.11a794f9720079b6ab1d928b9665232f%40djangoproject.com.

Re: [Django] #33205: call_command() fails when required mutually exclusive arguments use the same `dest`.

2021-10-18 Thread Django

#33205: call_command() fails when required mutually exclusive arguments use the
same `dest`.
-+-
 Reporter:  Peter Law|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  3.2
  commands)  |
 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 Peter Law):

 Ah, interesting, I wasn't aware that those other spellings worked! I'd be
 happy to switch to using those spellings instead (I've confirmed they work
 for my original case).

 Perhaps just documenting this limitation (and the fact that those
 spellings work as alternatives) and/or improving the related error
 messages could be a way to go here?

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

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

Re: [Django] #33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to get a model

2021-10-18 Thread Django

#33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to
get a model
--+--
 Reporter:  Jonas L.  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  3.2
 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
--+--

Comment (by Jonas L.):

 Oooh, first let me apologize for not noticing the different between an
 App.name and an App.label.

 I guess I could fix my issue by using a custom App.label, without dot.

 My app now looks like this:
 {{{
 from pathlib import Path

 from django.apps import AppConfig

 here = Path(__file__).parent


 class LibreTimeAPIConfig(AppConfig):
 name = "libretime.api"
 label = "libretime_api"
 path = here
 verbose_name = "LibreTime API"
 default_auto_field = "django.db.models.AutoField"

 }}}

 And it seem to be working.

 Sorry again for this new comer 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/064.55c625355cde6c8f5338047037dc5ccc%40djangoproject.com.

Re: [Django] #33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to get a model

2021-10-18 Thread Django

#33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to
get a model
--+--
 Reporter:  Jonas L.  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  3.2
 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
--+--

Comment (by Jonas L.):

 > There's a Nested namespace packages example but it's not really about
 namespaces',' as in nesting that you get from folders, that we're familiar
 with from Namespaces are one honking great idea -- let's do more of
 those''

 Sorry, I am not sure I understand your comment here.

 I probably didn't explain enough my use case.

 We have few services, '''playout''', '''analyzer''', '''api''', and more.
 Only one of them is actually based on Django the '''api'''.

 Our goal is to put them into the libretime namespace so we don't collide
 with other packages/modules. This would result in '''libretime.playout''',
 '''libretime.analyzer''', '''libretime.api'''.

 The django app is still full of __init__.py files, we just wanted to wrap
 it into the namespace so we can separate the different services.

 I understood the documentation like this: "Since our django app does not
 have anything anything outside the '''libretime/api''' folder, we can put
 it in the libretime namespace.

 So based on my explanation, is it doable ? And how can we make the
 documentation less misleading, as it seem to perfectly fit my uses case ?

 Thanks for your time, and sorry if I have trouble to understand your
 answers, the question was probably too short.

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

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

Re: [Django] #33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to get a model

2021-10-18 Thread Django

#33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to
get a model
--+--
 Reporter:  Jonas L.  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  3.2
 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
--+--

Comment (by Carlton Gibson):

 PEP 420 is about being able to ''compose'' a package from code situated at
 different locations on the filesystem. These are known as ''namespace
 packages''.

 There's a [https://www.python.org/dev/peps/pep-0420/#nested-namespace-
 packages Nested namespace packages example] but it's not really about
 ''namespaces',' as in nesting that you get from folders, that we're
 familiar with from ''Namespaces are one honking great idea -- let's do
 more of those!''

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

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

Re: [Django] #33191: Avoid unnecessary clear of cached reference

2021-10-18 Thread Django

#33191: Avoid unnecessary clear of cached reference
-+-
 Reporter:  Barry Johnson|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (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 Barry Johnson):

 Changed the suggested correction based on the discussion within the
 mailing list.

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

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

Re: [Django] #33191: Avoid unnecessary clear of cached reference

2021-10-18 Thread Django

#33191: Avoid unnecessary clear of cached reference
-+-
 Reporter:  Barry Johnson|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (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
-+-
Description changed by Barry Johnson:

Old description:

> Consider this case of ORM models "Parent" and "Child", where Child has a
> foreign key reference to Parent (and the database can return generated
> IDs following insert operations):
>
> {{{
> parent = Parent(name='parent_object')
> child = Child(parent=parent)
> parent.save()
> child.save()
> print(child.parent.name)
> }}}
>
> The print statement will cause an unnecessary lazy read of the parent
> object.
>
> In the application where this behavior was first observed, the
> application was creating thousands of parent and child objects using
> bulk_create().  The subsequent lazy reads occurred when creating log
> entries to record the action, and added thousands of unwanted SELECT
> queries.
>
> Closed ticket #29497 solved a problem with potential data loss in this
> situation by essentially executing {{{child.parent_id =
> child.parent.pk}}} while preparing the child object to be saved.
> However, when the child's ForeignKeyDeferredAttrbute "parent_id" changes
> value from None to the parent's ID, the child's internal cache containing
> the reference to "parent" is cleared.  The subsequent reference to
> child.parent then must do a lazy read and reload parent from the
> database.
>
> A workaround to avoid this lazy read is to explicitly update both the
> "parent_id" and "parent" cache entry by adding this non-intuitive
> statement:
> {{{child.parent = child.parent}}}
> after executing parent.save()
>
> But it appears that a simple change could avoid clearing the cache in
> this narrow case.
> Within Model._prepare_related_fields_for_save(), replace
> {{{setattr(self, field.attname, obj.pk)}}}
> with
> {{{self.__dict__[field.attname] = obj.pk}}}
>
> This suggested code has -not- been tested.
>
> This change would set the associated "parent_id" attribute to the desired
> value without affecting the cache.  In this spot of the code, "obj" is
> currently set to the cached parent object that we want to preserve, and
> we're just reconciling the associated copy of the parent's primary key.

New description:

 Consider this case of ORM models "Parent" and "Child", where Child has a
 foreign key reference to Parent (and the database can return generated IDs
 following insert operations):

 {{{
 parent = Parent(name='parent_object')
 child = Child(parent=parent)
 parent.save()
 child.save()
 print(child.parent.name)
 }}}

 The print statement will cause an unnecessary lazy read of the parent
 object.

 In the application where this behavior was first observed, the application
 was creating thousands of parent and child objects using bulk_create().
 The subsequent lazy reads occurred when creating log entries to record the
 action, and added thousands of unwanted SELECT queries.

 Closed ticket #29497 solved a problem with potential data loss in this
 situation by essentially executing {{{child.parent_id = child.parent.pk}}}
 while preparing the child object to be saved.  However, when the child's
 ForeignKeyDeferredAttrbute "parent_id" changes value from None to the
 parent's ID, the child's internal cache containing the reference to
 "parent" is cleared.  The subsequent reference to child.parent then must
 do a lazy read and reload parent from the database.

 A workaround to avoid this lazy read is to explicitly update both the
 "parent_id" and "parent" cache entry by adding this non-intuitive
 statement:
 {{{child.parent = child.parent}}}
 after executing parent.save()

 But it appears that a simple change could avoid clearing the cache in this
 narrow case.
 Within Model._prepare_related_fields_for_save(), replace
 {{{setattr(self, field.attname, obj.pk)}}}
 with
 {{{setattr(self, field.name, obj)}}}

 This suggested code has -not- been tested.

 This change would set the associated "parent_id" attribute while ensuring
 that the currently referenced object remains referenced.

--

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

-- 
You received this message because you are subscribed to the

Re: [Django] #33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to get a model

2021-10-18 Thread Django

Comment (by Jonas L.):

Replying to [comment:1 Mariusz Felisiak]:
> Thanks for the ticket, however Django doesn't support namespace
packages, see [https://groups.google.com/g/django-
developers/c/GVHMH2ciAnk/m/vbIPbZuSBQAJ a discussion on the mailing list].
It's also

[https://docs.djangoproject.com/en/stable/topics/auth/customizing/#substituting-a
-custom-user-model documented] that `AUTH_USER_MODEL` is ''"dotted pair
describes the name of the Django app ... and the name of the Django model
that you wish to use as your user model"''.

In that case the following documentation is misleading
https://docs.djangoproject.com/en/3.2/ref/applications/#namespace-package

I understood that if I meet the requirements, using a namespace is
possible. Or maybe I didn't understand it right ?

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

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

Re: [Django] #33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to get a model (was: django.apps.apps.get_model shortcut does not allow namespaced (PEP 420) apps to get a mo

2021-10-18 Thread Django

#33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to
get a model
--+--
 Reporter:  Jonas L.  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  3.2
 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
 * component:  Uncategorized => Core (Other)


Comment:

 Thanks for the ticket, however Django doesn't support namespace packages,
 see [https://groups.google.com/g/django-
 developers/c/GVHMH2ciAnk/m/vbIPbZuSBQAJ a discussion on the mailing list].
 It's also
 
[https://docs.djangoproject.com/en/stable/topics/auth/customizing/#substituting-a
 -custom-user-model documented] that `AUTH_USER_MODEL` is ''"dotted pair
 describes the name of the Django app ... and the name of the Django model
 that you wish to use as your user model"''.

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

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

Re: [Django] #31685: Support updating conflicts with QuerySet.bulk_create().

2021-10-18 Thread Django

#31685: Support updating conflicts with QuerySet.bulk_create().
-+-
 Reporter:  Vitor Pereira|Owner:  Chih Sean
 |  Hsu
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk insert update   | Triage Stage:  Accepted
  upsert |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chih Sean Hsu):

 * 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/062.1d3089fa7456c3c76be743db619df374%40djangoproject.com.

Re: [Django] #33205: call_command() fails when required mutually exclusive arguments use the same `dest`.

2021-10-18 Thread Django

#33205: call_command() fails when required mutually exclusive arguments use the
same `dest`.
-+-
 Reporter:  Peter Law|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  3.2
  commands)  |
 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 Hasan Ramezani):

 I can create a patch to fix the two above-mentioned issues but using the
 command with both options together:

 `management.call_command('pause', **{'for': '1', 'util': '1'})`

 won't raise an error because both options use the same `dest`.

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

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

[Django] #33207: django.apps.apps.get_model shortcut does not allow namespaced (PEP 420) apps to get a model

2021-10-18 Thread Django

#33207: django.apps.apps.get_model shortcut does not allow namespaced (PEP 420)
apps to get a model
-+
   Reporter:  Jonas L.   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  3.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 The '''django.contrib.auth''' app use '''django.apps.apps.get_model''' to
 load the '''AUTH_USER_MODEL''' from the settings. While doing so it
 leverage the shortcut to provide the ''app_name.ModelName'''.

 The shortcut does not take into count that app_name can be a namespaced
 (PEP 420) app like '''my_namespace.my_app''', and that we might want to
 load a model from '''my_namespace.my_app.User'''.

 This result in the following error:
 {{{
 Traceback (most recent call last):
   File "/usr/local/lib/python3.7/dist-packages/django/db/models/utils.py",
 line 15, in make_model_tuple
 app_label, model_name = model.split(".")
 ValueError: too many values to unpack (expected 2)

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/usr/local/bin/libretime-api", line 10, in 
 sys.exit(main())
   File "/usr/local/lib/python3.7/dist-packages/libretime/api/cli.py", line
 18, in main
 execute_from_command_line(sys.argv)
   File "/usr/local/lib/python3.7/dist-
 packages/django/core/management/__init__.py", line 419, in
 execute_from_command_line
 utility.execute()
   File "/usr/local/lib/python3.7/dist-
 packages/django/core/management/__init__.py", line 395, in execute
 django.setup()
   File "/usr/local/lib/python3.7/dist-packages/django/__init__.py", line
 24, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/usr/local/lib/python3.7/dist-packages/django/apps/registry.py",
 line 114, in populate
 app_config.import_models()
   File "/usr/local/lib/python3.7/dist-packages/django/apps/config.py",
 line 301, in import_models
 self.models_module = import_module(models_module_name)
   File "/usr/lib/python3.7/importlib/__init__.py", line 127, in
 import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 1006, in _gcd_import
   File "", line 983, in _find_and_load
   File "", line 967, in
 _find_and_load_unlocked
   File "", line 677, in _load_unlocked
   File "", line 728, in exec_module
   File "", line 219, in
 _call_with_frames_removed
   File "/usr/local/lib/python3.7/dist-
 packages/django/contrib/admin/models.py", line 39, in 
 class LogEntry(models.Model):
   File "/usr/local/lib/python3.7/dist-packages/django/db/models/base.py",
 line 161, in __new__
 new_class.add_to_class(obj_name, obj)
   File "/usr/local/lib/python3.7/dist-packages/django/db/models/base.py",
 line 326, in add_to_class
 value.contribute_to_class(cls, name)
   File "/usr/local/lib/python3.7/dist-
 packages/django/db/models/fields/related.py", line 747, in
 contribute_to_class
 super().contribute_to_class(cls, name, private_only=private_only,
 **kwargs)
   File "/usr/local/lib/python3.7/dist-
 packages/django/db/models/fields/related.py", line 318, in
 contribute_to_class
 lazy_related_operation(resolve_related_class, cls,
 self.remote_field.model, field=self)
   File "/usr/local/lib/python3.7/dist-
 packages/django/db/models/fields/related.py", line 80, in
 lazy_related_operation
 return apps.lazy_model_operation(partial(function, **kwargs),
 *model_keys)
   File "/usr/local/lib/python3.7/dist-
 packages/django/db/models/fields/related.py", line 78, in 
 model_keys = (make_model_tuple(m) for m in models)
   File "/usr/local/lib/python3.7/dist-packages/django/db/models/utils.py",
 line 24, in make_model_tuple
 "must be of the form 'app_label.ModelName'." % model
 ValueError: Invalid model reference 'libretime.api.User'. String model
 references must be of the form 'app_label.ModelName'.

 }}}

 Some links:
 
https://github.com/django/django/blob/e2f778d57947d168a875159e6df075255eea4bbc/django/contrib/auth/__init__.py#L160
 
https://docs.djangoproject.com/en/3.2/ref/applications/#django.apps.apps.get_model

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit

Re: [Django] #33191: Avoid unnecessary clear of cached reference

2021-10-18 Thread Django

#33191: Avoid unnecessary clear of cached reference
-+-
 Reporter:  Barry Johnson|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (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 John Speno):

 * cc: John Speno (added)


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

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

Re: [Django] #33191: Avoid unnecessary clear of cached reference

2021-10-18 Thread Django

#33191: Avoid unnecessary clear of cached reference
-+-
 Reporter:  Barry Johnson|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (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 Carlton Gibson):

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


Comment:

 [https://groups.google.com/g/django-
 developers/c/JNCrmmSAU5Y/m/7NFUx9eTAAAJ Follow up discussion on the
 mailing list].
 Reopening based on the discussion 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/068.451c09988d0948f78afa83903cb5aae8%40djangoproject.com.

Re: [Django] #33205: call_command() fails when required mutually exclusive arguments use the same `dest`. (was: call_command fails when required mutually exclusive group arguments use the same `dest`)

2021-10-18 Thread Django

#33205: call_command() fails when required mutually exclusive arguments use the
same `dest`.
-+-
 Reporter:  Peter Law|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  3.2
  commands)  |
 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):

 * cc: Hasan Ramezani (added)
 * type:  Uncategorized => Bug
 * component:  Uncategorized => Core (Management commands)
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. The following calls work as expected for me :
 {{{#!python
 management.call_command('pause', '--until=1')
 management.call_command('pause', '--until', '1')
 management.call_command('pause', '--for=1')
 management.call_command('pause', '--for', '1')
 }}}
 however I confirmed an issue when passing arguments in keyword arguments:
 {{{
 management.call_command('pause', until='1')
 management.call_command('pause', **{'for': '1'}) # Using
 "call_command('pause', for='1')" raises SyntaxError
 }}}

 This is caused by using `dest` for mapping `**options` to arguments, see
 
[https://github.com/django/django/blob/e2f778d57947d168a875159e6df075255eea4bbc/django/core/management/__init__.py#L117-L121
 call_command()].

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

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

Re: [Django] #33172: Document CBV decoration for modifying upload handlers on the fly

2021-10-18 Thread Django

#33172: Document CBV decoration for modifying upload handlers on the fly
-+-
 Reporter:  Matthew Pava |Owner:  SREEHARI
 Type:   |  K.V
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 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:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c067a2b68fe2701608b34ac4a538e1f9dba0e9f2" c067a2b]:
 {{{
 #!CommitTicketReference repository=""
 revision="c067a2b68fe2701608b34ac4a538e1f9dba0e9f2"
 [4.0.x] Fixed #33172 -- Added example of modifying upload handlers on the
 fly for CBVs.

 Backport of e2f778d57947d168a875159e6df075255eea4bbc 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/064.40a0067cf2a3a7d1a87c860d40fdbd81%40djangoproject.com.

Re: [Django] #33172: Document CBV decoration for modifying upload handlers on the fly

2021-10-18 Thread Django

#33172: Document CBV decoration for modifying upload handlers on the fly
-+-
 Reporter:  Matthew Pava |Owner:  SREEHARI
 Type:   |  K.V
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 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:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"e2f778d57947d168a875159e6df075255eea4bbc" e2f778d5]:
 {{{
 #!CommitTicketReference repository=""
 revision="e2f778d57947d168a875159e6df075255eea4bbc"
 Fixed #33172 -- Added example of modifying upload handlers on the fly for
 CBVs.
 }}}

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

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

Re: [Django] #31503: Moving a unique constraint from unique_together to Field.unique generate an invalid migration.

2021-10-18 Thread Django

#31503: Moving a unique constraint from unique_together to Field.unique 
generate an
invalid migration.
-+-
 Reporter:  Xiang Wang   |Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  unique_together  | Triage Stage:  Accepted
  unique migrations  |
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/064.6fef689e366846867d2b83008b4e5f75%40djangoproject.com.

Re: [Django] #33172: Document CBV decoration for modifying upload handlers on the fly

2021-10-18 Thread Django

#33172: Document CBV decoration for modifying upload handlers on the fly
-+-
 Reporter:  Matthew Pava |Owner:  SREEHARI
 Type:   |  K.V
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 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 Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #33194: Remaking table with unique constraint crashes on SQLite.

2021-10-18 Thread Django

#33194: Remaking table with unique constraint crashes on SQLite.
-+-
 Reporter:  Mark |Owner:  Hannes
 |  Ljungberg
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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:"f5802a21c401b92764a9f3e2886144f3c5d77573" f5802a21]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5802a21c401b92764a9f3e2886144f3c5d77573"
 [3.2.x] Fixed #33194 -- Fixed migrations when altering a field with
 functional indexes on SQLite.

 This adjusts Expressions.rename_table_references() to only update alias
 when needed.

 Regression in 83fcfc9ec8610540948815e127101f1206562ead.

 Co-authored-by: Simon Charette 

 Backport of 86971c40909430a798e4e55b140004c4b1fb02ff 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/064.ed7a4b1992488ff3fa130eb18762f532%40djangoproject.com.

Re: [Django] #33194: Remaking table with unique constraint crashes on SQLite.

2021-10-18 Thread Django

#33194: Remaking table with unique constraint crashes on SQLite.
-+-
 Reporter:  Mark |Owner:  Hannes
 |  Ljungberg
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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:"00aa3e0b9b8fac8fa5adab47249790d2ee2f767e" 00aa3e0b]:
 {{{
 #!CommitTicketReference repository=""
 revision="00aa3e0b9b8fac8fa5adab47249790d2ee2f767e"
 [4.0.x] Fixed #33194 -- Fixed migrations when altering a field with
 functional indexes/unique constraints on SQLite.

 This adjusts Expressions.rename_table_references() to only update alias
 when needed.

 Regression in 83fcfc9ec8610540948815e127101f1206562ead.

 Co-authored-by: Simon Charette 

 Backport of 86971c40909430a798e4e55b140004c4b1fb02ff 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/064.4d92a878b87b7ab9bdc8d3e2536c81df%40djangoproject.com.

Re: [Django] #33194: Remaking table with unique constraint crashes on SQLite.

2021-10-18 Thread Django

#33194: Remaking table with unique constraint crashes on SQLite.
-+-
 Reporter:  Mark |Owner:  Hannes
 |  Ljungberg
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"86971c40909430a798e4e55b140004c4b1fb02ff" 86971c4]:
 {{{
 #!CommitTicketReference repository=""
 revision="86971c40909430a798e4e55b140004c4b1fb02ff"
 Fixed #33194 -- Fixed migrations when altering a field with functional
 indexes/unique constraints on SQLite.

 This adjusts Expressions.rename_table_references() to only update alias
 when needed.

 Regression in 83fcfc9ec8610540948815e127101f1206562ead.

 Co-authored-by: Simon Charette 
 }}}

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

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

Re: [Django] #33206: Allow redirect type choice in contrib.redirects app

2021-10-18 Thread Django

#33206: Allow redirect type choice in contrib.redirects app
-+-
 Reporter:  Niccolò Mineo|Owner:  Niccolò
 |  Mineo
 Type:  New feature  |   Status:  closed
Component:  contrib.redirects|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 This change is backward incompatible and against our stability policy. We
 also don't have a clear migration path for existing users. We should go
 back to the mailing list and reach a strong consensus before moving it
 forward.

 Closing as "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/070.c1ab5bf70cbef451a5827d856ae13c2f%40djangoproject.com.

Re: [Django] #33194: Remaking table with unique constraint crashes on SQLite.

2021-10-18 Thread Django

#33194: Remaking table with unique constraint crashes on SQLite.
-+-
 Reporter:  Mark |Owner:  Hannes
 |  Ljungberg
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/064.a9c885b1700ab31f563db56bb468365e%40djangoproject.com.

Re: [Django] #33198: BinaryField documentation references length in characters, which is incorrect

2021-10-18 Thread Django

#33198: BinaryField documentation references length in characters, which is
incorrect
---+
 Reporter:  Gavin Wahl |Owner:  Nick Frazier
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  3.2
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Mariusz Felisiak ):

 In [changeset:"fdc1c6435c8fb9e720169ef0aebf87c33f1d86c2" fdc1c64]:
 {{{
 #!CommitTicketReference repository=""
 revision="fdc1c6435c8fb9e720169ef0aebf87c33f1d86c2"
 [3.2.x] Fixed #33198 -- Corrected BinaryField.max_length docs.

 Backport of 0d4e575c96d408e0efb4dfd0cbfc864219776950 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/067.f480f2f5ce05d8aed8c66f81c2e1d742%40djangoproject.com.

Re: [Django] #33198: BinaryField documentation references length in characters, which is incorrect

2021-10-18 Thread Django

#33198: BinaryField documentation references length in characters, which is
incorrect
---+
 Reporter:  Gavin Wahl |Owner:  Nick Frazier
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  3.2
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Mariusz Felisiak ):

 In [changeset:"f5fd03aebe54f28a62436ef81aeed50fef594619" f5fd03ae]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5fd03aebe54f28a62436ef81aeed50fef594619"
 [4.0.x] Fixed #33198 -- Corrected BinaryField.max_length docs.

 Backport of 0d4e575c96d408e0efb4dfd0cbfc864219776950 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/067.dfe32589c9ef539ef269b09d4f0beddb%40djangoproject.com.

Re: [Django] #33198: BinaryField documentation references length in characters, which is incorrect

2021-10-18 Thread Django

#33198: BinaryField documentation references length in characters, which is
incorrect
---+
 Reporter:  Gavin Wahl |Owner:  Nick Frazier
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  3.2
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"0d4e575c96d408e0efb4dfd0cbfc864219776950" 0d4e575c]:
 {{{
 #!CommitTicketReference repository=""
 revision="0d4e575c96d408e0efb4dfd0cbfc864219776950"
 Fixed #33198 -- Corrected BinaryField.max_length docs.
 }}}

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

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

Re: [Django] #33194: Remaking table with unique constraint crashes on SQLite.

2021-10-18 Thread Django

#33194: Remaking table with unique constraint crashes on SQLite.
-+-
 Reporter:  Mark |Owner:  Hannes
 |  Ljungberg
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak):

 * version:  4.0 => 3.2


Comment:

 > Not really sure if we need a backport to 3.2 but feels like this would
 create issues for non-unique functional indexes on SQLite as well.

 Good catch, it's a bug in 83fcfc9ec8610540948815e127101f1206562ead.

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

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

37 matches

Mail list logo