Re: [Django] #32226: QuerySet.explain(format='json') outputs repr'd JSON on PostgreSQL

2022-04-18 Thread Django
#32226: QuerySet.explain(format='json') outputs repr'd JSON on PostgreSQL
-+-
 Reporter:  Adam Johnson |Owner:  Wu
 |  Haotian
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"f4f2afeb457429f55d6325ed557f8e92a74ee028" f4f2afeb]:
 {{{
 #!CommitTicketReference repository=""
 revision="f4f2afeb457429f55d6325ed557f8e92a74ee028"
 Refs #32226 -- Fixed JSON format of QuerySet.explain() on PostgreSQL when
 format is uppercased.

 Follow up to aba9c2de669dcc0278c7ffde7981be91801be00b.
 }}}

-- 
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/01070180407f0154-87aa3c78-960d-4b5c-bdcd-a1683dba1b5f-00%40eu-central-1.amazonses.com.


Re: [Django] #32137: Change message describing the deletion of inline objects in admin has no id available

2022-04-18 Thread Django
#32137: Change message describing the deletion of inline objects in admin has 
no id
available
-+-
 Reporter:  Vlada Macek  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  dev
 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 Mariusz Felisiak):

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


Comment:

 Replying to [comment:4 Richard Laager]:
 > I just ran into this issue. That change (with the obvious addition of
 `import copy`) works as expected. Adding a copy doesn't seem particularly
 complex to me.

 Unfortunately it's complex. Creating a deep-copy is always complicated,
 will introduce a performance regression, and can create subsequent issues
 e.g. some objects may not support creating deep copies. Please if we will
 have a reasonable proposition.

 Please first start a discussion (on the https://forum.djangoproject.com/
 or DevelopersMailingList) about a doable solutions before reopening the
 ticket. Thanks.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180407dadfd-8b1777a1-547e-425a-81b5-a37de1113b50-00%40eu-central-1.amazonses.com.


Re: [Django] #32559: Add attribute 'step' to FloatField.

2022-04-18 Thread Django
#32559: Add attribute 'step' to FloatField.
-+-
 Reporter:  Jacob Rief   |Owner:  Jacob
 |  Rief
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  FloatField,  | Triage Stage:  Accepted
  NumberInput, step  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hey Jacob. See
 [https://github.com/django/django/pull/14532#pullrequestreview-935148664
 my comment on the PR for outstanding issues]. Specifically, the docs need
 `versionchanged`/`versionadded` annotations, and (more) the new validator
 needs tests, matching those for the other validator classes.

-- 
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/01070180407c263a-a89883c7-eeef-456e-9c05-12cfad071737-00%40eu-central-1.amazonses.com.


Re: [Django] #32137: Change message describing the deletion of inline objects in admin has no id available

2022-04-18 Thread Django
#32137: Change message describing the deletion of inline objects in admin has 
no id
available
-+-
 Reporter:  Vlada Macek  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Richard Laager):

 * cc: Richard Laager (added)
 * status:  closed => new
 * has_patch:  0 => 1
 * resolution:  needsinfo =>


Comment:

 Replying to [comment:3 Mariusz Felisiak]:
 > We could create a copy of `obj` before deletion:
 > ...code snipped...
 > but I'm not sure it's worth complexity.

 I just ran into this issue. That change (with the obvious addition of
 `import copy`) works as expected. Adding a copy doesn't seem particularly
 complex to me.

 I don't see an easier way to fix it. `save_existing_objects()` takes a
 `commit` argument, but 1) passing down `commit=False` would be complicated
 (and it seems like that would end up breaking compatibility in
 `ModelAdmin.save_formset()`), 2) that probably has non-trivial
 consequences, and 3) the deletions still need to happen, so then something
 needs to do that (possibly a second call to `save_existing_objects()` with
 `commit=True`, but then we're creating another round of the first two
 concerns).

 Note that the scenario under which this occurs ("Sometimes the developer
 wishes the id to be a part of the Model.__str__.") is literally the
 default. `Model.__str__()` is:
 {{{
 def __str__(self):
 return '%s object (%s)' % (self.__class__.__name__, self.pk)
 }}}

-- 
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/0107018040652670-75ef6fae-ba80-488d-9fd2-285f9f866999-00%40eu-central-1.amazonses.com.


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

2022-04-18 Thread Django
#33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic
Foreign Key
-+-
 Reporter:  Finn Andersen|Owner:  Sarah
 |  Boyce
 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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

 * owner:  Jonny Park => Sarah Boyce


-- 
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/01070180406493a2-ccb22c98-8e5f-4d9a-b658-671d829e984d-00%40eu-central-1.amazonses.com.


Re: [Django] #33647: bulk_update silently truncating values for size limited fields

2022-04-18 Thread Django
#33647: bulk_update silently truncating values for size limited fields
-+-
 Reporter:  jerch|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 An alternative approach might to commit to dropping the whole
 `CASE`/`WHEN` wrapping altogether on backends that support it as described
 in #29771.

 We know the underlying expression construction approach performs poorly
 #31202 and the following form doesn't suffer for the type inference issue
 we're experiencing here

 {{{#!sql
 UPDATE test_model SET name = v.name
 FROM (VALUES
(1, ‘aa’),
(2, ‘bb’)
 ) AS v(id, name)
 WHERE test_model.id = v.id
 }}}

-- 
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/01070180400528d2-1a2a2e24-2df3-463c-a16f-4ef51ac9de4f-00%40eu-central-1.amazonses.com.


Re: [Django] #33649: bulk_create() with ignore_conflicts=True and ForeignKey fails

2022-04-18 Thread Django
#33649: bulk_create() with ignore_conflicts=True and ForeignKey fails
-+-
 Reporter:  Markus Friedrich |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  bulk_create  | Triage Stage:
  ForeignKey ignore_conflicts|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 > So the error is wrong in this case.

 Rows are saved in the database, but object instances don't have primary
 keys, so they are not associated with saved rows. Again, you can fix this
 by re-fetching new objects from the database before assigning them to a
 related model.

 > And in my view at least for lower level functions like bulk_create
 (which are for performance tuning) no error should be raised if its
 unclear for Django if there is really an error. Its up to the caller to
 ensure that things are right, at least for lower level functions.

 I don't agree, `bulk_create()` and `bulk_update()` are supported and
 documented APIs. I see no reason to leave users on their own in this
 particular case.

 You can start a discussion on DevelopersMailingList if you don't agree,
 where you'll reach a wider audience and see what other think. Thanks.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701803fff6111-44f7087f-52f7-4205-afc9-421de5d77e04-00%40eu-central-1.amazonses.com.


Re: [Django] #33647: bulk_update silently truncating values for size limited fields

2022-04-18 Thread Django
#33647: bulk_update silently truncating values for size limited fields
-+-
 Reporter:  jerch|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * cc: Simon Charette (added)


Comment:

 > Then only postgres is affected here?

 yep, if you set this feature flag to `False` on
 
[https://github.com/django/django/blob/6723a26e59b0b5429a0c5873941e01a2e1bdbb81/django/db/backends/postgresql/features.py#L52
 the Postgres backend] and run the `queries.test_bulk_update` you'll be
 able to see why it was added in the first place.

 > In general the broader "super" type with no constraints can be derived
 in postgres like this:
 > ...
 > Maybe it is enough to apply the super type to the cast in that line

 That could be one approach yes, we'd likely need to adapt `CAST` to allow
 for such usage though. Not sure of what the argument should be named
 though, maybe `generic` which defaults to `False`? Not sure what
 `generic=True` would mean in the case of `Cast(expr,
 ArrayField(CharField(max_length=20), generic=True)` would it be
 `::varchar[]` or `::array`.

-- 
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/010701803d6544fc-450a1bc0-740d-4bde-b0d8-b1aff461047e-00%40eu-central-1.amazonses.com.


Re: [Django] #33649: bulk_create() with ignore_conflicts=True and ForeignKey fails

2022-04-18 Thread Django
#33649: bulk_create() with ignore_conflicts=True and ForeignKey fails
-+-
 Reporter:  Markus Friedrich |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  bulk_create  | Triage Stage:
  ForeignKey ignore_conflicts|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Markus Friedrich):

 >> Why? This error message is only raised when a related object **is not
 saved**.
 > The related object **is saved** since bulk_create() is called on it.
 This save is just not recognized by Django either because
 > - the used database does not support setting the pk by bulk_create (as
 documented) or
 > - bulk_create disables the setting of the pk if ignore_conflicts=True is
 used (as documented)
 > So the error is wrong in this case. And in my view at least for lower
 level functions like bulk_create (which are for performance tuning) no
 error should be raised if its unclear for Django if there is really an
 error. Its up to the caller to ensure that things are right, at least for
 lower level functions.

-- 
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/010701803d541048-9a048f44-354a-4c45-a4af-6849b1b27ae0-00%40eu-central-1.amazonses.com.


Re: [Django] #33651: Support prefetch GenericForeignKey with custom queryset.

2022-04-18 Thread Django
#33651: Support prefetch GenericForeignKey with custom queryset.
--+
 Reporter:  elonzh|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.contenttypes  |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:  GenericForeignKey | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Simon Charette):

 * component:  Database layer (models, ORM) => contrib.contenttypes
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701803d1b07e3-f21c9ba8-1896-49ca-8be5-1e82c4f09ef9-00%40eu-central-1.amazonses.com.


Re: [Django] #33651: Support prefetch GenericForeignKey with custom queryset.

2022-04-18 Thread Django
#33651: Support prefetch GenericForeignKey with custom queryset.
-+-
 Reporter:  elonzh   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  GenericForeignKey| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 If I understand correctly you'd like to be able to have the prefetch
 querysets issued when doing
 `Node.objects.prefetch_related('content_object')` for `ItemA` and `ItemB`
 be `.objects.only('name')`.

 I've had to implement such a feature in the past and ended up with writing
 [https://gist.github.com/charettes/3dcdec3bf66257b0299455a70559f47d my
 own] `GenericForeignKeySubclass` that would allow for the following

 {{{#!python
 class Node(models.Model):
 content_type = models.ForeignKey(ContentType,
 on_delete=models.CASCADE)
 object_id = models.PositiveIntegerField()
 content_object = PrefetchedManagerGenericForeignKey("name_only",
 "content_type", "object_id")

 class AbstractNodeItem(models.Model):
 name = models.CharField(max_length=100)

 class NameOnlyManager(models.Manager):
 def get_queryset(self):
 return super().only("name")

 class ItemA(AbstractNodeItem):
 a_content = models.TextField()
 name_only = NameOnlyManager()

 class ItemB(AbstractNodeItem):
 b_content = models.TextField()
 name_only = NameOnlyManager()
 }}}

 If we were to do a proper implementation here though I think that a
 `GenericPrefetch(Prefetch)` subclass would make for a better API as that's
 the current way custom querysets are provided to the prefetching logic.
 Something along

 {{{#!python
 Node.objects.prefetch_related(
 GenericPrefetch(
 "content_object", querysets={
 ItemA: ItemA.objects.only("a"),
 ItemB: ItemB.objects.only("a"),
 }
 )
 )
 }}}

 Accepting on the basis that I think this would be a valuable 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/010701803d1ac285-a7b8f8ee-3d39-401c-84d1-5ea9bf221e0e-00%40eu-central-1.amazonses.com.


Re: [Django] #33648: Unnecessary redirect in LogoutView when ?next=... contains "unsafe" URL

2022-04-18 Thread Django
#33648: Unnecessary redirect in LogoutView when ?next=... contains "unsafe" URL
-+-
 Reporter:  Aymeric Augustin |Owner:  Aymeric
 Type:   |  Augustin
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"5591a72571b8a07c5e3d87dcfe08310bb7611d15" 5591a725]:
 {{{
 #!CommitTicketReference repository=""
 revision="5591a72571b8a07c5e3d87dcfe08310bb7611d15"
 Fixed #33648 -- Prevented extra redirect in LogoutView on invalid next
 page when LOGOUT_REDIRECT_URL is set.
 }}}

-- 
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/010701803d17c56b-1c53159e-5203-4c26-a5de-3830e3cc1acb-00%40eu-central-1.amazonses.com.


Re: [Django] #33328: Use native JS events to trigger 'formset:added'/'formset:removed'

2022-04-18 Thread Django
#33328: Use native JS events to trigger 'formset:added'/'formset:removed'
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  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
-+-

Comment (by GitHub ):

 In [changeset:"fe7cb345448822528ce0447141810c27f9e56cff" fe7cb345]:
 {{{
 #!CommitTicketReference repository=""
 revision="fe7cb345448822528ce0447141810c27f9e56cff"
 Refs #33328 -- Corrected JS check for event.detail presence in 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/010701803cd51d0d-4a83cd94-bc80-46d6-ac72-24dcf30554a4-00%40eu-central-1.amazonses.com.


Re: [Django] #33649: bulk_create() with ignore_conflicts=True and ForeignKey fails

2022-04-18 Thread Django
#33649: bulk_create() with ignore_conflicts=True and ForeignKey fails
-+-
 Reporter:  Markus Friedrich |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  bulk_create  | Triage Stage:
  ForeignKey ignore_conflicts|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 > This means with this error message you have intentionally completely
 removed the functionality to use bulk_create together with a ForeignKey on
 all databases which are not able to set the pk in bulk_create!

 Why? This error message is only raised when a related object **is not
 saved**. The current behavior of `bulk_create()` and `bulk_update()`
 reflects the `save()` behavior.

 > If this is really intended I'm OK with it and need to workaround this.
 (even thought I do not understand why there should be a data-loss problem
 in this case (with a uuid as to_field of the ForeignKey))

 As far as I'm aware there is still a data loss possibility 🤔, because the
 assigned UUID may not exists in the database at the end. We cannot
 guarantee that the assigned UUID will be stored in the database as it
 comes from an unsaved object.

 > (I also do not understand your last sentence: I do not have any already
 saved reporter in my test case (but in my real case). But as detected now
 it even fails without the ignore_conflicts, see above)

 My advise is to save `reporter` instances before attaching them to an
 `article`.

-- 
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/010701803cca0c73-1bacf381-47a8-47a1-b26e-bd75cee6807b-00%40eu-central-1.amazonses.com.


Re: [Django] #26029: Provide an API to configure arbitrary file storage backends

2022-04-18 Thread Django
#26029: Provide an API to configure arbitrary file storage backends
-+-
 Reporter:  Aymeric Augustin |Owner:  Jarosław
 |  Wygoda
 Type:  New feature  |   Status:  assigned
Component:  File |  Version:  dev
  uploads/storage|
 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 Jarosław Wygoda):

 * owner:  (none) => Jarosław Wygoda
 * 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/010701803c8d5ba5-639e7b67-500f-490c-8313-bbf1977f5e38-00%40eu-central-1.amazonses.com.


Re: [Django] #27909: Use AUTH_USER_MODEL in startproject template

2022-04-18 Thread Django
#27909: Use AUTH_USER_MODEL in startproject template
-+-
 Reporter:  David D Lowe |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Timothy Allen):

 I've issued a PR that does this and makes the configuration directory
 named `config` instead of `{{ project_name }}` here:
 https://github.com/django/django/pull/15609

 These two items have been the most frequent pain points I've run into when
 teaching newcomers.

-- 
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/010701803c7b78cd-4d4f93c1-710c-4d33-82ba-ba27a805e865-00%40eu-central-1.amazonses.com.


Re: [Django] #33649: bulk_create() with ignore_conflicts=True and ForeignKey fails

2022-04-18 Thread Django
#33649: bulk_create() with ignore_conflicts=True and ForeignKey fails
-+-
 Reporter:  Markus Friedrich |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  bulk_create  | Triage Stage:
  ForeignKey ignore_conflicts|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Markus Friedrich):

 Thanks for you very fast answer and the provided links.

 I know that ignore_conflicts=True disables setting the primary key for all
 DB's and that some DB's are not able to set the primary key using
 bulk_create at all.
 That's why the ForeignKey of Article does not use the primary key (id) of
 Reporter as to_field but used the uuid field of Reporter. This uuid field
 is unique=True and its value is a UUID4 value which is even set if the
 object is not already saved. This enables the use of bulk_create even for
 DB's which are not able to set a primary auto inc key.

 I found now that may test case even fails with the same error with >=3.2
 if ignore_conflicts is removed if a DB is used which cannot set the pk in
 bulk_create. (e.g. older sqlite3 (I have tested with sqlite3-3.27))
 This means with this error message you have intentionally completely
 removed the functionality to use bulk_create together with a ForeignKey on
 all databases which are not able to set the pk in bulk_create!
 If this is really intended I'm OK with it and need to workaround this.
 (even thought I do not understand why there should be a data-loss problem
 in this case (with a uuid as to_field of the ForeignKey))

 (I also do not understand your last sentence: I do not have any already
 saved reporter in my test case (but in my real case). But as detected now
 it even fails without the ignore_conflicts, see above)

-- 
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/010701803bccdd6e-ec065176-7d73-43b4-a2a0-9002baf39d6a-00%40eu-central-1.amazonses.com.


[Django] #33651: Support prefetch GenericForeignKey with custom queryset.

2022-04-18 Thread Django
#33651: Support prefetch GenericForeignKey with custom queryset.
-+-
   Reporter:  elonzh |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  4.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  GenericForeignKey
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 For example:


 {{{
 class Node(models.Model):
 content_type = models.ForeignKey(ContentType,
 on_delete=models.CASCADE)
 object_id = models.PositiveIntegerField()
 content_object = GenericForeignKey("content_type", "object_id")

 class AbstractNodeItem(models.Model):
 name = models.CharField(max_length=100)

 class ItemA(AbstractNodeItem):
 a_content = models.TextField()

 class ItemB(AbstractNodeItem):
 b_content = models.TextField()

 }}}

 Currently we can't list all  node with only `content_object.name`
 prefetched.

-- 
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/010701803bc1a67a-357a38a1-d62e-45f2-9483-b8fd839c7af9-00%40eu-central-1.amazonses.com.