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:  Internationalization  |  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
--+

Comment (by Artem Polunin):

 Replying to [comment:1 Tim Graham]:
 > Seems okay at first glance, although I'm not a translations expert.
 Perhaps it would suffice to mark `CONTEXT_SEPARATOR` as safe?
 It won't help, because `"%s" % ...` always evaluates to `str`:
 {{{
 >>> from django.utils.safestring import SafeText
 >>> type("%s%s%s" % (SafeText('context'), SafeText('separator'),
 SafeText('message')))
 
 }}}

--
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.3e01c6cdd123e1d2918663a8c50027cd%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
-+-

Comment (by Tim Graham):

 A starting point would be to
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/#bisecting-a-regression bisect] to find the commit where the
 behavior changed. If writing a test for Django's test suite is too
 difficult for you, you can always bisect manually using your test project.

--
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.91d8b6edd67399504ab2e934986a3295%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28306: Complete test coverage for django/utils/lorem_ipsum.py (was: Added tests in tests_lorem_ipsum.py)

[Django]

#28306: Complete test coverage for django/utils/lorem_ipsum.py
--+
 Reporter:  Idan Melamed  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:  Testing, lorem ipsum  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted
 * component:  Testing framework => Utilities


Comment:

 See [https://docs.djangoproject.com/en/dev/internals/contributing/writing-
 code/working-with-git/ Working with Git and GitHub] if you need help with
 that. The branch name isn't important but see the PatchReviewChecklist for
 things to check.

 You can create two pull requests, one for the additional test and one for
 code refactorings.

--
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.6cfda901df9b562cc8da941253eec442%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27434: Document caveats of raising a ValidationError in Model.clean() for a field not in a model form

[Django]

#27434: Document caveats of raising a ValidationError in Model.clean() for a 
field
not in a model form
-+-
 Reporter:  Matthias Kestenholz  |Owner:  Matthias
 Type:   |  Kestenholz
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"a1c6c220e2ac86a74869d0017cd658115cc4ad7b" a1c6c220]:
 {{{
 #!CommitTicketReference repository=""
 revision="a1c6c220e2ac86a74869d0017cd658115cc4ad7b"
 [1.11.x] Fixed #27434 -- Doc'd how to raise a model validation error for a
 field not in a model form.

 Backport of e8c056c31a5b353e7b50a405c00db12c28f4a756 from master
 }}}

--
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.5bd4e9a452672439b899c1ea5cd4a3ac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27434: Document caveats of raising a ValidationError in Model.clean() for a field not in a model form

[Django]

#27434: Document caveats of raising a ValidationError in Model.clean() for a 
field
not in a model form
-+-
 Reporter:  Matthias Kestenholz  |Owner:  Matthias
 Type:   |  Kestenholz
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 ):

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


Comment:

 In [changeset:"e8c056c31a5b353e7b50a405c00db12c28f4a756" e8c056c]:
 {{{
 #!CommitTicketReference repository=""
 revision="e8c056c31a5b353e7b50a405c00db12c28f4a756"
 Fixed #27434 -- Doc'd how to raise a model validation error for a field
 not in a model form.
 }}}

--
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.15934e4eef1b277931cd144a4f8bff02%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27161: TypedChoiceField fails to validate properly when used with ArrayField

[Django]

#27161: TypedChoiceField fails to validate properly when used with ArrayField
-+-
 Reporter:  Roman Karpovich  |Owner:  Rômulo
 |  Rosa Furtado
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  TypedChoiceField | 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 ):

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


Comment:

 In [changeset:"9dd244394236388c3479ab202a0ec31055f7ec09" 9dd2443]:
 {{{
 #!CommitTicketReference repository=""
 revision="9dd244394236388c3479ab202a0ec31055f7ec09"
 Fixed #27161 -- Fixed form validation when an ArrayField's base_field has
 choices.
 }}}

--
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/063.ea2e53f4c79506bf3e3e8c3274abde2a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28307: Add more stub files in startapp template (was: Cleaner app template)

[Django]

#28307: Add more stub files in startapp template
-+-
 Reporter:  Mark |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  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/063.5086269bf38b7cb5bb8a5d265c3bd9a3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28307: Cleaner app template

[Django]

#28307: Cleaner app template
-+-
 Reporter:  Mark |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 Tim Graham):

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


Comment:

 You can raise the idea on the DevelopersMailingList but past discussions
 (search that mailing list's archives for "startapp" and "startproject") to
 add files or reorganize has not yielded consensus about it -- that's why
 there's an option for custom project/app templates. The Django master
 branch no longer suppots Python 2, so `# coding: utf-8` would be obsolete.

--
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/063.863e6e4fda08c23e0db126311a2c9c9f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27161: TypedChoiceField fails to validate properly when used with ArrayField

[Django]

#27161: TypedChoiceField fails to validate properly when used with ArrayField
-+-
 Reporter:  Roman Karpovich  |Owner:  Rômulo
 |  Rosa Furtado
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  TypedChoiceField | 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):

 * needs_better_patch:  1 => 0


Comment:

 An alternate [https://github.com/django/django/pull/8311 PR] adds
 `ArrayField.clean()` that calls `base_field.clean()`.

--
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/063.532331cbbaa42d0877d9ebdfcc2fc1fd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28307: Cleaner app template

[Django]

#28307: Cleaner app template
-+-
   Reporter:  Mark   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Core   |Version:  master
  (Management commands)  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I find that the standard django app template (the one used by the
 `startapp` command) is a little bit "messy" and it seems to me that
 encourages not-so-clean architectures for the apps.

 This is what I suggest:
 * A separate `forms.py` file (to discourage keeping form classes in
 `views.py` file)
 * Separate `middleware.py` and `mixins.py` files (for the same reason as
 above, and to make the third party app architectures more similar to
 django itself, with less doubts for the developer)
 * A separate `urls.py` file (this is another file I find always creating
 myself just after the app creation)
 * Refactor `tests.py` in a `tests` module, also to encourage modularity of
 the testsuite instead of creating a mammoth `tests.py` file by adding
 "just one more test case" and avoiding the hassle of refactoring the whole
 thing after some development

 I forked the django project on github and created a branch in my
 repository, here: https://github.com/mcagl/django/tree/mcagl/better-
 startapp-template

 The branch does not conflict with the `master` branch

--
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/048.03775e10243177884717b2d3cc42b730%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24018: Support journal_mode=WAL for sqlite

[Django]

#24018: Support journal_mode=WAL for sqlite
-+-
 Reporter:  Curtis Maloney   |Owner:  Curtis
 |  Maloney
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 tonnzor):

 As a workaround, you could use https://stackoverflow.com/a/6843199 (use
 `connection_created` signal)

--
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.3cd05de0d946bd1580ebc4c99b9d4152%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24018: Support journal_mode=WAL for sqlite

[Django]

#24018: Support journal_mode=WAL for sqlite
-+-
 Reporter:  Curtis Maloney   |Owner:  Curtis
 |  Maloney
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 tonnzor):

 Any progress here?

 We could add `init_command` to `OPTIONS` for sqlite backend like for
 MySQL.

 Then you would be able to use any PRAGMA we need:

 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
 'OPTIONS': {
 'init_command': 'PRAGMA journal_mode=wal;',
 }
 }
 }
 }}}

--
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.f680dc79deba136e865d6ee16d8b47f4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17962: Add ModelAdmin.get_deleted_objects() hook

[Django]

#17962: Add ModelAdmin.get_deleted_objects() hook
---+---
 Reporter:  Chris Wilson   |Owner:  Becky Smith
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  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


Comment:

 I left comments for improvement on the PR. Please uncheck "Patch needs
 improvement" after updating.

--
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/061.5c309647d563842eec9c3af662acdcf7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28306: Added tests in tests_lorem_ipsum.py

[Django]

#28306: Added tests in tests_lorem_ipsum.py
-+-
   Reporter:  Idan   |  Owner:  nobody
  Melamed|
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Testing|Version:  1.11
  framework  |   Keywords:  Testing, lorem
   Severity:  Normal |  ipsum
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi people,

 I added a few more tests in tests_lorem_ipsum.py and increased the
 coverage for it to 100%.
 Also changed the code a bit in lorem_ipsum.py.

 I read the the documentation for contributing, and couldn't find out clear
 information on what to do in my case.

 How do I continue now?
 Do I create a pull request?
 If so, how should I name my branch?

 Kindly,
 Idan.

--
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/050.f4d5e4b6ece6a975a83c205118397edb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28297: Same queryset result in two different queries on ORM

[Django]

#28297: Same queryset result in two different queries on ORM
-+-
 Reporter:  Marcus Renno |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  join, annotation, F  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom):

 * cc: tom@… (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.d52028c0f5ee957d010e2bc6021505e7%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 Andreas Backx):

 * type:  Uncategorized => Bug


--
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.983aec56baeb95ebab49e9ec633fe837%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:  Uncategorized|   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
-+-
Description changed by Andreas Backx:

Old description:

> ''A test case has been created here: https://github.com/AndreasBackx
> /Django-OneToOneFieldBug-Example. How to run the test case is described
> there.''
>
> There is a migration issue when moving from Django 1.10.7 to Django
> 1.11.2. This sample I made is a slimmed down version from an internal
> library which moved from utf8 to utf8mb4 in MySQL. This required the keys
> to be changed from 255 characters to 191 characters in order to be
> compatible with older versions of MySQL but the reason is irrelevant
> here. The issue is that Django 1.11.2+ tries to change the 'id' column of
> which the max_length has been changed from 255 to 191 that still has a
> constraint. It results in the following error:
>
> {{{
> django.db.utils.OperationalError: (1833, "Cannot change column 'id': used
> in a foreign key constraint
> 'myapp_agreement_member_id_0dc75c75_fk_myapp_member_id' of table
> 'test_onetoone.myapp_agreement'")
> }}}
>
> This is the full traceback:
>
> {{{
>   Applying myapp.0002_utf8mb4...Traceback (most recent call last):
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/django/db/backends/utils.py", line 65, in execute
> return self.cursor.execute(sql, params)
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/django/db/backends/mysql/base.py", line 101, in execute
> return self.cursor.execute(query, args)
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/MySQLdb/cursors.py", line 250, in execute
> self.errorhandler(self, exc, value)
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/MySQLdb/connections.py", line 50, in defaulterrorhandler
> raise errorvalue
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/MySQLdb/cursors.py", line 247, in execute
> res = self._query(query)
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/MySQLdb/cursors.py", line 411, in _query
> rowcount = self._do_query(q)
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/MySQLdb/cursors.py", line 374, in _do_query
> db.query(q)
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/MySQLdb/connections.py", line 292, in query
> _mysql.connection.query(self, query)
> _mysql_exceptions.OperationalError: (1833, "Cannot change column 'id':
> used in a foreign key constraint
> 'myapp_agreement_member_id_0dc75c75_fk_myapp_member_id' of table
> 'test_onetoone.myapp_agreement'")
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "manage.py", line 22, in 
> execute_from_command_line(sys.argv)
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/django/core/management/__init__.py", line 363, in
> execute_from_command_line
> utility.execute()
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/django/core/management/__init__.py", line 355, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/django/core/management/commands/test.py", line 29, in
> run_from_argv
> super(Command, self).run_from_argv(argv)
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/django/core/management/base.py", line 283, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/path/to/project/django-onetoone-
> test/.tox/py35-django-111/lib/python3.5/site-
> packages/django/core/management/base.py", line 330, in execute
> output = self.handle(*args, **options)
>   File "/path/to/project/django-onetoone-
> 

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:  Uncategorized|   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 Andreas Backx):

 * keywords:  mysql, onetoonefield, utf8mb4 => mysql, onetoonefield,
 utf8mb4, foreign key


--
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.41eaf5f6bdd35a9c120ef3c84fdf6486%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[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|  Owner:  nobody
  Backx  |
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  master
  Migrations |   Keywords:  mysql,
   Severity:  Normal |  onetoonefield, utf8mb4
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 ''A test case has been created here: https://github.com/AndreasBackx
 /Django-OneToOneFieldBug-Example. How to run the test case is described
 there.''

 There is a migration issue when moving from Django 1.10.7 to Django
 1.11.2. This sample I made is a slimmed down version from an internal
 library which moved from utf8 to utf8mb4 in MySQL. This required the keys
 to be changed from 255 characters to 191 characters in order to be
 compatible with older versions of MySQL but the reason is irrelevant here.
 The issue is that Django 1.11.2+ tries to change the 'id' column of which
 the max_length has been changed from 255 to 191 that still has a
 constraint. It results in the following error:

 {{{
 django.db.utils.OperationalError: (1833, "Cannot change column 'id': used
 in a foreign key constraint
 'myapp_agreement_member_id_0dc75c75_fk_myapp_member_id' of table
 'test_onetoone.myapp_agreement'")
 }}}

 This is the full traceback:

 {{{
   Applying myapp.0002_utf8mb4...Traceback (most recent call last):
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-
 packages/django/db/backends/utils.py", line 65, in execute
 return self.cursor.execute(sql, params)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-
 packages/django/db/backends/mysql/base.py", line 101, in execute
 return self.cursor.execute(query, args)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-packages/MySQLdb/cursors.py",
 line 250, in execute
 self.errorhandler(self, exc, value)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-
 packages/MySQLdb/connections.py", line 50, in defaulterrorhandler
 raise errorvalue
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-packages/MySQLdb/cursors.py",
 line 247, in execute
 res = self._query(query)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-packages/MySQLdb/cursors.py",
 line 411, in _query
 rowcount = self._do_query(q)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-packages/MySQLdb/cursors.py",
 line 374, in _do_query
 db.query(q)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-
 packages/MySQLdb/connections.py", line 292, in query
 _mysql.connection.query(self, query)
 _mysql_exceptions.OperationalError: (1833, "Cannot change column 'id':
 used in a foreign key constraint
 'myapp_agreement_member_id_0dc75c75_fk_myapp_member_id' of table
 'test_onetoone.myapp_agreement'")

 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "manage.py", line 22, in 
 execute_from_command_line(sys.argv)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 363, in
 execute_from_command_line
 utility.execute()
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 355, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-
 packages/django/core/management/commands/test.py", line 29, in
 run_from_argv
 super(Command, self).run_from_argv(argv)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-
 packages/django/core/management/base.py", line 283, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-
 packages/django/core/management/base.py", line 330, in execute
 output = self.handle(*args, **options)
   File "/path/to/project/django-onetoone-
 test/.tox/py35-django-111/lib/python3.5/site-
 packages/django/core/management/commands/test.py", line 62, in handle
 failures = test_runner.run_tests(test_labels)
   File 

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:  Internationalization  |  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 Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Seems okay at first glance, although I'm not a translations expert.
 Perhaps it would suffice to mark `CONTEXT_SEPARATOR` as safe?

--
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.93a3539dad96ce87235f4c48313dce62%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[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:  Internationalization  |Version:  master
   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 |
+
 `pgettext` always returns `str` even if both `message` and `context` are
 instances of `SafeData` (assuming translations exist).

 If we have following translations into Ukrainian
 {{{
 msgid ""
 msgstr ""
 "Project-Id-Version: django\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2017-06-09 14:23+\n"
 "PO-Revision-Date: 2017-06-09 10:22-0400\n"
 "Last-Translator: None\n"
 "Language-Team: Ukrainian\n"
 "Language: uk_UA\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 &&
 n"
 "%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"

 msgid ""
 msgstr " відсотків"

 msgctxt "percent"
 msgid ""
 msgstr " відсотків"
 }}}
 then
 {{{
 >>> from django.utils.translation import activate, ugettext, pgettext
 >>> from django.utils.safestring import SafeText
 >>>
 >>> activate('ua')
 >>>
 >>> type(pgettext(SafeText('percent'), SafeText('')))# Should
 return `SafeText` instance
 
 >>>
 >>> type(ugettext(SafeText('')))# This works correctly
 
 }}}

 This causes additional escape when using `trans` with `context` in
 templates:
 {{{
 >>> from django.utils.translation import activate
 >>> from django.template import Context, Template
 >>>
 >>> activate('ua')
 >>>
 >>> Template("{% load i18n %}{% trans '' context 'percent'
 %}").render(Context())# `&` unnecessary escaped into ``
 '#39; відсотків'
 >>>
 >>> Template("{% load i18n %}{% trans '' %}").render(Context())#
 This works correctly
 ' відсотків'
 }}}
 -
 The fix can be as follows:
 This line
 
https://github.com/django/django/blob/master/django/utils/translation/trans_real.py#L325
 in `pgettext` can be changed into:
 {{{
 msg_with_ctxt = "%s%s%s" % (context, CONTEXT_SEPARATOR, message)
 if isinstance(context, SafeData) and isinstance(message, SafeData):
 msg_with_ctxt = mark_safe(msg_with_ctxt)
 }}}
 -
 All versions from 1.8 to master are affected.

--
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.37f31499000cca49f6a6406ec7817990%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28295: ModelAdmin.prepopulated_fields generates a string with a trailing hyphen

[Django]

#28295: ModelAdmin.prepopulated_fields generates a string with a trailing hyphen
-+-
 Reporter:  monotonee|Owner:  monotonee
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin, ModelAdmin,   | Triage Stage:  Accepted
  prepopulated_fields, urlify, slug  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"7c4f05fae2ae12d698dc28421f5d4659162f928a" 7c4f05fa]:
 {{{
 #!CommitTicketReference repository=""
 revision="7c4f05fae2ae12d698dc28421f5d4659162f928a"
 Fixed #28295 -- Made admin's URLify.js trim trailing hyphens.
 }}}

--
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.127533027dd66249b606369d2baeafad%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27682: Add more dependencies to extras_require (eg sqlparse, PyYAML)

[Django]

#27682: Add more dependencies to extras_require (eg sqlparse, PyYAML)
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Packaging|  Version:  master
 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
-+-
Changes (by Connor Osborn):

 * cc: cdosborn@… (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.8a836166469bc8e72f25dc89706e748d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28302: Separate authorisation from authentication

[Django]

#28302: Separate authorisation from authentication
-+-
 Reporter:  Luc Saffre   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:  duplicate
 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:   => duplicate
 * component:  Uncategorized => contrib.auth
 * type:  Uncategorized => Cleanup/optimization


Comment:

 I'd consider this a duplicate of #20313. I closed the PR to stable/1.11.x
 as this type of change doesn't qualify for a backport per our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy]. Feel free to send a pull
 request to master -- tests and documentation also required.

--
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.13f512825af405df29a27cb00f8a4284%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23853: Replace JoinInfo namedtuple with Join class

[Django]

#23853: Replace JoinInfo namedtuple with Join class
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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 Tim Graham ):

 In [changeset:"31d7fc85410c81932a42c4d5bb84759fd9f4a295" 31d7fc85]:
 {{{
 #!CommitTicketReference repository=""
 revision="31d7fc85410c81932a42c4d5bb84759fd9f4a295"
 [1.11.x] Refs #23853 -- Updated sql.query.Query.join() docstring.

 Follow up to ab89414f40db1598364a7fe4cfac1766cacd2668.

 Backport of 7acbe89cc2a72f1b85d415c1cdb622c0dbbbe37c from master
 }}}

--
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.23635b7983e3e11d23171bc432fa8a94%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23853: Replace JoinInfo namedtuple with Join class

[Django]

#23853: Replace JoinInfo namedtuple with Join class
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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:"7acbe89cc2a72f1b85d415c1cdb622c0dbbbe37c" 7acbe89]:
 {{{
 #!CommitTicketReference repository=""
 revision="7acbe89cc2a72f1b85d415c1cdb622c0dbbbe37c"
 Refs #23853 -- Updated sql.query.Query.join() docstring.

 Follow up to ab89414f40db1598364a7fe4cfac1766cacd2668.
 }}}

--
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.9a905128adc4454f18f9989480847a3b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17962: Add ModelAdmin.get_deleted_objects() hook (was: Django Admin delete_view could benefit from extension points)

[Django]

#17962: Add ModelAdmin.get_deleted_objects() hook
---+---
 Reporter:  Chris Wilson   |Owner:  Becky Smith
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  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
---+---

--
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/061.65541be80d407b7300606d4da959276c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27833: prefetch_related fails with SQLite when used with 1000 parent records

[Django]

#27833: prefetch_related fails with SQLite when used with 1000 parent records
-+-
 Reporter:  Jason Barnabe|Owner:  Raphael
 |  Michel
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
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.f1ccae55e74a134841d62356376f2070%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28071: ExtendsNode history initialized with context origin rather than own origin

[Django]

#28071: ExtendsNode history initialized with context origin rather than own 
origin
-+-
 Reporter:  John D'Ambrosio  |Owner:  John
 |  D'Ambrosio
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.9
 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 Tim Graham ):

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


Comment:

 In [changeset:"be68c0bf637d9b28780753575b889946a734ca0e" be68c0b]:
 {{{
 #!CommitTicketReference repository=""
 revision="be68c0bf637d9b28780753575b889946a734ca0e"
 Fixed #28071 -- Fixed {% extends %} origin history.
 }}}

--
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.0e5a0ff32a4921524e5bfc89621e2c91%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28303: IntegerField & NumberInput widget localize max_value when rendering form field

[Django]

#28303: IntegerField & NumberInput widget localize max_value when rendering form
field
-+
 Reporter:  Richard Owen |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   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 Tim Graham):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 581879a510e58841e5780a5d1fdb4995733d2036 fixed a similar issue and might
 be a useful template for developing a patch.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.887b7ef3cf95ee82088d5c5e87c8bd56%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28303: IntegerField & NumberInput widget localize max_value when rendering form field

[Django]

#28303: IntegerField & NumberInput widget localize max_value when rendering form
field
+
   Reporter:  Richard Owen  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Forms |Version:  1.11
   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 |
+
 This issue is a change / regression in Django 1.11. It works correctly
 with Django 1.10. Tested on Django 1.11.2 and Python 2.7.13.

 == Reproduction Steps

 1. Enable the following settings:

 {{{
 USE_L10N = True
 USE_THOUSAND_SEPARATOR = True
 }}}

 2. Create a form with an IntegerField with a large max_value set:

 {{{
 class TestForm(forms.Form):
 integer_field = forms.IntegerField(max_value=99)
 }}}

 == Expected Result
 Form is rendered as
 {{{
 
 }}}

 == Actual Result
 Form is rendered as
 {{{
 
 }}}

 Note the comma separator in the max attribute on the input.

 Internet Explorer 11 treats this field as having a max attribute of 999.
 So entering a value of 1000 in the field prevents the user from submitting
 the form.

--
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/054.c325c9a0ba65e42eff4448141fd64401%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28302: Separate authorisation from authentication

[Django]

#28302: Separate authorisation from authentication
-+
   Reporter:  Luc Saffre |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.11
   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  |
-+
 With the AUTH_USER_MODEL setting, Django has opened the door for
 specifying a custom User model. Now it is only a little step to make it
 possible to use Django's authentication system without also using the
 authorization and permissions system. We just need to make sure that the
 functions defined in the auth.__init__.py file don't import the
 auth.models.py file. This is necessary because Django does not allow
 importing a models module of an app which is not installed.

 This is what [https://github.com/django/django/pull/8635 pull request
 8635] does. The changes in this PR are rather minimal and don't affect
 Django itself. We ran the Django test suite as described in
 [https://docs.djangoproject.com/en/dev/intro/contributing/ Writing your
 first patch for Django] in order to verify this. Summary of our changes:

 1) in file `django/contrib/auth/base_user.py` we define a class method on
 the AbstractUser model:


 {{{
 @classmethod
 def get_anonymous_user(cls):
 """Return an instance of AnonymousUser. Alternative
 implementations
 for AUTH_USER_MODEL may override this to use an alternative
 AnonymousUser class or add custom initialization.

 """
 return AnonymousUser()

 }}}

 2) In three places we changed Django to call this class method instead of
 instantiating AnonymousUser itself.

 BEFORE:

 {{{
 from django.contrib.auth.models import AnonymousUser
 request.user = AnonymousUser()
 }}}

 AFTER:

 {{{
 from django.contrib.auth import get_user_model
 request.user = get_user_model().get_anonymous_user()

 }}}

 As a side effect this PR also provides a fix for #20313. Instead of
 introducing a new setting ANONYMOUS_USER_MODEL, we prefer to define a
 class method on the AbstractUser model.

 This PR might also be an answer to #26401 (Allow auth machinery to be used
 without installing auth app)

 Some of our applications application cannot yet migrate to Python 3 due to
 third-party dependencies. So for us it would be important that these
 changes could be visible to the latest 1.x branch as well.

--
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/050.79929c56aef6e1081dd350d016645d3f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27830: Use distutils.version.LooseVersion instead of custom version parsing

[Django]

#27830: Use distutils.version.LooseVersion instead of custom version parsing
--+
 Reporter:  NotSqrt   |Owner:  ChillarAnand
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  1.10
 Severity:  Normal|   Resolution:  fixed
 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 ):

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


Comment:

 In [changeset:"08bda82c237b9ad071538c2386b8bfc62fef7f7f" 08bda82c]:
 {{{
 #!CommitTicketReference repository=""
 revision="08bda82c237b9ad071538c2386b8bfc62fef7f7f"
 Fixed #27830 -- Used distutils.version.LooseVersion for version parsing.
 }}}

--
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.81f6bccd60b2129bbbe2983faae83f80%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28297: Same queryset result in two different queries on ORM

[Django]

#28297: Same queryset result in two different queries on ORM
-+-
 Reporter:  Marcus Renno |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  join, annotation, F  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Marcus Renno):

 Tom, I agree with you that it should be the second query and I believe
 that the feature should be supported. It's just a bug and we will fix it
 ;)

 I'll try to work on this issue when I get home. I think you did a
 fantastic job narrowing down the problem and it's close to be solved.


 Replying to [comment:20 Tom]:
 > I've dug into this a fair bit and I'm sorry to say I'm stuck. I also
 think there is a pretty big bug lurking here that is out of my league. Or
 maybe it's a feature we don't support?
 >
 > As far as I can tell, if you annotate over foreign keys as well as m2m:
 >
 > {{{
 > Publisher.objects
 >.annotate(num_books=Count('book', distinct=True))
 >.filter(book__rating__gt=3.0)
 >.annotate(num_rated=Count('book', distinct=True))
 >.filter(num_books=F('num_rated'))
 >
 > }}}
 >
 > Then the resulting SQL will have the following `HAVING` clause:
 >
 > `HAVING COUNT(DISTINCT "publisher"."id") = (COUNT(DISTINCT
 "publisher"."id"))`
 >
 > Am I correct in thinking that this should be:
 >
 > `HAVING COUNT(DISTINCT "publisher"."id") = (COUNT(DISTINCT "T3"."id"))`,
 where `T3` is the correct join?
 >
 > In any case, either the generated query is incorrect or the
 documentation needs to be updated.
 >
 > I think, at least in the case of a m2m join, one of the issues are that
 there seems to be no way to resolve which alias is used by two identical
 annotations which are affected by a previous `.filter()` in the
 `query.join` method.

--
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.7d20d73cf17dea142b4b39b9d8af6ed5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28301: Object history is not logged for many to many fields

[Django]

#28301: Object history is not logged for many to many fields
-+--
 Reporter:  Karolis Ryselis  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.11
 Severity:  Normal   |   Resolution:  duplicate
 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:   => duplicate


Comment:

 Duplicate of #27998

--
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.c2c734d9a7fb632f70f1a1b03c6a6841%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28301: Object history is not logged for many to many fields

[Django]

#28301: Object history is not logged for many to many fields
---+
   Reporter:  Karolis Ryselis  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  contrib.admin|Version:  1.11
   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|
---+
 Consider this models.py:

 {{{
 from django.db import models


 class Model1(models.Model):
 title = models.CharField(max_length=20)

 def __str__(self):
 return self.title


 class Model2(models.Model):
 title = models.CharField(max_length=20)
 models1 = models.ManyToManyField(to="Model1")

 def __str__(self):
 return self.title
 }}}

 and this admin.py

 {{{
 from django.contrib import admin

 from .models import Model1, Model2

 admin.site.register(Model1)
 admin.site.register(Model2)
 }}}

 My test scenario:
 1. Add two `Model1` items via admin
 2. Add one `Model2` item via admin, choose one instance of `Model1` for
 many-to-many field
 3. Edit the `Model2` item via admin choosing both `Model1` instances for
 many-to-many field
 4. Open history for `Model2` instance
 5. "No fields changed." is in history even though we have changed one of
 the fields.

 I guess that this could be caused by lazy evaluation of initial queryset.
 Initial data is loaded from model instance using `model_to_dict` which
 calls `f.value_from_object` for each field. `ManyToManyField` implemention
 returns a queryset. It think it is only evaluated when object history
 messages are constructed, i.e., after object is saved to database, and
 queryset returns already saved values instead of initial values. Because
 of this, initial and saved data are always the same and this field never
 appears in `changed_data`.
 I was able to reproduce this on 1.11.2.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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/050.e00fdfb938a233de44f57d9089df6b82%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28229: The "next" variable is set in the login page, even when accessed directly

[Django]

#28229: The "next" variable is set in the login page, even when accessed 
directly
-+-
 Reporter:  Shrikant Sharat  |Owner:  Mikhail
 |  Golubev
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  auth | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"16431b03f801788d791bbb24d6fb266c3591ab07" 16431b0]:
 {{{
 #!CommitTicketReference repository=""
 revision="16431b03f801788d791bbb24d6fb266c3591ab07"
 [1.11.x] Fixed #28229 -- Fixed the value of LoginView's "next" template
 variable.

 Backport of e7dc39fb65e51d7613c941f7e5768b621dea4e76 from master
 }}}

--
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.64006609395af3ce8fd642d7d2592069%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28229: The "next" variable is set in the login page, even when accessed directly

[Django]

#28229: The "next" variable is set in the login page, even when accessed 
directly
-+-
 Reporter:  Shrikant Sharat  |Owner:  Mikhail
 |  Golubev
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  auth | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"e7dc39fb65e51d7613c941f7e5768b621dea4e76" e7dc39fb]:
 {{{
 #!CommitTicketReference repository=""
 revision="e7dc39fb65e51d7613c941f7e5768b621dea4e76"
 Fixed #28229 -- Fixed the value of LoginView's "next" template variable.
 }}}

--
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.ab8faf879447179405f0453d34a584fd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28284: Paginator._check_object_list_is_ordered should not evaluate the entire queryset

[Django]

#28284: Paginator._check_object_list_is_ordered should not evaluate the entire
queryset
--+
 Reporter:  Tom   |Owner:  Tom
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Other)  |  Version:  1.11
 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
--+

Comment (by Tim Graham ):

 In [changeset:"f908e9d015b5ac56b834f362339b03f6647e35ee" f908e9d0]:
 {{{
 #!CommitTicketReference repository=""
 revision="f908e9d015b5ac56b834f362339b03f6647e35ee"
 [1.11.x] Fixed #28284 -- Prevented Paginator's unordered object list
 warning from evaluating a QuerySet.

 Backport of a118287bca65f2e5da110c89509941c677ebc2e1 from master
 }}}

--
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/061.319a44e06d9d6ada817dfe0a3889557c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28284: Paginator._check_object_list_is_ordered should not evaluate the entire queryset

[Django]

#28284: Paginator._check_object_list_is_ordered should not evaluate the entire
queryset
--+
 Reporter:  Tom   |Owner:  Tom
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Other)  |  Version:  1.11
 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 Tim Graham ):

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


Comment:

 In [changeset:"a118287bca65f2e5da110c89509941c677ebc2e1" a118287b]:
 {{{
 #!CommitTicketReference repository=""
 revision="a118287bca65f2e5da110c89509941c677ebc2e1"
 Fixed #28284 -- Prevented Paginator's unordered object list warning from
 evaluating a QuerySet.
 }}}

--
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/061.8127d06d32be01e756c6d73f29285400%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28300: Enable GDALRaster objects to be read and created in GDAL's virtual file system.

[Django]

#28300: Enable GDALRaster objects to be read and created in GDAL's virtual file
system.
-+-
 Reporter:  Daniel Wiesmann  |Owner:  Daniel
 |  Wiesmann
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal gis vsi  | Triage Stage:  Accepted
  filesystem |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * 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 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.6cc733a5d2a329a7700f7b7469244a4c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28297: Same queryset result in two different queries on ORM

[Django]

#28297: Same queryset result in two different queries on ORM
-+-
 Reporter:  Marcus Renno |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  join, annotation, F  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom):

 * owner:  Tom => (none)
 * status:  assigned => new


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.271f3da61910f0d5a8d208c8cb6d90f4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28297: Same queryset result in two different queries on ORM

[Django]

#28297: Same queryset result in two different queries on ORM
-+-
 Reporter:  Marcus Renno |Owner:  Tom
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  join, annotation, F  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tom):

 I've dug into this a fair bit and I'm sorry to say I'm stuck. I also think
 there is a pretty big bug lurking here that is out of my league. Or maybe
 it's a feature we don't support?

 As far as I can tell, if you do:

 {{{
 Publisher.objects
.annotate(num_books=Count('book', distinct=True))
.filter(book__rating__gt=3.0)
.annotate(num_rated=Count('book', distinct=True))
.filter(num_books=F('num_rated'))

 }}}

 Then the resulting SQL will have the following `HAVING` clause:

 `HAVING COUNT(DISTINCT "publisher"."id") = (COUNT(DISTINCT
 "publisher"."id"))`

 Am I correct in thinking that this should be:

 `HAVING COUNT(DISTINCT "publisher"."id") = (COUNT(DISTINCT "T3"."id"))`,
 where `T3` is the correct join?

 In any case, either the generated query is incorrect or the documentation
 needs to be updated.

 I think, at least in the case of a m2m join, one of the issues are that
 there seems to be no way to resolve which alias is used by two identical
 annotations which are affected by a previous `.filter()` in the
 `query.join` method.

--
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.d5a510237f88c7a8c0eabac9e4ad6793%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28300: Enable GDALRaster objects to be read and created in GDAL's virtual file system.

[Django]

#28300: Enable GDALRaster objects to be read and created in GDAL's virtual file
system.
-+-
 Reporter:  Daniel Wiesmann  |Owner:  Daniel
 |  Wiesmann
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal gis vsi  | Triage Stage:
  filesystem |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Daniel Wiesmann):

 * has_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/067.ec4a8b22688d22e243183fedd96e0825%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28300: Enable GDALRaster objects to be read and created in GDAL's virtual file system.

[Django]

#28300: Enable GDALRaster objects to be read and created in GDAL's virtual file
system.
-+-
   Reporter:  Daniel |  Owner:  Daniel Wiesmann
  Wiesmann   |
   Type:  New| Status:  assigned
  feature|
  Component:  GIS|Version:  master
   Severity:  Normal |   Keywords:  raster gdal gis vsi
   Triage Stage: |  filesystem
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When dealing with rasters in a web context, rasters might be read from
 remote binary sources or are returned to the user as files. In such
 situations, the rasters would have to be written to disk as a file and
 then openend with GDALRaster. This can represent significant overhead.

 GDAL has an internal memory based virtual file system that allows reading
 and writing file buffers to memory and treat them as files. Allowing
 GDALRasters to use that filesystem would be useful for using rasters in
 web 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/052.01173bc1ff6e1a7fdbafbc958d770dc2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26488: migrate crashes when renaming a multi-table inheritance base model

[Django]

#26488: migrate crashes when renaming a multi-table inheritance base model
-+-
 Reporter:  Christopher  |Owner:  nobody
  Neugebauer |
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.9
 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 kesterlester):

 Replying to [comment:5 Tim Graham]:
 > As reported in #28243 (closed as duplicate), after
 ecd625e830ef765d5e60d5db7bc6e3b7ffc76d06,  the error is now something like
 "FieldError: Auto-generated field 'a_ptr' in class 'B' for parent_link to
 base class 'A' clashes with declared field of the same name."

 Ah - such a relief to find this bug report!   ~24 hours ago I hit this
 problem in my first django project.  Being a newbie I presumed I was doing
 something wrong and have been trying all sorts of things (without success)
 to allow me to rename a base class without losing all the data that's now
 in my database.  I'll leave the renaming issue alone now and await a
 patch.  I don't feel anywhere near experienced enough yet to try to patch
 things myself, but maybe later?

 In agreement with Tim's comment I see:

 {{{ jango.core.exceptions.FieldError: Auto-generated field 'content_ptr'
 in class 'Answer' for parent_link to base class 'Content' clashes with
 declared field of the same name. }}}

 as a result of me trying to rename a multi-table inheritance base class
 (having no non-automatic fields) from name "Content" to something else,
 when class Answer derives from Content.

--
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.5d15f5833b6b38428d72a910c5291f77%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26522: Non-determinstic crash in django.db.models.sql.Query.combine()

[Django]

#26522: Non-determinstic crash in django.db.models.sql.Query.combine()
-+-
 Reporter:  Ole Laursen  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (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 Gwildor Sok):

 I just ran into this problem as well after updating a project from 1.8 to
 1.11.2. Unfortunately, implementing the fix by changing `alias_map` to be
 an OrderedDict did not help. I managed to work around it by just rewriting
 the query, (because it was doing some dumb things which were obfuscated by
 chaining manager methods, as you can see below), but I thought I would
 share the smallest test case I could reproduce it with, just in case
 someone else runs into it as well.

 My models:
 {{{
 class Assessment(models.Model):
 pass

 class AnswerGroup(models.Model):
 assessment = models.ForeignKey(Assessment)

 author = models.ForeignKey(
 User, related_name='created_answergroups')
 about = models.ForeignKey(
 User, blank=True, null=True, related_name='subject_answergroups)
 }}}

 And my test code where I get the same AssertionError:

 {{{
 u = User.objects.get(pk=1)

 assessments = Assessment.objects.all()

 groups = AnswerGroup.objects.filter(assessment__in=assessments)

 groups_1 = groups.filter(author=u, about=u)
 groups_2 = groups.filter(author=u).exclude(about=None).exclude(about=u)

 list(groups_1 | groups_2)
 }}}

 Note that when I remove the `assessment__in` filter, the code works fine.
 Also note that `change_map` is something like `{u'auth_user': 'T4', 'T4':
 u'auth_user'}` both with and without the filter, and thus both when an
 error occurs and when it does not.

 I've worked around it by just using one filter and ditching the combine by
 just using `filter(author=u).exclude(about=None)`, but of course not
 everyone has the option to rewrite their query that easily.

--
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/068.55721578839730bdc22a4360ba42ff71%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25197: Add a more friendly widget for HStoreField

[Django]

#25197: Add a more friendly widget for HStoreField
-+-
 Reporter:  gam_phon |Owner:  Curtis
 |  Maloney
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  widget   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Evstifeev Roman):

 * cc: someuniquename@… (added)


Comment:

 add someuniquen...@gmail.com to cc list

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.63516aeb95948a9d2d6b0f68c2a2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28293: QuerySet.union(QuerySet.none()) results in an empty queryset, should be the original queryset

[Django]

#28293: QuerySet.union(QuerySet.none()) results in an empty queryset, should be 
the
original queryset
-+-
 Reporter:  Jon Dufresne |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"44e29ea1e906859e85bb2a46ae5ea9d82bd96f5f" 44e29ea1]:
 {{{
 #!CommitTicketReference repository=""
 revision="44e29ea1e906859e85bb2a46ae5ea9d82bd96f5f"
 [1.11.x] Fixed #28293 -- Fixed union(), intersection(), and difference()
 when combining with an EmptyQuerySet.

 Thanks Jon Dufresne for the report and Tim Graham for the review.

 Backport of 82175ead723f8fa3f9271fbd4b24275097029aab from master
 }}}

--
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.7af253089695b2a4d8b33d4f36fb6e2b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28293: QuerySet.union(QuerySet.none()) results in an empty queryset, should be the original queryset

[Django]

#28293: QuerySet.union(QuerySet.none()) results in an empty queryset, should be 
the
original queryset
-+-
 Reporter:  Jon Dufresne |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   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:"82175ead723f8fa3f9271fbd4b24275097029aab" 82175ead]:
 {{{
 #!CommitTicketReference repository=""
 revision="82175ead723f8fa3f9271fbd4b24275097029aab"
 Fixed #28293 -- Fixed union(), intersection(), and difference() when
 combining with an EmptyQuerySet.

 Thanks Jon Dufresne for the report and Tim Graham for the 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 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.fe67ca641462fee454efbdbf10bbc95b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.