Re: [Django] #28313: Add a contenttypes check to prohibit model names greater than 100 characters

[Django]

#28313: Add a contenttypes check to prohibit model names greater than 100
characters
-+-
 Reporter:  Michal Dabski|Owner:  Michal
 Type:   |  Dabski
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  1.11
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  contenttype, model,  | Triage Stage:  Accepted
  name, length, migration|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 Yes, tests are always required unless it's infeasible.

 This does not qualify for a backport based on our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy]. I don't think model names
 longer than 100 characters are common.

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.f1d540a57d3a995273449c04916ae91b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28048: Allow generic date views to use related fields as date_field

[Django]

#28048: Allow generic date views to use related fields as date_field
-+-
 Reporter:  Lefteris Nikoltsios  |Owner:  Lefteris
 |  Nikoltsios
 Type:  New feature  |   Status:  assigned
Component:  Generic views|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Lefteris Nikoltsios):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.c952fdfa4ea41694f5a61e6657acc634%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28313: Add a contenttypes check to prohibit model names greater than 100 characters

[Django]

#28313: Add a contenttypes check to prohibit model names greater than 100
characters
-+-
 Reporter:  Michal Dabski|Owner:  Michal
 Type:   |  Dabski
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  1.11
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  contenttype, model,  | Triage Stage:  Accepted
  name, length, migration|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Michal Dabski):

 Merge request:
 https://github.com/django/django/pull/8647

 Is a test case needed?
 Can this be backported to LTS?

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a32f559c01553a85ab5d3c32feed404f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28291: ArrayField cannot contain JSONField; causes SQL error

[Django]

#28291: ArrayField cannot contain JSONField; causes SQL error
--+--
 Reporter:  Richard Eames |Owner:  Zac Yauney
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  master
 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 Zac Yauney):

 * status:  new => assigned
 * owner:  (none) => Zac Yauney


--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.2e418e3ea585519a2234c052f5d30da5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27392: Remove "Tests that", "Ensures that", etc. from test docstings

[Django]

#27392: Remove "Tests that", "Ensures that", etc. from test docstings
-+-
 Reporter:  Tim Graham   |Owner:  Roman
 Type:   |  Dmytriv
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Roman Dmytriv):

 * status:  new => assigned
 * owner:  (none) => Roman Dmytriv


--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.58599bb8712ad33c1167f1d456c9d963%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28313: Add a contenttypes check to prohibit model names greater than 100 characters

[Django]

#28313: Add a contenttypes check to prohibit model names greater than 100
characters
-+-
 Reporter:  Michal Dabski|Owner:  Michal
 Type:   |  Dabski
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  1.11
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  contenttype, model,  | Triage Stage:  Accepted
  name, length, migration|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Michal Dabski):

 * owner:  nobody => Michal Dabski
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.78ca2c77dea62fcec01443a0d7135202%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25530: Deferred SQL operations fail when a referenced table or column is renamed or deleted during the same migration

[Django]

#25530: Deferred SQL operations fail when a referenced table or column is 
renamed
or deleted during the same migration
---+--
 Reporter:  Simon Philips  |Owner:  Simon Charette
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  master
 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
---+--
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #23268: Fixtures: Natural Key support for Generic Foreign Keys

[Django]

#23268: Fixtures: Natural Key support for Generic Foreign Keys
-+-
 Reporter:  Anshuman Aggarwal|Owner:  Guillaume
 |  Thomas
 Type:  Bug  |   Status:  assigned
Component:  Core |  Version:  1.6
  (Serialization)|
 Severity:  Normal   |   Resolution:
 Keywords:  natural generic  | Triage Stage:  Accepted
  fixtures   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


Comment:

 As I mentioned on the pull request, it doesn't seem like a good separation
 of concerns to modify the "core" serializers for a "contrib" field.
 Unfortunately, I haven't studied the problem enough to suggest an
 alternate solution.

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.60ae6da5d200b4de007488d586eba581%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28304: pgettext should return SafeData if both `message` and `context` are instances of SafeData

[Django]

#28304: pgettext should return SafeData if both `message` and `context` are
instances of SafeData
-+-
 Reporter:  Artem Polunin|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 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 Claude Paroz ):

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


Comment:

 In [changeset:"ceca221b31a38b01ee951fab82d5dc1c200c27b4" ceca221b]:
 {{{
 #!CommitTicketReference repository=""
 revision="ceca221b31a38b01ee951fab82d5dc1c200c27b4"
 Fixed #28304 -- Kept SafeData type for pgettext-translated strings
 }}}

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.6d672ad7947c2eac1393dfb1888e4fe9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28312: ModelChoiceIterator uses cached length of queryset.

[Django]

#28312: ModelChoiceIterator uses cached length of queryset.
+--
 Reporter:  Sjoerd Job Postmus  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.8
 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 Sjoerd Job Postmus):

 Perhaps this can be closed, as (our specific case) is resolved by #27563.
 My apologies.

 Extra context:

 We ran into this problem as our form contained logic as follows:

 {{{
 if len(self.fields['status'].choices) <= 1:
 self.fields.pop('status')
 }}}

 I tested this: count = 1: no field. Add a `Status`, reload page: still no
 field. Turns out the count was being "cached". Since it is a Django 1.8
 project, above fix is not taken into account, and the cached value did
 indeed live longer than the current request. Looking at the changes, I
 expect the behaviour to be correct in Django 2.0.

 Even so: the `ModelChoiceIterator` uses `.all()` or `.iterator()` in the
 `__iter__` method, and thus forces obtaining a fresh value. But `__len__`
 does not do so, and that is an inconsistency that might still qualify as a
 bug.

 Are there any plans to backport #27563 to Django 1.8? I expect not, as
 it's past the "End of mainstream support".

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f321e29552862dac39afe6daad7b3f25%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28312: ModelChoiceIterator uses cached length of queryset.

[Django]

#28312: ModelChoiceIterator uses cached length of queryset.
+--
 Reporter:  Sjoerd Job Postmus  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.8
 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 Sjoerd Job Postmus):

 The following two tests that show how I would expect the
 `ModelMultipleChoiceField` to work. The first tests `__iter__` (and
 works), the second tests `__len__` (and fails: `AssertionError: 3 != 4`).

 {{{
 diff --git a/tests/model_forms/tests.py b/tests/model_forms/tests.py
 index c85eb2a..3c6241d 100644
 --- a/tests/model_forms/tests.py
 +++ b/tests/model_forms/tests.py
 @@ -1992,6 +1992,27 @@ class ModelMultipleChoiceFieldTests(TestCase):
  form = ArticleCategoriesForm(instance=article)
  self.assertCountEqual(form['categories'].value(), [self.c2.slug,
 self.c3.slug])

 +def test_added_fields_gets_rendered(self):
 +f = forms.ModelMultipleChoiceField(Category.objects.all())
 +self.assertEqual(list(f.choices), [
 +(self.c1.pk, 'Entertainment'),
 +(self.c2.pk, "It's a test"),
 +(self.c3.pk, 'Third')])
 +c4 = Category.objects.create(
 +name="Now you see me", slug="now", url="added")
 +self.assertEqual(list(f.choices), [
 +(self.c1.pk, 'Entertainment'),
 +(self.c2.pk, "It's a test"),
 +(self.c3.pk, 'Third'),
 +(c4.pk, 'Now you see me')])
 +
 +def test_added_fields_gets_counted(self):
 +f = forms.ModelMultipleChoiceField(Category.objects.all())
 +self.assertEqual(len(f.choices), 3)
 +c4 = Category.objects.create(
 +name="Now you see me", slug="now", url="added")
 +self.assertEqual(len(f.choices), 4)
 +

  class ModelOneToOneFieldTests(TestCase):
  def test_modelform_onetoonefield(self):
 }}}

 This means that the "invariant" that `len(f.choices) ==
 len(list(f.choices))` does not hold.

 In particular: note that (currently) the value is calculated just once:
 the first time `__len__` is called. This caching is not limited to 'per
 request', but is cached for the lifetime of the process handling requests.

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.61efd7585181757bd7e02a215427c251%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28305: AlterField migration tries to alter column that still has a foreign key contraint

[Django]

#28305: AlterField migration tries to alter column that still has a foreign key
contraint
-+-
 Reporter:  Andreas Backx|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mysql,   | Triage Stage:
  onetoonefield, utf8mb4, foreign|  Unreviewed
  key|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * cc: Markus Holtermann (added)


Comment:

 Bisected to 45ded053b1f4320284aa5dac63052f6d1baefea9,  Fixed #27666 --
 Delayed rendering of recursivly related models in migration operations.

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.0fe276d2bda32ba92ab7d72c06e3a045%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28309: Migration bug in related_name for ManyToManyField with self

[Django]

#28309: Migration bug in related_name for ManyToManyField with self
-+-
 Reporter:  Ahmed Mohamed|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  ManyToManyField  | Triage Stage:
  self   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> The related_name is not set correctly on ManyToManyField when it is
> related with 'self'. When I use the model name explicitly, it is set
> correctly.
>

> {{{
> class Model1(models.Model):
> children = models.ManyToManyField('self', blank=True,
> related_name='parents')
>
> class Model2(models.Model):
> children = models.ManyToManyField('self', blank=True,
> related_name='parents')
> }}}
>

> {{{
> migrations.CreateModel(
> name='Model1',
> fields=[
> ('id', models.AutoField(auto_created=True, primary_key=True,
> serialize=False, verbose_name='ID')),
> ('children', models.ManyToManyField(blank=True,
> related_name='_model1_children_+', to='raftprot.Model1')),
> ],
> ),
> migrations.CreateModel(
> name='Model2',
> fields=[
> ('id', models.AutoField(auto_created=True, primary_key=True,
> serialize=False, verbose_name='ID')),
> ('children', models.ManyToManyField(blank=True,
> related_name='parents', to='raftprot.Model2')),
> ],
> ),
> }}}

New description:

 The related_name is not set correctly on ManyToManyField when it is
 related with 'self'. When I use the model name explicitly, it is set
 correctly.


 {{{
 class Model1(models.Model):
 children = models.ManyToManyField('self', blank=True)

 class Model2(models.Model):
 children = models.ManyToManyField('self', blank=True,
 related_name='parents')
 }}}


 {{{
 migrations.CreateModel(
 name='Model1',
 fields=[
 ('id', models.AutoField(auto_created=True, primary_key=True,
 serialize=False, verbose_name='ID')),
 ('children', models.ManyToManyField(blank=True,
 related_name='_model1_children_+', to='raftprot.Model1')),
 ],
 ),
 migrations.CreateModel(
 name='Model2',
 fields=[
 ('id', models.AutoField(auto_created=True, primary_key=True,
 serialize=False, verbose_name='ID')),
 ('children', models.ManyToManyField(blank=True,
 related_name='parents', to='raftprot.Model2')),
 ],
 ),
 }}}

--

Comment (by Tim Graham):

 I've edited the ticket description as I think you meant, please correct it
 if needed. If the unexpected output in the migration is
 `related_name='_model1_children_+'`, that's coming from
 
[https://github.com/django/django/blob/a6b5321ce997b899e540bb427cca98cb2b93a106/django/db/models/fields/related.py#L1531-L1546
 ManyToManyField.contribute_to_class()]. I'm uncertain if this is a bug.
 Can you please clarify?

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2d26ec44ba20835577d7afe4ce21b1f9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28176: Expose real (i.e. not converted to string) value in widget option context

[Django]

#28176: Expose real (i.e. not converted to string) value in widget option 
context
+
 Reporter:  Moritz Sichert  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

 On the PR for #28303
 [https://github.com/django/django/pull/8639#issuecomment-308612817 John
 suggested], "If this lands, the option's input's value could be added to
 the attrs dict in `Widget.create_option()`, then value could resume to be
 the actual value, not the coerced value." I implemented that idea in the
 second commit of a [https://github.com/django/django/pull/8646 PR], then
 simplified things to what I think is a simpler approach in the third
 commit.

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.389670395b3f1e1fc9202860065fc330%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27863: Implement "SameSite" flag for session and CSRF cookies

[Django]

#27863: Implement "SameSite" flag for session and CSRF cookies
---+--
 Reporter:  Alex Gaynor|Owner:  shangdahao
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by shangdahao):

 * owner:  Paweł Krawczyk => shangdahao


--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.5dcc6da938d045bf892978bb9d7b848e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27863: Implement "SameSite" flag for session and CSRF cookies

[Django]

#27863: Implement "SameSite" flag for session and CSRF cookies
---+
 Reporter:  Alex Gaynor|Owner:  (none)
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by hui shang):

 * status:  assigned => new
 * owner:  hui shang => (none)


--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.9f0aa359c7a7288ed652fde96d6e559d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28314: Quote error in static tag documentation (was: Quote error in documentation)

[Django]

#28314: Quote error in static tag documentation
+--
 Reporter:  Christian González  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Documentation   |  Version:  1.11
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--
Changes (by Tim Graham):

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


Comment:

 This works fine as far as I know. What error do you get?

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.687f082ff2fbf6310d2f6a33f5f9811e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28314: Quote error in documentation

[Django]

#28314: Quote error in documentation
--+
   Reporter:  Christian González  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Documentation   |Version:  1.11
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+
 On https://docs.djangoproject.com/en/dev/howto/static-files/, "Configuring
 static files", 3. in the example, there is a template line:

 {{{
 
 }}}

 This is not working, as the " are set wrong. What would work is using
 single quotes for the inner string:
 {{{
 
 }}}

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.4e954ce883afbb4c61a63c8c898569a3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28313: Add a contenttypes check to prohibit model names greater than 100 characters (was: Model name length is not enforced or validated)

[Django]

#28313: Add a contenttypes check to prohibit model names greater than 100
characters
-+-
 Reporter:  Michal Dabski|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:   |  Version:  1.11
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  contenttype, model,  | Triage Stage:  Accepted
  name, length, migration|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.53b0907baa990a55607c0fba6c0b65b9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28313: Model name length is not enforced or validated

[Django]

#28313: Model name length is not enforced or validated
-+-
 Reporter:  Michal Dabski|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:   |  Version:  1.11
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  contenttype, model,  | Triage Stage:  Accepted
  name, length, migration|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * stage:  Unreviewed => Accepted


Comment:

 I guess we could add a `django.contrib.contenttypes` system check for
 that.

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

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

Re: [Django] #28310: form RangeFields should treat (None, None) as Range(None, None) rather than None (was: (form) RangeFields should handle (None, None) better.)

[Django]

#28310: form RangeFields should treat (None, None) as Range(None, None) rather 
than
None
---+--
 Reporter:  Matthew Schinckel  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.postgres   |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

 * component:  Uncategorized => contrib.postgres
 * type:  Uncategorized => Bug


Old description:

> When you clean a RangeField, and pass it in ('', ''), or (None, None), it
> falls through to the MultiValueField handling, which, when all values are
> empty, treats the cleaned value as empty.
>
> https://github.com/django/django/blob/master/django/forms/fields.py#L992
>
> Thus:
>

> {{{
> FloatRangeField().clean([None, None])
> }}}
>
> returns `None`, when it really should return FloatRange(None, None).
>
> There is a very large difference between these.

New description:

 When you clean a `RangeField` and pass it in `('', '')`, or `(None,
 None)`, it falls through to the `MultiValueField` handling, which, when
 all values are empty,
 
[https://github.com/django/django/blob/a6b5321ce997b899e540bb427cca98cb2b93a106/django/forms/fields.py#L992
 treats the cleaned value as empty].

 Thus, `FloatRangeField().clean([None, None])` returns `None`, when it
 really should return `FloatRange(None, None)`.

 There is a very large difference between these.

--

Comment:

 I'm not sure -- could you elaborate on the use case? How can you submit a
 `[None, None]` value in an HTML form (or are you also advocating
 transforming `['', '']` to `Range(None, None)`)?

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e0e27975316f5146ff5e9cd5d9e1ece9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28309: Migration bug in related_name for ManyToManyField with self

[Django]

#28309: Migration bug in related_name for ManyToManyField with self
-+-
 Reporter:  Ahmed Mohamed|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  ManyToManyField  | Triage Stage:
  self   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I think there's a mistake in the ticket description. The two `children`
 fields in the models are identical.

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6560daa654e2f43a064a6b3ce664eb5c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28304: pgettext should return SafeData if both `message` and `context` are instances of SafeData

[Django]

#28304: pgettext should return SafeData if both `message` and `context` are
instances of SafeData
-+-
 Reporter:  Artem Polunin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.c15431b829978274f13d221cd5662d33%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28312: ModelChoiceIterator uses cached length of queryset.

[Django]

#28312: ModelChoiceIterator uses cached length of queryset.
+--
 Reporter:  Sjoerd Job Postmus  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham):

 * component:  Uncategorized => Forms


Comment:

 I don't understand the "bug" aspect to the report. Can you give a test
 case that demonstrates incorrect behavior?

 I understand the point about memory consumption. I guess switching to
 `count()` might be better, although it adds a query and could require some
 adapting of `assertNumQueries()` tests (there is one test in Django's
 `model_forms` tests that breaks in this way).

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ac81b4f8307a1cd5f77463d599d03deb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28311: Ability to specify field querysets in ModelForm constructor

[Django]

#28311: Ability to specify field querysets in ModelForm constructor
+--
 Reporter:  Pascal Briet|Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  Forms   |  Version:  1.11
 Severity:  Normal  |   Resolution:  wontfix
 Keywords:  modelform queryset  | 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:

 I don't see a need to add an alternate way of doing this. In my opinion,
 it could lead to a slippery slope with proposals to add all sorts of all
 other form customization options in `ModelForm.__init__()`. Also, I feel
 the logic really does belong in the form, not in the view (or wherever the
 form is initialized).

 Feel free to propose the idea on the DevelopersMailingList if you disagree
 with my assessment.

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.3dc8ab05d59f667fd5080967198f151d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28313: Model name length is not enforced or validated

[Django]

#28313: Model name length is not enforced or validated
-+-
 Reporter:  Michal Dabski|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:   |  Version:  1.11
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  contenttype, model,  | Triage Stage:
  name, length, migration|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Michal Dabski):

 * version:  1.8 => 1.11


--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.78dad9ce9597a1d94b932f62dbe01436%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28313: Model name length is not enforced or validated

[Django]

#28313: Model name length is not enforced or validated
-+-
 Reporter:  Michal Dabski|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:   |  Version:  1.8
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  contenttype, model,  | Triage Stage:
  name, length, migration|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Michal Dabski:

Old description:

> When creating a model with name longer than 100 characters, {{{migrate}}}
> will fail with the following trace:
> {{{
> Traceback (most recent call last):
>   File "C:/Users/Mick/Desktop/Projects/django/meg-forms/manage.py", line
> 14, in 
> execute_from_command_line(sys.argv)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\core\management\__init__.py", line 363, in
> execute_from_command_line
> utility.execute()
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\core\management\__init__.py", line 355, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\core\management\base.py", line 283, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\core\management\base.py", line 330, in execute
> output = self.handle(*args, **options)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\core\management\commands\migrate.py", line 227, in handle
> self.verbosity, self.interactive, connection.alias,
> apps=post_migrate_apps, plan=plan,
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\core\management\sql.py", line 53, in
> emit_post_migrate_signal
> **kwargs
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\dispatch\dispatcher.py", line 193, in send
> for receiver in self._live_receivers(sender)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\contrib\auth\management\__init__.py", line 63, in
> create_permissions
> ctype = ContentType.objects.db_manager(using).get_for_model(klass)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\contrib\contenttypes\models.py", line 60, in
> get_for_model
> model=opts.model_name,
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\manager.py", line 85, in manager_method
> return getattr(self.get_queryset(), name)(*args, **kwargs)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\query.py", line 466, in get_or_create
> return self._create_object_from_params(lookup, params)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\query.py", line 498, in
> _create_object_from_params
> obj = self.create(**params)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\query.py", line 394, in create
> obj.save(force_insert=True, using=self.db)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\base.py", line 806, in save
> force_update=force_update, update_fields=update_fields)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\base.py", line 836, in save_base
> updated = self._save_table(raw, cls, force_insert, force_update,
> using, update_fields)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\base.py", line 922, in _save_table
> result = self._do_insert(cls._base_manager, using, fields, update_pk,
> raw)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\base.py", line 961, in _do_insert
> using=using, raw=raw)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\manager.py", line 85, in manager_method
> return getattr(self.get_queryset(), name)(*args, **kwargs)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\query.py", line 1063, in _insert
> return query.get_compiler(using=using).execute_sql(return_id)
>   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
> packages\django\db\models\sql\compiler.py"

[Django] #28313: Model name length is not enforced or validated

[Django]

#28313: Model name length is not enforced or validated
-+-
   Reporter:  Michal |  Owner:  nobody
  Dabski |
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  1.8
  contrib.contenttypes   |   Keywords:  contenttype, model,
   Severity:  Normal |  name, length, migration
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When creating a model with name longer than 100 characters, {{{migrate}}}
 will fail with the following trace:
 {{{
 Traceback (most recent call last):
   File "C:/Users/Mick/Desktop/Projects/django/meg-forms/manage.py", line
 14, in 
 execute_from_command_line(sys.argv)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\core\management\__init__.py", line 363, in
 execute_from_command_line
 utility.execute()
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\core\management\__init__.py", line 355, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\core\management\base.py", line 283, in run_from_argv
 self.execute(*args, **cmd_options)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\core\management\base.py", line 330, in execute
 output = self.handle(*args, **options)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\core\management\commands\migrate.py", line 227, in handle
 self.verbosity, self.interactive, connection.alias,
 apps=post_migrate_apps, plan=plan,
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\core\management\sql.py", line 53, in
 emit_post_migrate_signal
 **kwargs
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\dispatch\dispatcher.py", line 193, in send
 for receiver in self._live_receivers(sender)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\contrib\auth\management\__init__.py", line 63, in
 create_permissions
 ctype = ContentType.objects.db_manager(using).get_for_model(klass)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\contrib\contenttypes\models.py", line 60, in get_for_model
 model=opts.model_name,
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\manager.py", line 85, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\query.py", line 466, in get_or_create
 return self._create_object_from_params(lookup, params)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\query.py", line 498, in
 _create_object_from_params
 obj = self.create(**params)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\query.py", line 394, in create
 obj.save(force_insert=True, using=self.db)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\base.py", line 806, in save
 force_update=force_update, update_fields=update_fields)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\base.py", line 836, in save_base
 updated = self._save_table(raw, cls, force_insert, force_update,
 using, update_fields)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\base.py", line 922, in _save_table
 result = self._do_insert(cls._base_manager, using, fields, update_pk,
 raw)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\base.py", line 961, in _do_insert
 using=using, raw=raw)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\manager.py", line 85, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\query.py", line 1063, in _insert
 return query.get_compiler(using=using).execute_sql(return_id)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\models\sql\compiler.py", line 1099, in execute_sql
 cursor.execute(sql, params)
   File "C:\Users\Mick\Desktop\Projects\django\meg-forms\lib\site-
 packages\django\db\backend

[Django] #28312: ModelChoiceIterator uses cached length of queryset.

[Django]

#28312: ModelChoiceIterator uses cached length of queryset.
--+
   Reporter:  Sjoerd Job Postmus  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Uncategorized   |Version:  1.8
   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   |
--+
 In Django 1.8 (but also master), `ModelChoiceIterator` has the following
 implementation:

 {{{
 class ModelChoiceIterator:
 def __init__(self, field):
 self.field = field
 self.queryset = field.queryset

 def __iter__(self):
 if self.field.empty_label is not None:
 yield ("", self.field.empty_label)
 queryset = self.queryset.all()
 # Can't use iterator() when queryset uses prefetch_related()
 if not queryset._prefetch_related_lookups:
 queryset = queryset.iterator()
 for obj in queryset:
 yield self.choice(obj)

 def __len__(self):
 return (len(self.queryset) + (1 if self.field.empty_label is not
 None else 0))

 def choice(self, obj):
 return (self.field.prepare_value(obj),
 self.field.label_from_instance(obj))
 }}}

 As can be seen, `__iter__` actually does a `.all()` to make sure it gets
 fresh results. However, `__len__` does not. Also: it currently caches all
 objects inside `self.queryset`, only releasing them again on shutdown
 which might be problematic if there are a lot of results (or even a few
 "large" results).

 Suggested implementation

 {{{
 def __len__(self):
 return self.queryset.count() + (1 if self.field.empty_label is not
 None else 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.73d125547a8a71124fc821e4502de92c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28311: Ability to specify field querysets in ModelForm constructor

[Django]

#28311: Ability to specify field querysets in ModelForm constructor
-+-
   Reporter:  Pascal |  Owner:  nobody
  Briet  |
   Type:  New| Status:  new
  feature|
  Component:  Forms  |Version:  1.11
   Severity:  Normal |   Keywords:  modelform queryset
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi,

 There is a common problematic I often encounter : Displaying a ModelForm
 with foreignkeys (ModelChoiceField) requiring sub-querysets.

 e.g., I have a `Restaurant` model, that I first create in a `Country`
 (`Restaurant::country`). Then, in a form, I want to specify a `City`
 (`Restaurant::city`).

 I do not want to display all the cities from all the world, but only the
 cities from the pre-selected country. (please note that the subselection
 logic might be more complex in many cases).

 Usually, you do the following in Django :

 {{{

 class RestaurantForm(forms.ModelForm):
 class Meta:
 model = Restaurant
 fields = ['name', 'city']

 def __init__(self, *args, **kargs):
  super().__init__(*args, **kargs)
  self.fields['city'].queryset =
 City.objects.filter(country=self.fields['country'])

 my_form = RestaurantForm(instance=restaurant)
 }}}

 It works, but it looks to me rather complicated for such a common use
 (especially for beginners).
 Would it be possible to pass through the Form contructor a dictionary of
 querysets that would replace the default ones ?

 {{{
 my_form = RestaurantForm(instance=restaurant, field_querysets={'city':
 City.objects.filter(country=restaurant.country)}
 }}}

 Does it make sense ? It doesn't invalidate the first approach. The classic
 way bounds the logic to the form itself - which is very handy - but I
 believe the suggested way would make Django more accessible to newbies.

 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.281714481dde7b64eb943276c10fb476%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.