Re: [Django] #33539: Missing space in SQL generated by PostgresIndex

[Django]

#33539: Missing space in SQL generated by PostgresIndex
-+-
 Reporter:  Anders Kaseorg   |Owner:  Anders
 Type:   |  Kaseorg
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.postgres |  Version:  3.2
 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_tests:  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/065.ba38d933c631b43016e890b31410aefb%40djangoproject.com.

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

[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 Carlton Gibson ):

 In [changeset:"981615c6b55bdd2860c6281d4521627de90274dd" 981615c]:
 {{{
 #!CommitTicketReference repository=""
 revision="981615c6b55bdd2860c6281d4521627de90274dd"
 Refs #33328 -- Added some advice regarding handling formset:added/removed
 in 3rd party libraries
 }}}

-- 
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/065.bad7d10681e804efe85da091994f3731%40djangoproject.com.

Re: [Django] #29208: Mistake in the documentation, request.POST['username'] is not working, but request.POST.get('username') is working!

[Django]

#29208: Mistake in the documentation, request.POST['username'] is not working, 
but
request.POST.get('username') is working!
--+--
 Reporter:  Marat Mkhitaryan  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Documentation |  Version:  4.0
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Carlton Gibson):

 I don't recall commenting here, but I do agree. The example is
 pedagogical… — it shows using `login()` -- making it production worthy
 would obscure the point trying to be made.

 Claude's comment:2 seems right:

 > If you use that in a context where it might not be the case, then yes,
 you should defensively use .get(). That's pure standard Python behaviour.

-- 
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.202e25eef9df9780fd098c7e477f8e10%40djangoproject.com.

Re: [Django] #33539: Missing space in SQL generated by PostgresIndex

[Django]

#33539: Missing space in SQL generated by PostgresIndex
-+-
 Reporter:  Anders Kaseorg   |Owner:  Anders
 Type:   |  Kaseorg
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.postgres |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_tests:  0 => 1


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

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

Re: [Django] #33539: Missing space in SQL generated by PostgresIndex

[Django]

#33539: Missing space in SQL generated by PostgresIndex
-+-
 Reporter:  Anders Kaseorg   |Owner:  Anders
 Type:   |  Kaseorg
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.postgres |  Version:  3.2
 Severity:  Normal   |   Resolution:
 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):

 * owner:  (none) => Anders Kaseorg
 * status:  new => assigned
 * type:  Bug => Cleanup/optimization


-- 
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/065.e2b329b6acc8af852d62aaeee5f954c6%40djangoproject.com.

Re: [Django] #33539: Missing space in SQL generated by PostgresIndex

[Django]

#33539: Missing space in SQL generated by PostgresIndex
--+
 Reporter:  Anders Kaseorg|Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  3.2
 Severity:  Normal|   Resolution:
 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 Mohamed Nabil Rady):

 * 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/065.395c1ff1b9b3167cd28108bdbb9de9e4%40djangoproject.com.

Re: [Django] #33539: Missing space in SQL generated by PostgresIndex

[Django]

#33539: Missing space in SQL generated by PostgresIndex
--+--
 Reporter:  Anders Kaseorg|Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Description changed by Anders Kaseorg:

Old description:

> If I define an index like
>
> `GinIndex("search_tsvector", fastupdate=False,
> name="zerver_message_search_tsvector")`
>
> the following output is generated by `manage.py sqlmigrate`:
>
> `CREATE INDEX "zerver_message_search_tsvector" ON "zerver_message" USING
> gin ("search_tsvector")WITH (fastupdate = off) ;`
>
> Note the missing space before `WITH`.
>
> Patch: https://github.com/django/django/pull/15459

New description:

 If I define an index like

 `GinIndex("search_tsvector", fastupdate=False,
 name="zerver_message_search_tsvector")`

 the following output is generated by `manage.py sqlmigrate`:

 `CREATE INDEX "zerver_message_search_tsvector" ON "zerver_message" USING
 gin ("search_tsvector")WITH (fastupdate = off) ;`

 Note the missing space before `WITH`. It happens that it doesn’t affect
 the behavior since it follows `)` (at least in all currently supported
 syntaxes), but it should be cleaned up anyway, so I submitted
 https://github.com/django/django/pull/15459.

--

-- 
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/065.0b9fc096e14fa9c531274b7f71fadbfa%40djangoproject.com.

[Django] #33539: Missing space in SQL generated by PostgresIndex

[Django]

#33539: Missing space in SQL generated by PostgresIndex
+
   Reporter:  Anders Kaseorg|  Owner:  (none)
   Type:  Bug   | Status:  new
  Component:  contrib.postgres  |Version:  3.2
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 If I define an index like

 `GinIndex("search_tsvector", fastupdate=False,
 name="zerver_message_search_tsvector")`

 the following output is generated by `manage.py sqlmigrate`:

 `CREATE INDEX "zerver_message_search_tsvector" ON "zerver_message" USING
 gin ("search_tsvector")WITH (fastupdate = off) ;`

 Note the missing space before `WITH`.

 Patch: https://github.com/django/django/pull/15459

-- 
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/050.e24a453ce0806f17ebc4995ecdbce6b4%40djangoproject.com.

Re: [Django] #29208: Mistake in the documentation, request.POST['username'] is not working, but request.POST.get('username') is working!

[Django]

#29208: Mistake in the documentation, request.POST['username'] is not working, 
but
request.POST.get('username') is working!
--+--
 Reporter:  Marat Mkhitaryan  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Documentation |  Version:  4.0
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Tim Graham):

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


Comment:

 There are other examples that use indexing of `request.POST`. Like
 Carlton, I don't see much advantage to making this change throughout all
 the documentation. You can write to the DevelopersMailingList if you wish
 to seek other opinions.

-- 
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.966646a50f91b0d4bf601288b591ea7f%40djangoproject.com.

Re: [Django] #33534: Formset form with initial values doesnt save

[Django]

#33534: Formset form with initial values doesnt save
-+-
 Reporter:  saschahofmann|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  formset initial  | Triage Stage:
  save   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 There's a discussion in #24541 which documented the behavior. I don't know
 that the use case is common enough to warrant a new option. A set of
 completely prefilled forms that require no input from the user seems quite
 niche.

-- 
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/071.b1a91632df4177748fef69a7aeac28b1%40djangoproject.com.

Re: [Django] #33532: Micro-optimisation: Special-case dictionaries for CaseInsensitiveMapping.

[Django]

#33532: Micro-optimisation: Special-case dictionaries for 
CaseInsensitiveMapping.
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  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):

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


Comment:

 [https://github.com/django/django/pull/15453 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/067.f7183beb47e2043cf9d5ef0b2e9d4521%40djangoproject.com.

Re: [Django] #33538: Migrations autodetector change for djangopolymorphicmodel

[Django]

#33538: Migrations autodetector change for djangopolymorphicmodel
-+-
 Reporter:  markp2   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Migrations   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 > Is there any way to resolve this and not have the migration auto
 generated?

 Unfortunately no, all auto-generated migrations should contain only no-op
 operations so no SQL statements are issued. If you're having trouble
 understanding how Django works, see
 TicketClosingReasons/UseSupportChannels for ways to get help.

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

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

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

[Django]

#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  Anssi Kääriäinen |Owner:  raydeal
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 > Should we consider making this a deprecation warning for now, and adding
 the strict validation in Django 5.x instead? (Admittedly, this isn't the
 sort of thing you can write a startup check for, so it may be that a
 deprecation warning would only help for apps that have good test coverage
 anyhow.)

 IMO deprecation is unnecessary, we raise an exception so it's not
 something can be easily missed. Also, this is undocumented behavior and as
 far as I'm aware it should be quite rare. If you think deprecation is
 necessary, please first start a discussion on the DevelopersMailingList,
 where you'll reach a wider audience and see what other think.

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

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

[Django] #33538: Migrations autodetector change for djangopolymorphicmodel

[Django]

#33538: Migrations autodetector change for djangopolymorphicmodel
-+-
   Reporter:  markp2 |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  4.0
  Migrations |
   Severity:  Normal |   Keywords:  Migrations
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 We use Django-polymorphic and now get spurious migration AlterField
 operation. We note that this is referenced in the 4.0 release notes:

 Migrations autodetector changes¶
 The migrations autodetector now uses model states instead of model
 classes. Also, migration operations for ForeignKey and ManyToManyField
 fields no longer specify attributes which were not passed to the fields
 during initialization.
 As a side-effect, running makemigrations might generate no-op AlterField
 operations for ManyToManyField and ForeignKey fields in some cases

 However, we de not understand what is a model state [vs a model class]?

 The auto-generated migration looks like this:

 {{{
 operations = [
 migrations.AlterField(
 model_name='polymorphicmodel',
 name='polymorphic_ctype',
 field=models.ForeignKey(editable=False, null=True,
 on_delete=django.db.models.deletion.CASCADE,
 related_name='polymorphic_%(app_label)s.%(class)s_set+',
 to='contenttypes.contenttype'),
 ),
 ]
 }}}

 Presumably based on our [simple] sub-class of PolymorphicModel:


 {{{
 class PolymorphicModel(poly_models.PolymorphicModel):
 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)
 if self.__class__ == PolymorphicModel:
 return
 tag = self.get_polymorphic_tag()
 if not tag and args:
 tag = args[self.get_polymorphic_tag_index() + 1]
 setattr(self, self.get_polymorphic_tag_name(), tag)

 @classmethod
 def get_polymorphic_tag(cls) -> str:
 baseclass = cls.get_polymorphic_concrete_base_model()
 assert cls.__name__.startswith(baseclass.__name__)
 return cls.__name__[len(baseclass.__name__):]

 @classmethod
 def get_polymorphic_tag_name(cls) -> str:
 i = cls.get_polymorphic_tag_index()
 return cls.get_polymorphic_base_model()._meta.fields[i + 1].name

 @classmethod
 def get_polymorphic_tag_index(cls) -> int:
 internal_fields = len(cls.get_polymorphic_internal_model_fields())
 return internal_fields + 1

 @classmethod
 def get_polymorphic_submodels(cls) -> List[Type['PolymorphicModel']]:
 baseclass = cls.get_polymorphic_concrete_base_model()
 submodels = [m for m in apps.get_models() if issubclass(m,
 baseclass) and m != baseclass]
 return submodels

 @classmethod
 def get_polymorphic_submodel(cls, tag) -> Type['PolymorphicModel']:
 models = [m for m in cls.get_polymorphic_submodels() if
 m.get_polymorphic_tag() == tag]
 return models[0]

 @classmethod
 def get_polymorphic_base_model(cls):
 raise NotImplementedError()

 @classmethod
 def get_polymorphic_concrete_base_model(cls):
 raise NotImplementedError()

 @classmethod
 def get_polymorphic_internal_model_fields(cls):
 return cls.polymorphic_internal_model_fields

 @classmethod
 def fqn(cls):
 return cls.__module__ + '.' + cls.__name__
 }}}

 Is there any way to resolve this and not have the migration auto
 generated?

-- 
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/049.3e82a083304736135ccec899b4135618%40djangoproject.com.

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

[Django]

#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  Anssi Kääriäinen |Owner:  raydeal
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Matt Westcott):

 * cc: Matt Westcott (added)


Comment:

 Ran across this while bringing Wagtail up to date with Django main. I
 appreciate that accessing a reverse-FK relation on an unsaved instance is
 undefined behaviour, so this isn't technically a breaking change -
 however, I suspect there could be a lot of code in the wild that's doing
 this unwittingly, in which case this change might be more disruptive than
 expected.

 For example, I had to make this fix:
 
https://github.com/wagtail/wagtail/pull/8028/commits/9e19bf63dbb698a4f57b131b6f8ae92bab7c2606
 - where I'd implemented something approximating an InlineFormSet, but
 neglected to make a special case for the 'create' view, and so it ends up
 querying an unsaved instance to arrive at the initial empty formset. I
 imagine this will be a fairly common gotcha in user code.

 (for the record, Wagtail also does much more esoteric things with faking
 relations on in-memory objects to support previews and saving drafts, but
 I'm willing to take the hit for that :-) )

 Should we consider making this a deprecation warning for now, and adding
 the strict validation in Django 5.x instead? (Admittedly, this isn't the
 sort of thing you can write a startup check for, so it may be that a
 deprecation warning would only help for apps that have good test coverage
 anyhow.)

-- 
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.d6563b503f09a89bbc04b9ee7266d835%40djangoproject.com.

Re: [Django] #33537: Cloning test database fails with mysql-client 8.x and older mysql-server or mariadb-server

[Django]

#33537: Cloning test database fails with mysql-client 8.x and older 
mysql-server or
mariadb-server
-+-
 Reporter:  Stephen Finucane |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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 Mariusz Felisiak):

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


Comment:

 Thanks for this ticket, however Django 2.2 doesn't officially support
 MariaDB. Moreover Django 2.2 is in extended support so it doesn't receive
 bugfixes anymore (except security issues). Please reopen this ticket if
 you can reproduce the issue on Django 4.0 (or the current `main` branch).
 I couldn't reproduce it with MySQL 8+ or MariaDB.

-- 
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.3ab737e4285507cb127518c67dce7e4a%40djangoproject.com.

Re: [Django] #28889: Use JavaScript to prevent double submission of admin forms

[Django]

#28889: Use JavaScript to prevent double submission of admin forms
-+-
 Reporter:  Manuel Saelices  |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  1.11
 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 Carlton Gibson ):

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


Comment:

 In [changeset:"fe7dbef5867c577995f0fc849d8dfdb8f2e6bbfa" fe7dbef]:
 {{{
 #!CommitTicketReference repository=""
 revision="fe7dbef5867c577995f0fc849d8dfdb8f2e6bbfa"
 Fixed #28889 -- Prevented double submission of admin forms.

 Added a JavaScript confirm() to catch double-submissions, when the
 change form has already been submitted.

 Thanks to Adam Johnson, Claude Paroz, Keryn Knight, and Thibaud Colas
 for review.
 }}}

-- 
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.1738e493ca224a429f12eae27330164f%40djangoproject.com.

[Django] #33537: Cloning test database fails with mysql-client 8.x and older mysql-server or mariadb-server

[Django]

#33537: Cloning test database fails with mysql-client 8.x and older 
mysql-server or
mariadb-server
-+-
   Reporter:  Stephen|  Owner:  nobody
  Finucane   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.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  |
-+-
 I've been seeing the following error message when attempting to run tests
 in parallel using a MySQL backend:

 {{{
 py36-django22 run-test-pre: PYTHONHASHSEED='1711093702'
 py36-django22 run-test: commands[0] | python
 /home/patchwork/patchwork/manage.py test --noinput --parallel -- patchwork
 mysqldump: Couldn't execute 'SELECT COLUMN_NAME,
 JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')
 FROM information_schema.COLUMN_STATISTICSWHERE SCHEMA_NAME
 = 'test_patchwork' AND TABLE_NAME = 'auth_group';': Unknown table
 'COLUMN_STATISTICS' in information_schema (1109)
 mysqldump: Couldn't execute 'SELECT COLUMN_NAME,
 JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')
 FROM information_schema.COLUMN_STATISTICSWHERE SCHEMA_NAME
 = 'test_patchwork' AND TABLE_NAME = 'auth_group';': Unknown table
 'COLUMN_STATISTICS' in information_schema (1109)
 System check identified no issues (0 silenced).
 Creating test database for alias 'default'...
 Cloning test database for alias 'default'...
 Cloning test database for alias 'default'...
 ...
 }}}

 This is followed by a lot of test failures due to missing databases.

 In my instance, I traced this back to the fact that I was using `mariadb-
 server` with `mysql-client` rather than `mariadb-server`. Switching the
 client packages resolved the issue. However, posts on StackOverflow
 suggest the same issue can occur when using older MySQL servers (5.7?)
 that don't provide these statistics with newer clients so it's not as
 clear cut as this.

 I'm not sure there's much to be done here from a Django perspective. We
 could arguably add the `-column-statistics=0` flag to the `mysqldump` call
 (in `django.db.backends.mysql.creation.DatabaseCreation._clone_db`), but
 this is not compatible with the version of this tool provided by `mariadb-
 client`. We might also want to make this a more serious error and fail the
 test run rather than attempt to proceed, obscuring the failure in the
 process (this could conceivably get flaky if you had a mix of DB and non-
 DB tests running in different runner instances). Perhaps the best thing to
 do here is close this and leave it here as a breadcrumb for others that
 run into the issue.

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

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

Re: [Django] #31169: Allow parallel test runner to work with Windows/macOS `spawn` process start method.

[Django]

#31169: Allow parallel test runner to work with Windows/macOS `spawn` process 
start
method.
---+---
 Reporter:  Brandon Navra  |Owner:  David Smith
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  dev
 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 Mariusz Felisiak ):

 In [changeset:"ae91ecf6a1037fb67d14841b66ac19d4c2ccc4ac" ae91ecf6]:
 {{{
 #!CommitTicketReference repository=""
 revision="ae91ecf6a1037fb67d14841b66ac19d4c2ccc4ac"
 Refs #31169 -- Added DatabaseCreation.setup_worker_connection() hook.
 }}}

-- 
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.29a143e2bb652b2cadb9dfaab064605d%40djangoproject.com.

Re: [Django] #29208: Mistake in the documentation, request.POST['username'] is not working, but request.POST.get('username') is working!

[Django]

#29208: Mistake in the documentation, request.POST['username'] is not working, 
but
request.POST.get('username') is working!
--+--
 Reporter:  Marat Mkhitaryan  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Documentation |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Mogoh Viol):

 Replying to [comment:6 Tim Graham]:
 > Maybe it's unclear that this code is for example purposes only and isn't
 meant to be copied into your project.

 That is the least that should be changed.

 But why don't just change it to a production ready working example?
 I see no downsides in changing it.

 And even if we decide to not make the example production ready, I think
 obtaining fields from a PUSH request should always check for invalid
 fields.
 The documentation should teach safe code.

-- 
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.f83234d3d8124a3de3066572ee486610%40djangoproject.com.

Re: [Django] #28889: Use JavaScript to prevent double submission of admin forms

[Django]

#28889: Use JavaScript to prevent double submission of admin forms
-+-
 Reporter:  Manuel Saelices  |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  1.11
 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 Carlton Gibson):

 * 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/067.b2575953651042eb8bad0f7805023abf%40djangoproject.com.

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

[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
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"eabc22f919e6c1774842e628400b87ac56c47bce" eabc22f9]:
 {{{
 #!CommitTicketReference repository=""
 revision="eabc22f919e6c1774842e628400b87ac56c47bce"
 Fixed #33328 -- Transformed formset:added/removed to native JS events.
 }}}

-- 
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/065.4caf071b4d899e4d5b680e838ce69538%40djangoproject.com.

Re: [Django] #33434: Browser font resizing doesn’t work in Django admin due to pixel values

[Django]

#33434: Browser font resizing doesn’t work in Django admin due to pixel values
-+-
 Reporter:  Thibaud Colas|Owner:  ravi
 |  kunwar
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  accessibility, ux,   | Triage Stage:  Ready for
  wcag, admin, css   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"1f42a352e04d2e63117f067a1432594ffbb6a8b4" 1f42a352]:
 {{{
 #!CommitTicketReference repository=""
 revision="1f42a352e04d2e63117f067a1432594ffbb6a8b4"
 Fixed #33434 -- Changed font-size in admin CSS to use rem units.
 }}}

-- 
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.0ff107359179ab25e0665147f04f54cf%40djangoproject.com.

Re: [Django] #33434: Browser font resizing doesn’t work in Django admin due to pixel values

[Django]

#33434: Browser font resizing doesn’t work in Django admin due to pixel values
-+-
 Reporter:  Thibaud Colas|Owner:  ravi
 |  kunwar
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ux,   | Triage Stage:  Ready for
  wcag, admin, css   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
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/070.f2fd5443a98e73e7908556ac1e888b63%40djangoproject.com.