Re: [Django] #28345: limit_choices_to callable is no longer applied during ModelForm instantiation which blocks some use cases

[Django]

#28345: limit_choices_to callable is no longer applied during ModelForm
instantiation which blocks some use cases
-+
 Reporter:  drunkard |Owner:  Jon Dufresne
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  ModelForm| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Jon Dufresne):

 [https://github.com/django/django/pull/8687 PR]

 The change adds an additional keyword argument, `apply_limit_choices_to`,
 to `field_for_model()`. This arugment allows `field_for_model()` to
 continue to be used to create form fields dynamically after
 `ModelForm.__init__()` is called.

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

Re: [Django] #28345: limit_choices_to callable is no longer applied during ModelForm instantiation which blocks some use cases

[Django]

#28345: limit_choices_to callable is no longer applied during ModelForm
instantiation which blocks some use cases
-+
 Reporter:  drunkard |Owner:  Jon Dufresne
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  ModelForm| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Jon Dufresne):

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

Re: [Django] #28345: limit_choices_to callable is no longer applied during ModelForm instantiation which blocks some use cases

[Django]

#28345: limit_choices_to callable is no longer applied during ModelForm
instantiation which blocks some use cases
-+
 Reporter:  drunkard |Owner:  Jon Dufresne
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  ModelForm| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Jon Dufresne):

 * status:  new => assigned
 * owner:  nobody => Jon Dufresne


Comment:

 I agree, this is a regression.
 
[https://docs.djangoproject.com/en/1.11/ref/models/fields/#django.db.models.ForeignKey.limit_choices_to
 The docs say:]

 > If a callable is used for `limit_choices_to`, it will be invoked every
 time a new form is instantiated.

 I have a fix in mind that will restore previous, correct behavior will
 also facilitating my use case motivating the original change.

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

Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

[Django]

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Forms |  Version:  1.11
 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 Tim Graham):

 The new ticket is #28345.

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

Re: [Django] #28345: limit_choices_to callable is no longer applied during ModelForm instantiation which blocks some use cases (was: #27563 caused regression to ModelForm)

[Django]

#28345: limit_choices_to callable is no longer applied during ModelForm
instantiation which blocks some use cases
-+
 Reporter:  drunkard |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  ModelForm| 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):

 * cc: Jon Dufresne (added)
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Old description:

> This change breaks inheriting from django.forms.models.ModelForm
> directly.
>
> I'm upgrading to python3.6 + django-1.11.2, and gets wrong, the choice
> field is always empty, caused by this commit
> 6abd6c598ea23e0a962c87b0075aa2f79f9ead36, and it's ticket is
> https://code.djangoproject.com/ticket/27563 . I'm using dynamic
> limit_choices_to function to get user specific filter expr.
>
>  It just called once during develop server init, and won't be call while
> open a USER EDIT FORM, which is inherited from ModelForm, but it work in
> django admin edit page, by reading the code, django admin build form
> using modelform_factory(), with this commit reverted, my customized form
> works just fine. So, I think it's a regression.
>
> Or, the usage of ModelForm changed? but newest doc not mentioned.
>
> Below is key part of test project saying the problem:
>
> proj/middleware.py
>
> {{{
> from threading import current_thread
>

> class CUserMiddleware(object):
> """Get current operating request and user"""
> _user = {}
>
> def process_request(self, request):
> self._user[current_thread()] = request.user
>
> def process_response(self, request, response):
> # TODO cleanup by alive session, if user session expired, remove
> all
> # items related to the user (dict value).
> # self._user.pop(current_thread(), None)  # clean to avoid it
> grows
> if len(self._user) > 1000:
> self._user = {}
> return response
>
> @classmethod
> def get_user(cls, default=None):
> # debug('当前用户: {}'.format(cls._user.get(current_thread(),
> default)))
> return cls._user.get(current_thread(), default)
>

> def current_user():
> return CUserMiddleware.get_user()
> }}}
>
> testapp/models.py
>
> {{{
> from django.db import models
> from django.db.models import Q
>
> from proj.middleware import current_user
>

> def limit_export_branch():
> u = current_user()
> if u:
> print('\tlimit_export_branch worked the right way')
> return Q(name__endswith='something')
> print('\tlimit_export_branch works in wrong way')
> import traceback
> traceback.print_stack()
> return Q(pk=-1)  # deny to avoid info leak
>

> class Branch(models.Model):
> name = models.CharField(max_length=16)
>
> def __str__(self):
> return self.name
>

> class Export(models.Model):
> name = models.CharField(max_length=16)
> branch = models.ForeignKey(Branch,
> limit_choices_to=limit_export_branch)
>
> def __str__(self):
> return self.name
> }}}
>
> testapp/forms.py
>
> {{{
> from django import forms
> from .models import Export
>

> class ExportEditForm(forms.ModelForm):
> class Meta:
> model = Export
> fields = ['name', 'branch']
> }}}
>
> testapp/views.py
>
> {{{
> from django.views.generic import UpdateView
>
> from .forms import ExportEditForm
> from .models import Export
>

> class ExportEditView(UpdateView):
> form_class = ExportEditForm
> model = Export
> template_name = 'edit.html'
> pk_url_kwarg = 'export_pk'
> }}}
>
> and the ugly template: testapp/templates/edit.html
>
> {{{
> {{ form.as_table }}
> }}}

New description:

 I'm upgrading to Django 1.11.2 and found that `limit_choices_to` is
 applied to forms too early. It's caused by commit
 6abd6c598ea23e0a962c87b0075aa2f79f9ead36 (ticket #27563).

 I'm using dynamic limit_choices_to function to get user specific filter
 expr. It just called once during develop server init, and won't be call
 while open a USER EDIT FORM, which is inherited from ModelForm, but it
 work in django admin edit page, by reading the code, django admin build
 form using modelform_factory(), with this commit reverted, my customized
 form works just fine. So, I think it's a regression.

 Below is key part of test project showing the problem:

 proj/middleware.py

 {{{
 from threading import current_thread


 class CUserMiddleware(object):
 """Get current operating request and user"""
 _user = {}

 def proces

Re: [Django] #28345: #27563 caused regression to ModelForm

[Django]

#28345: #27563 caused regression to ModelForm
---+--
 Reporter:  drunkard   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  ModelForm  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by drunkard):

 * Attachment "limit_choices_to-bug.tgz" added.

 Simple test project of this 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/066.2a4641fb50a2c05c4edb41d8a24c06e4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28345: #27563 caused regression to ModelForm

[Django]

#28345: #27563 caused regression to ModelForm
--+---
   Reporter:  drunkard|  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |Version:  1.11
   Severity:  Normal  |   Keywords:  ModelForm
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
 This change breaks inheriting from django.forms.models.ModelForm directly.

 I'm upgrading to python3.6 + django-1.11.2, and gets wrong, the choice
 field is always empty, caused by this commit
 6abd6c598ea23e0a962c87b0075aa2f79f9ead36, and it's ticket is
 https://code.djangoproject.com/ticket/27563 . I'm using dynamic
 limit_choices_to function to get user specific filter expr.

  It just called once during develop server init, and won't be call while
 open a USER EDIT FORM, which is inherited from ModelForm, but it work in
 django admin edit page, by reading the code, django admin build form using
 modelform_factory(), with this commit reverted, my customized form works
 just fine. So, I think it's a regression.

 Or, the usage of ModelForm changed? but newest doc not mentioned.

 Below is key part of test project saying the problem:

 proj/middleware.py

 {{{
 from threading import current_thread


 class CUserMiddleware(object):
 """Get current operating request and user"""
 _user = {}

 def process_request(self, request):
 self._user[current_thread()] = request.user

 def process_response(self, request, response):
 # TODO cleanup by alive session, if user session expired, remove
 all
 # items related to the user (dict value).
 # self._user.pop(current_thread(), None)  # clean to avoid it
 grows
 if len(self._user) > 1000:
 self._user = {}
 return response

 @classmethod
 def get_user(cls, default=None):
 # debug('当前用户: {}'.format(cls._user.get(current_thread(),
 default)))
 return cls._user.get(current_thread(), default)


 def current_user():
 return CUserMiddleware.get_user()
 }}}

 testapp/models.py

 {{{
 from django.db import models
 from django.db.models import Q

 from proj.middleware import current_user


 def limit_export_branch():
 u = current_user()
 if u:
 print('\tlimit_export_branch worked the right way')
 return Q(name__endswith='something')
 print('\tlimit_export_branch works in wrong way')
 import traceback
 traceback.print_stack()
 return Q(pk=-1)  # deny to avoid info leak


 class Branch(models.Model):
 name = models.CharField(max_length=16)

 def __str__(self):
 return self.name


 class Export(models.Model):
 name = models.CharField(max_length=16)
 branch = models.ForeignKey(Branch,
 limit_choices_to=limit_export_branch)

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

 testapp/forms.py

 {{{
 from django import forms
 from .models import Export


 class ExportEditForm(forms.ModelForm):
 class Meta:
 model = Export
 fields = ['name', 'branch']
 }}}

 testapp/views.py

 {{{
 from django.views.generic import UpdateView

 from .forms import ExportEditForm
 from .models import Export


 class ExportEditView(UpdateView):
 form_class = ExportEditForm
 model = Export
 template_name = 'edit.html'
 pk_url_kwarg = 'export_pk'
 }}}

 and the ugly template: testapp/templates/edit.html

 {{{
 {{ form.as_table }}
 }}}

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

Re: [Django] #28343: Update the Windows instructions in the docs to use py launcher rather than Git bash

[Django]

#28343: Update the Windows instructions in the docs to use py launcher rather 
than
Git bash
-+-
 Reporter:  Ramiro Morales   |Owner:  Ramiro
 Type:   |  Morales
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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:

 The
 
[https://github.com/django/djangoproject.com/tree/f0c11a962a9e2cc9651f56cffe1ab69877b3bf36/docs
 djangoproject.com website] doesn't use the sphinx theme, so separate
 changes are needed for this to work there.

 A usability improvement would be for the operating system selector above
 the code blocks to toggle all blocks on the page rather than each
 individual block. It's annoying to follow the tutorial and have to click
 to change to Windows each time. For the website, I wonder if it would be
 worth trying to persist the user's choice in a cookie (and/or even try to
 pull it from the browser's user agent).

 It could be useful to post about this effort on the DevelopersMailingList,
 just to make sure other Windows users are in agreement with these changes.

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

Re: [Django] #27818: Use contextlib.suppress to suppress exceptions.

[Django]

#27818: Use contextlib.suppress to suppress exceptions.
-+-
 Reporter:  Mads Jensen  |Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  master
 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 ):

 * owner:  (none) => Tim Graham 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"550cb3a365dee4edfdd1563224d5304de2a57fda" 550cb3a]:
 {{{
 #!CommitTicketReference repository=""
 revision="550cb3a365dee4edfdd1563224d5304de2a57fda"
 Fixed #27818 -- Replaced try/except/pass with contextlib.suppress().
 }}}

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

Re: [Django] #24272: Better error messages for prefetch_related

[Django]

#24272: Better error messages for prefetch_related
-+-
 Reporter:  Todor Velichkov  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related,| Triage Stage:  Accepted
  GenericRelation,   |
  related_query_name |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Todor Velichkov):

 I did some debugging and I think I find out why `prefetch_related` on
 `GenericRelation` using `related_query_name`  is not working. i.e.

 `TaggedItem.objects.filter(books__author__name='E L
 James').prefetch_related('books')`

 It starts from the
 
[https://github.com/django/django/blob/1.11.2/django/db/models/fields/related_descriptors.py#L596
 get_prefetch_queryset] at `related_descriptors`, where `self.field` is a
 `GenericRelation` field
 (`` in this
 example) the
 
[https://github.com/django/django/blob/1.11.2/django/contrib/contenttypes/fields.py#L276
 GenericRelation] class inherits from `ForeignObject` but does not
 implement
 
[https://github.com/django/django/blob/1.11.2/django/db/models/fields/related.py#L655
 get_local_related_value] and `get_foreign_related_value` methods which
 looks incompatible  with the `GenericRelation` interface, because they
 search for `object_id` attribute inside a `Book` model.

 I would love to try to fix this, but I still can't fully understand the
 code, I'm not even sure what needs to be returned here, all tags related
 to this book maybe? If thats the case, then the code in
 `get_prefetch_queryset` looks like its expected to be returned only a
 single instance, not many, this is confusing me.

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

Re: [Django] #25612: django.contrib.auth should include support for 2fa out of the box

[Django]

#25612: django.contrib.auth should include support for 2fa out of the box
--+
 Reporter:  Alex Gaynor   |Owner:  (none)
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  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 mlevental):

 * status:  assigned => new
 * owner:  mlevental => (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.3e23c8977417c032b461c2aab8b8d091%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28334: contrib.postgresql overwhelms database with "select from pg_type" queries on each request

[Django]

#28334: contrib.postgresql overwhelms database with "select from pg_type" 
queries
on each request
-+-
 Reporter:  Igor Gumenyuk|Owner:  Igor
 Type:   |  Gumenyuk
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.postgres |  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
-+-

Comment (by Igor Gumenyuk):

 All issues resolved, there are no failed tests

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

Re: [Django] #28334: contrib.postgresql overwhelms database with "select from pg_type" queries on each request

[Django]

#28334: contrib.postgresql overwhelms database with "select from pg_type" 
queries
on each request
-+-
 Reporter:  Igor Gumenyuk|Owner:  Igor
 Type:   |  Gumenyuk
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.postgres |  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 Igor Gumenyuk):

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

Re: [Django] #28344: Add for_update parameter to Model.refresh_from_db() (was: Add `for_update=False` to `refresh_from_db()`)

[Django]

#28344: Add for_update parameter to Model.refresh_from_db()
-+-
 Reporter:  Patryk Zawadzki  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Looks okay at first glance. Is the implementation fairly simple?

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

Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

[Django]

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Forms |  Version:  1.11
 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 Tim Graham):

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


Comment:

 This change is released, so please open a new ticket at this point. I'm
 not sure if what you provided is sufficient to reproduce the issue. A
 sample project or a test would be helpful.

--
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.b2522aa05f1090124b6490dd301b461c%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:  Release blocker  |   Resolution:
 Keywords:  mysql,   | Triage Stage:  Accepted
  onetoonefield, utf8mb4, foreign|
  key|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Markus, do you have any suggestions about how to fix this? I confirmed
 that reverting the
 
[https://github.com/django/django/commit/45ded053b1f4320284aa5dac63052f6d1baefea9
 #diff-efb7d00c2383393046c9c5d842f45499R201 delayed rendering changes] to
 `AlterField` fixes it. Maybe the reloading shouldn't be delayed if a field
 is pointed to by a foreign key? (i.e. reloading should be delayed for both
 forward and reverse relations)

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

[Django] #28344: Add `for_update=False` to `refresh_from_db()`

[Django]

#28344: Add `for_update=False` to `refresh_from_db()`
-+-
   Reporter:  Patryk |  Owner:  nobody
  Zawadzki   |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have a project where we deal with many financial operations that rely on
 transactions and row-level locking a lot to guard against race conditions.
 Unfortunately it's a common pattern for a function to accept an instance
 of model A, start an atomic block, fetch a new instance of the same row
 with `select_for_update()`, do a change, call `save()` and then refresh
 the original instance. It would all be easier if I could just call
 `instance.refresh_from_db(for_update=True)` and it would save a me a DB
 roundtrip to refresh the original instance passed (Django ORM does not
 have a session manager so the old object will not otherwise reflect the
 changes).

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

Re: [Django] #28343: Update the Windows instructions in the docs to use py launcher rather than Git bash

[Django]

#28343: Update the Windows instructions in the docs to use py launcher rather 
than
Git bash
-+-
 Reporter:  Ramiro Morales   |Owner:  Ramiro
 Type:   |  Morales
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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
-+-

Comment (by Ramiro Morales):

 A short screencast of how the new custom Sphinx directive works
 [[Image(http://i.imgur.com/00oSOXU.gifv)]]

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

Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

[Django]

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  1.11
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by drunkard):

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


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

Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

[Django]

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Forms |  Version:  1.11
 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 drunkard):

 This change breaks inheriting from django.forms.models.ModelForm directly.

 I'm upgrading to python3.6 + django-1.11.2, and gets wrong with this
 commit. I'm using dynamic limit_choices_to function to get user specific
 filter expr, one of my function is like:

 {{{
 def limit_export_branch():
 user = current_user()
 if user:
 bs = user.userprofile.branches_with_perms(['add_export',
 'change_export'])
 return Q(pk__in=bs.values_list('pk', flat=True),
  businesses__name=BUSINESS_BROADBAND)
 return Q(pk=-1)  # deny to avoid info leak
 }}}

 It just called once during develop server init, and won't be call while
 open a USER EDIT FORM, but it work in django admin edit page, by reading
 the code, django admin build form using modelform_factory(), with this
 commit reverted, my customized form works just fine. So, I think it's a
 regression.

 Or, the usage of ModelForm changed? but newest doc not mentioned.

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

Re: [Django] #28343: Update the Windows instructions in the docs to use py launcher rather than Git bash (was: Documentation for Windows users can be simpler now that we only support Python >= 3.5)

[Django]

#28343: Update the Windows instructions in the docs to use py launcher rather 
than
Git bash
-+-
 Reporter:  Ramiro Morales   |Owner:  Ramiro
 Type:   |  Morales
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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):

 * stage:  Unreviewed => Accepted


Old description:

> Python installations on WIndows now
> * Ship the PEP397 `py` launcher which reduces the need to either having
> to add `python.exe` directory to PATH or having to always aspecify its
> full path. OIt also cand detect  your Python's `python.exe`  even when
> its invoked from inside a virtualenv.
> * Have a better ''"Execute manage.py or runtest.py by simply running
> them"'' story when compared to previous Python versions, thanks partially
> to the above mentioned launcher.
>
> This would allow us to reduce special casing of Windows when describing
> command line interactions. In particular IMHO the suggestion to use the
> Git for Windows Bash shell can be dropped from the contributing tutorial
> as it doesn't actually make things easier.

New description:

 Python installations on Windows now:
 * Ship the PEP397 `py` launcher which reduces the need to either having to
 add `python.exe` directory to PATH or having to always specify its full
 path. It also can detect  your Python's `python.exe`  even when it's
 invoked from inside a virtualenv.
 * Have a better ''"Execute manage.py or runtest.py by simply running
 them"'' story when compared to previous Python versions, thanks partially
 to the above mentioned launcher.

 This would allow us to reduce special casing of Windows when describing
 command line interactions. In particular IMHO the suggestion to use the
 Git for Windows Bash shell can be dropped from the contributing tutorial
 as it doesn't actually make things easier.

--

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

Re: [Django] #27473: Allow using Extract() with DurationField

[Django]

#27473: Allow using Extract() with DurationField
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"43a4835edf32c57eb74c0eb207c276734a34abcf" 43a4835e]:
 {{{
 #!CommitTicketReference repository=""
 revision="43a4835edf32c57eb74c0eb207c276734a34abcf"
 Fixed #27473 -- Added DurationField support to Extract.
 }}}

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

Re: [Django] #28334: contrib.postgresql overwhelms database with "select from pg_type" queries on each request

[Django]

#28334: contrib.postgresql overwhelms database with "select from pg_type" 
queries
on each request
-+-
 Reporter:  Igor Gumenyuk|Owner:  Igor
 Type:   |  Gumenyuk
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.postgres |  Version:  1.11
 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:

 There are test failures on the pull request.

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

Re: [Django] #28294: Document request/args/kwargs attributes of class-based views

[Django]

#28294: Document request/args/kwargs attributes of class-based views
-+-
 Reporter:  Tony Narlock |Owner:  Michael
 Type:   |  Vasiliou
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  documentation views  | 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:"a6756195c1a11eee10c16c96fe95d52e22e1d9ba" a6756195]:
 {{{
 #!CommitTicketReference repository=""
 revision="a6756195c1a11eee10c16c96fe95d52e22e1d9ba"
 [1.11.x] Fixed #28294 -- Doc'd request/args/kwargs attributes of class-
 based views.

 Backport of 63e9a71ec4917ddf7f4acbf69a7ccdafb76fb2ee 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/062.fa205ad925fcd9d8182e7cddbfba5bbc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28294: Document request/args/kwargs attributes of class-based views

[Django]

#28294: Document request/args/kwargs attributes of class-based views
-+-
 Reporter:  Tony Narlock |Owner:  Michael
 Type:   |  Vasiliou
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  documentation views  | 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:"63e9a71ec4917ddf7f4acbf69a7ccdafb76fb2ee" 63e9a71]:
 {{{
 #!CommitTicketReference repository=""
 revision="63e9a71ec4917ddf7f4acbf69a7ccdafb76fb2ee"
 Fixed #28294 -- Doc'd request/args/kwargs attributes of class-based views.
 }}}

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

Re: [Django] #28201: Make CharField form field prohibit null characters

[Django]

#28201: Make CharField form field prohibit null characters
-+-
 Reporter:  CM Lubinski  |Owner:  Alejandro
 Type:   |  Zamora Fonseca
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  1.11
 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/067.67874d23a68899df56b5350bd0b07495%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28334: contrib.postgresql overwhelms database with "select from pg_type" queries on each request

[Django]

#28334: contrib.postgresql overwhelms database with "select from pg_type" 
queries
on each request
-+-
 Reporter:  Igor Gumenyuk|Owner:  Igor
 Type:   |  Gumenyuk
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.postgres |  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 Igor Gumenyuk):

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

Re: [Django] #28201: Make CharField form field prohibit null characters

[Django]

#28201: Make CharField form field prohibit null characters
-+-
 Reporter:  CM Lubinski  |Owner:  Alejandro
 Type:   |  Zamora Fonseca
  Cleanup/optimization   |   Status:  new
Component:  Forms|  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 Alejandro Zamora Fonseca):

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


Comment:

 Also my apologies, I accidentally modified 'resolution' and 'status'
 flags, and I'm not sure how revert it the changes.
 Maybe should I  'reopen' the ticket to achieve 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/067.09c38843599fb3600290044d6a2e9c53%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27473: Allow using Extract() with DurationField

[Django]

#27473: Allow using Extract() with DurationField
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:  New feature  |   Status:  new
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:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Daniel Hahler):

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

Re: [Django] #28201: Make CharField form field prohibit null characters

[Django]

#28201: Make CharField form field prohibit null characters
-+-
 Reporter:  CM Lubinski  |Owner:  Alejandro
 Type:   |  Zamora Fonseca
  Cleanup/optimization   |   Status:  closed
Component:  Forms|  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 Alejandro Zamora Fonseca):

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


Comment:

 Should I mark the ticket as "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/067.58bae7d67e2a09591e3ec70dd289b2ca%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:  Marcus
 |  Renno
 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 Marcus Renno):

 Replying to [comment:31 holvianssi]:
 > To me it seems that pre
 
https://code.djangoproject.com/changeset/ab89414f40db1598364a7fe4cfac1766cacd2668
 we always used the *first* join, not the last join possible in join(). I
 believe this has been that way for a long time, so changing that should be
 considered carefully.
 >
 > I'm not exactly sure why do we get random order for self.alias_map in
 join. It's an OrderedDict, so that shouldn't be the case...

 Hm... I always had the impression it was the last join. For me, it makes
 sense to use the tables in sequence, because  you use actions (aka
 operations) in sequence. If it always grab the first joined table this
 wouldn't be possible. From what I understood, here in this ticket, until
 recent changes the order was random.

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