Re: [Django] #29024: `TestContextDecorator` never exits if `setUp` fails in tests

[Django]

#29024: `TestContextDecorator` never exits if `setUp` fails in tests
-+-
 Reporter:  Anthony King |Owner:  Shahbaj
 |  Sayyad
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_tests:  0 => 1


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

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

Re: [Django] #29129: Child model updates parent model with empty fields making an extra query in multi-inheritance when parent model has custom PK

[Django]

#29129: Child model updates parent model with empty fields making an extra 
query in
multi-inheritance when parent model has custom PK
-+-
 Reporter:  user0007 |Owner:  Ashaba
 |  John
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ashaba John):

 * owner:  nobody => Ashaba John
 * status:  new => assigned


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

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

Re: [Django] #29024: `TestContextDecorator` never exits if `setUp` fails in tests

[Django]

#29024: `TestContextDecorator` never exits if `setUp` fails in tests
-+-
 Reporter:  Anthony King |Owner:  Shahbaj
 |  Sayyad
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Shahbaj Sayyad):

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

Re: [Django] #29024: `TestContextDecorator` never exits if `setUp` fails in tests

[Django]

#29024: `TestContextDecorator` never exits if `setUp` fails in tests
-+-
 Reporter:  Anthony King |Owner:  Shahbaj
 |  Sayyad
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Shahbaj Sayyad):

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

Re: [Django] #28933: Optimize the queries for ModelAdmin.date_hierarchy (was: Implement a range-based filter for Django Admin date_hierarchy)

[Django]

#28933: Optimize the queries for ModelAdmin.date_hierarchy
--+
 Reporter:  hakib |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  2.0
 Severity:  Normal|   Resolution:
 Keywords:  date_hierarchy| 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
 * stage:  Ready for checkin => Accepted
 * type:  New feature => Cleanup/optimization


Old description:

> The predicate generated by date_hierarchy makes it very difficult for
> databases to optimize the query.
>
> The following date hierarchy:
>
> {{{
> /admin/app/model?created__year=2017__month=12__day=16
> }}}
>
> Will generate the following where clause (PostgreSql):
>
> {{{
> WHERE created between '2017-01-01' and '2017-31-12' and EXTRACT('month',
> created) = 12 and EXTRACT('day', created) = 16
> }}}
>

> The query above will not be able to utilize range based indexes on the
> date hierarchy column - on big tables this has a significant performance
> impact.
>
> The current implementation of date hierarchy is relying on the "default"
> filtering mechinizem used by Django Admin. **I propose implementing
> custom filtering for Django Admin that will better utilize it's
> hierarchical nature and make it more database "friendly".**
>
> Instead of the query above the date hierarchy would generate the
> following predicates for different levels of the heirarchy:
>

> {{{
> /admin/app/model?created__year=2017__month=12__day=16
> WHERE created >= '2017-12-16' and created < '2017-12-17'
> }}}
>

> {{{
> /admin/app/model?created__year=2017__month=12
> WHERE created >= '2017-12-01' and created < '2018-01-01'
> }}}
>

> {{{
> /admin/app/model?created__year=2017
> WHERE created >= '2017-01-01' and created < '2018-01-01'
> }}}
>

> I already [wrote about this issue](https://codeburst.io/django-admin-
> range-based-date-hierarchy-37955b12ea4e) and [published a
> package](https://github.com/hakib/django-admin-lightweight-date-
> hierarchy/blob/master/django_admin_lightweight_date_hierarchy/admin.py)
> that implement the above as a custom SimpleListFilter.
>
> I already have a PR ready - I'm following proper protocol here so please
> let me know if this is acceptable.

New description:

 The predicate generated by `ModelAdmin.date_hierarchy` makes it very
 difficult for databases to optimize the query.

 The following date hierarchy:

 `/admin/app/model?created__year=2017__month=12__day=16`

 generates the following WHERE clause (PostgreSQL):

 `WHERE created between '2017-01-01' and '2017-31-12' and EXTRACT('month',
 created) = 12 and EXTRACT('day', created) = 16`

 The query above will not be able to utilize range based indexes on the
 date hierarchy column - on big tables this has a significant performance
 impact.

 The current implementation of date hierarchy is relying on the "default"
 filtering mechanism used by the admin. I propose implementing custom
 filtering for  that will better utilize it's hierarchical nature and make
 it more database friendly.

 Instead of the query above the date hierarchy would generate the following
 predicates for different levels of the hierarchy:

 {{{
 /admin/app/model?created__year=2017__month=12__day=16
 WHERE created >= '2017-12-16' and created < '2017-12-17'
 }}}

 {{{
 /admin/app/model?created__year=2017__month=12
 WHERE created >= '2017-12-01' and created < '2018-01-01'
 }}}

 {{{
 /admin/app/model?created__year=2017
 WHERE created >= '2017-01-01' and created < '2018-01-01'
 }}}

 I already [https://codeburst.io/django-admin-range-based-date-hierarchy-
 37955b12ea4e wrote about this issue] and [https://github.com/hakib/django-
 admin-lightweight-date-
 hierarchy/blob/master/django_admin_lightweight_date_hierarchy/admin.py
 published a package] that implements the above as a custom
 `SimpleListFilter`.

 I already have a PR ready - I'm following proper protocol here so please
 let me know if this is acceptable.

--

Comment:

 I left some comments for improvement.

-- 
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 

Re: [Django] #29106: Make manage.py test display the test tags that are in use

[Django]

#29106: Make manage.py test display the test tags that are in use
-+-
 Reporter:  Rich Jones   |Owner:  Sanyam
 Type:   |  Khurana
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"5a669ae2f4e1665f475d384ab762bcf4ddc5660b" 5a669ae2]:
 {{{
 #!CommitTicketReference repository=""
 revision="5a669ae2f4e1665f475d384ab762bcf4ddc5660b"
 Fixed #29106 -- Made DiscoverRunner display selected test tags.
 }}}

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

Re: [Django] #23646: query set sql update to change different values by different keys (include django-bulk-update in core)

[Django]

#23646: query set sql update to change different values by different keys 
(include
django-bulk-update in core)
-+-
 Reporter:  Brillgen Developers  |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (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 Tom Forbes):

 * cc: Tom Forbes (added)
 * owner:  nobody => Tom Forbes
 * status:  new => assigned


Comment:

 Sorry for the duplicate, I'm not sure how my search missed this. I've got
 a patch that implements this at a basic level, there are some small
 optimizations that could be done at a later stage (including adding
 Postgres specific syntax).

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

Re: [Django] #23646: query set sql update to change different values by different keys (include django-bulk-update in core)

[Django]

#23646: query set sql update to change different values by different keys 
(include
django-bulk-update in core)
-+-
 Reporter:  Brillgen Developers  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (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 Tim Graham):

 * has_patch:  0 => 1


Comment:

 #29037 is a duplicate with [https://github.com/django/django/pull/9606 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/066.825a24b1d953cb27765e99f4a09de16f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29037: Add a bulk_update method to models

[Django]

#29037: Add a bulk_update method to models
-+-
 Reporter:  Tom Forbes   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 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:   => duplicate


Comment:

 [https://groups.google.com/d/topic/django-developers/nHH-
 gKPCs6Q/discussion django-developers thread]

 Duplicate of #23646.

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

Re: [Django] #29098: Add SimpleTestCase.assertRedirectsRegex() (was: Allow assertRedirects to handle regex matches.)

[Django]

#29098: Add SimpleTestCase.assertRedirectsRegex()
---+
 Reporter:  Dan J Strohl   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  unittest redirect  | 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):

 * type:  Cleanup/optimization => New feature
 * stage:  Unreviewed => Accepted


Old description:

> or, perhaps, allow it to use the patterns from the url's file.  Either
> way, the issue is that I have a view that gets a request, looks at it,
> and redirects it to a url such as /labs/12345/running, or
> /labs/4567/start.  this is a similar pattern to what is recommended and
> used in the admin, so I don't think I am doing something weird here, but
> I may not know what the redirect url will look like before I send the
> request (if I am sending something like /labs/new, and it returns
> /labs/12345 for example).
>
> as a hack, I did this:
> {{{
> #!div style="font-size: 80%"
> Code highlighting:
>   {{{#!python
> def fix_response_for_test(response, re_pattern, replace, count=0,
> flags=0):
>
> if hasattr(response, 'redirect_chain'):
> url, status_code = response.redirect_chain[-1]
>
> tmp_replaced = re.search(re_pattern, url, flags=flags)
> new_url = re.sub(re_pattern, replace, url, count=count,
> flags=flags)
>
> # print('redirect - new: %s' % new_url)
>
> response.redirect_chain[-1] = (new_url, status_code)
>
> else:
> # Not a followed redirect
> url = response.url
> scheme, netloc, path, query, fragment = urlsplit(url)
>
> # Prepend the request path to handle relative path redirects.
> if not path.startswith('/'):
> url = urljoin(response.request['PATH_INFO'], url)
>
> tmp_replaced = re.search(re_pattern, url, flags=flags)
> new_url = re.sub(re_pattern, replace, url, count=count,
> flags=flags)
>
> # print('no redirected - new: %s' % new_url)
>
> response['Location'] = new_url
>
> return tmp_replaced.group(0)
>   }}}
> }}}
>
> and is run like this:
>
> {{{
> #!div style="font-size: 80%"
> Code highlighting:
>   {{{#!python
>
> session_id = fix_response_for_test(response, UUID_REGEX,
> '')
>
> redirect_url = '/lab//error/'
>
> with self.subTest('%s - response url' % name):
> self.assertRedirects(response, redirect_url,
> fetch_redirect_response=False, msg_prefix=tmp_msg)
> test_session = Sessions.objects.get(session_id=session_id)
> # do more testing on the session object to make sure it was
> created correctly.
>   }}}
> }}}
>
> The returning the pulled content is nice, but probably not required as I
> COULD simply build two tests, one to check the redirect, and another to
> test the actual session object.
>
> If I had my druthers, I would love to see something like:
>
> {{{
> #!div style="font-size: 80%"
> Code highlighting:
>   {{{#!python
>
> args_obj=None
> self.assertRedirects(response, r'/labs/(?P.+)/(.+)',
> get_args=args_obj)
>
> # assuming this passes the assertion, args_obj then would ==
> # args_obj = {
> #'args': ['list of un-named items'],
> #'kwargs': {dict of kwargs}
>   }}}
> }}}
>
> This coudl also be approached by adding the ability to get this kind of
> thing directly from the response object, along the lines of:
> {{{
> #!div style="font-size: 80%"
> Code highlighting:
>   {{{#!python
>
> (assuming the request was '/labs/12344/test_page
> > my_response.seed_url()
> ' '//labs//(?P.+)//(.+)'  # which could then be matched in a
> redirect url match.
> > my_response.url_params(1)
> 'test_page'
> > my_response.url_params('foobar')
> '12344'
>
>   }}}
> }}}

New description:

 or, perhaps, allow it to use the patterns from the url's file.  Either
 way, the issue is that I have a view that gets a request, looks at it, and
 redirects it to a url such as /labs/12345/running, or /labs/4567/start.
 this is a similar pattern to what is recommended and used in the admin, so
 I don't think I am doing something weird here, but I may not know what the
 redirect url will look like before I send the request (if I am sending
 something like /labs/new, and it returns /labs/12345 for example).

 as a hack, I did this:
 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
 def fix_response_for_test(response, re_pattern, replace, count=0,
 flags=0):

 if hasattr(response, 'redirect_chain'):
 url, status_code = 

Re: [Django] #29062: "database table locked errors" when using sqlite in-memory database with LiveServerTestCase

[Django]

#29062: "database table locked errors" when using sqlite in-memory database with
LiveServerTestCase
-+-
 Reporter:  Juozas Masiulis  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  sqlite, testing, | Triage Stage:
  databases  |  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:   => worksforme


Comment:

 Is the error consistent? I ran your sample project ten times and the test
 usually passes. Once in a while, I see this failure:
 {{{
 ==
 FAIL: testStuff (bugdemo.tests.TestDatabaseLocking)
 --
 Traceback (most recent call last):
   File "/home/tim/code/django-bug-demo/bugdemo/tests.py", line 75, in
 testStuff
 self.assertEqual(Question.objects.count(), 30)
 AssertionError: 29 != 30
 }}}
 I think you'll have to explain why Django is at fault to move this report
 forward. Possibly the problem might be dependent on the Python version. I
 tested with Python 3.4.7, 3.5.5, and 3.6.4.

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

Re: [Django] #29026: Make makemigrations scriptable / script-friendly

[Django]

#29026: Make makemigrations scriptable / script-friendly
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  makemigrations,scripting,stderr,stdout|
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:

 I'm skeptical, but I guess if you have a patch to propose, we can evaluate
 it.

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

Re: [Django] #29040: test database creation log output doesn't use consistent stream

[Django]

#29040: test database creation log output doesn't use consistent stream
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  stdout,stderr,database,creation|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 The problem with logging is that we
 [https://docs.djangoproject.com/en/dev/topics/logging/#disabling-logging-
 configuration document how to disable it]
 (c633667da3605208ea5fc137f5322c599f48da69) so we can't generally rely on
 it, at least without it being a backwards-incompatible change for users
 who have done 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.dfb6add437aa4b3b7237c479b6d34e1c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29126: Model.update_or_create method pk issue.

[Django]

#29126: Model.update_or_create method pk issue.
-+-
 Reporter:  Théo "Bob" Massard   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Can you please include the model and steps to reproduce?

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

Re: [Django] #29129: Child model updates parent model with empty fields making an extra query in multi-inheritance when parent model has custom PK (was: Child model updates parent model with empty fie

[Django]

#29129: Child model updates parent model with empty fields making an extra 
query in
multi-inheritance when parent model has custom PK
-+-
 Reporter:  user0007 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 That does look unexpected. Reproduced at
 cb7860ccedb199cb221c9e084b5104978b246356.

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

Re: [Django] #29130: floatformat is rounding off incorrectly

[Django]

#29130: floatformat is rounding off incorrectly
-+-
 Reporter:  Akash Deshpande  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  template float   | Triage Stage:
  filter |  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:   => invalid


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

Re: [Django] #29010: Allow customizing the autocomplete search results based on the querying model

[Django]

#29010: Allow customizing the autocomplete search results based on the querying
model
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignKey,  | Triage Stage:  Accepted
  get_search_results, search_fields  |
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


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