Re: [Django] #31083: Add select_related support for Site.objects.get_current

2019-12-16 Thread Django 
#31083: Add select_related support for Site.objects.get_current
-+--
 Reporter:  Kris Ciccarello  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.sites|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Carlton Gibson):

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


Comment:

 Hi Kris.

 Thanks for the report.

 > Given the use of `SITE_CACHE`…

 I'm not quite following the need for this here. `SITE_CACHE` holds the
 instantiated `Site` objects, which would fetch `detail` the first time it
 was accessed but then re-use the same fetched `SiteDetail` from memory,
 rather than re-hitting the database each time after that. (Yes?) So, I
 can't see there's much optimisation to be had...

 Beyond that, most uses of the sites framework are ''behind the scenes'' so
 it's not clear that users would have much opportunity to pass the
 select_related parameter. (Most times we're not calling
 `get_current_site()` ourselves.)

 As such, I don't think this is a needed addition. Please follow-up though
 if I've missed the point. Thanks.

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

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

Re: [Django] #31094: Subquery uses ungrouped column "table.column" from outer query.

2019-12-16 Thread Django 
#31094: Subquery uses ungrouped column "table.column" from outer query.
-+-
 Reporter:  Johannes Hoppe   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 Simon Charette):

 * has_patch:  0 => 1


Comment:

 Hey Johannes, I'd gladly provide answers to your questions on
 https://github.com/django/django/pull/12227 if you have any.

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

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

Re: [Django] #31094: Subquery uses ungrouped column "table.column" from outer query.

2019-12-16 Thread Django 
#31094: Subquery uses ungrouped column "table.column" from outer query.
-+-
 Reporter:  Johannes Hoppe   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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
-+-

Comment (by Johannes Hoppe):

 Hey Simon, I have only limited experience with this part of the ORM, so I
 don't know if I can be of much help. However, I am happy to review
 anything you throw at me. Best -Joe

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

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

Re: [Django] #31086: Improve error message for admin.E202.

2019-12-16 Thread Django 
#31086: Improve error message for admin.E202.
-+-
 Reporter:  Collin Anderson  |Owner:  shubham
 Type:   |  singh
  Cleanup/optimization   |   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:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => assigned
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.75bcf8b11a150747c78c30d0d867f35e%40djangoproject.com.

Re: [Django] #31095: Related Manager set() should prepare values before checking for missing elements. (was: Django Related Manager set method may not work with pk strings)

2019-12-16 Thread Django 
#31095: Related Manager set() should prepare values before checking for missing
elements.
-+-
 Reporter:  TZanke   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * version:  1.11 => master
 * type:  Bug => Cleanup/optimization
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 We cannot raise an exception on strings because `set()` accepts the field
 the relation points, e.g. `CharField`. However we can optimize this with
 preparing values, i.e.
 {{{
 diff --git a/django/db/models/fields/related_descriptors.py
 b/django/db/models/fields/related_descriptors.py
 index a9445d5d10..9f82ca4e8c 100644
 --- a/django/db/models/fields/related_descriptors.py
 +++ b/django/db/models/fields/related_descriptors.py
 @@ -999,7 +999,7 @@ def create_forward_many_to_many_manager(superclass,
 rel, reverse):
  for obj in objs:
  fk_val = (
 self.target_field.get_foreign_related_value(obj)[0]
 -if isinstance(obj, self.model) else obj
 +if isinstance(obj, self.model) else
 self.target_field.get_prep_value(obj)
  )
  if fk_val in old_ids:
  old_ids.remove(fk_val)
 }}}

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

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

Re: [Django] #31086: Improve error message for admin.E202.

2019-12-16 Thread Django 
#31086: Improve error message for admin.E202.
-+-
 Reporter:  Collin Anderson  |Owner:  shubham
 Type:   |  singh
  Cleanup/optimization   |   Status:  new
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:  1|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 PR is not merged so ticket is not 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.b9c2c09a630735c739acba6d047e0502%40djangoproject.com.

Re: [Django] #31086: Improve error message for admin.E202.

2019-12-16 Thread Django 
#31086: Improve error message for admin.E202.
-+-
 Reporter:  Collin Anderson  |Owner:  shubham
 Type:   |  singh
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  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:  1|UI/UX:  0
-+-
Changes (by shubham singh ):

 * cc: shubham singh  (added)
 * status:  assigned => closed
 * has_patch:  0 => 1
 * resolution:   => fixed


Comment:

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

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

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

Re: [Django] #31097: StringAgg And ArrayAgg with filtering in subquery generates invalid string_agg() SQL function call

2019-12-16 Thread Django 
#31097: StringAgg And ArrayAgg with filtering in subquery generates invalid
string_agg() SQL function call
--+
 Reporter:  Laurent Tramoy|Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  3.0
 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 Baptiste Mispelon):

 * version:  2.2 => 3.0
 * stage:  Unreviewed => Accepted


Comment:

 Reproduced on current master (ff00a053478fee06bdfb4206c6d4e079e98640ff)
 using the code in the ticket.

 Here's the prettified query reported by `--debug-sql` after the testcase
 failure:
 {{{#!sql lineno=1 marks=20
 SELECT
   "aaticket31097_book"."id",
   "aaticket31097_book"."category"
 FROM
   "aaticket31097_book"
 WHERE
   "aaticket31097_book"."id" IN (
 SELECT
   U0."id"
 FROM
   "aaticket31097_book" U0
   LEFT OUTER JOIN "aaticket31097_book_people" U1 ON (U0."id" =
 U1."book_id")
   LEFT OUTER JOIN "aaticket31097_person" U2 ON (U1."person_id" =
 U2."id")
 WHERE
   U0."id" = "aaticket31097_book"."id"
 GROUP BY
   U0."id"
 HAVING
   NOT (
 STRING_AGG(, ',') FILTER (
   WHERE
 U2."first_name"
 ) = ''
   )
   )
 }}}

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

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

Re: [Django] #31034: Add a navigation sidebar to the admin

2019-12-16 Thread Django 
#31034: Add a navigation sidebar to the admin
---+---
 Reporter:  Tom Carrick|Owner:  Tom Carrick
 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:  1
---+---
Changes (by Tom Carrick):

 * needs_better_patch:  1 => 0


Comment:

 Thanks. I've fixed that, now I'm just having a problem figuring out the
 test failure.

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

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

Re: [Django] #31097: StringAgg And ArrayAgg with filtering in subquery generates invalid string_agg() SQL function call

2019-12-16 Thread Django 
#31097: StringAgg And ArrayAgg with filtering in subquery generates invalid
string_agg() SQL function call
--+--
 Reporter:  Laurent Tramoy|Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  2.2
 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 Simon Charette):

 The fact the grouping conditions are surfaced to the outer query makes me
 believe it could be related to another issue that was addressed in 3.0.
 Could you try reproducing with Django 3.0 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.246fea9b92251a6c15966a8500061fc2%40djangoproject.com.

[Django] #31097: StringAgg And ArrayAgg with filtering in subquery generates invalid string_agg() SQL function call

2019-12-16 Thread Django 
#31097: StringAgg And ArrayAgg with filtering in subquery generates invalid
string_agg() SQL function call
+
   Reporter:  Laurent Tramoy|  Owner:  (none)
   Type:  Bug   | Status:  new
  Component:  contrib.postgres  |Version:  2.2
   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 similar to issue #30315 but using the `filter` keyword
 instead of `ordering`, so I'll reuse the same structure. I tested it on
 Django 2.2.8

 Consider the following models (in the people app):

 {{{
 from django.db import models
 from django.contrib.postgres.fields import ArrayField


 class Person(models.Model):
 """Person model."""

 first_name = models.TextField()
 last_name = models.TextField()
 country = models.TextField(null=True, blank=True)


 class Book(models.Model):
 """Book model."""
 category = ArrayField(models.CharField(max_length=32), null=True,
 default=list)
 people = models.ManyToManyField(Person)
 }}}

 with the following objects:
 {{{
 p1 = Person.objects.create(first_name="John", last_name="Doe")
 p2 = Person.objects.create(first_name="Jane", last_name="Doe")

 b1 = Book.objects.create()
 b1.people.add(p1)

 b2 = Book.objects.create()
 b2.people.add(p1, p2)

 b3 = Book.objects.create()
 }}}

 This fails:
 {{{
 from django.contrib.postgres.aggregates import StringAgg
 from django.db.models import Subquery, OuterRef, Q

 from people.models import  Book

 subquery = (
 Book.objects.annotate(
 _annotated_value=StringAgg(
 "people__first_name", ",",
 filter=Q(people__first_name__startswith="Ja")
 ),
 )
 .filter(pk=OuterRef("pk"),)
 .exclude(_annotated_value="")
 .values("id")
 )
 Book.objects.filter(id__in=Subquery(subquery))
 }}}

 The generated SQL is

 {{{
 SELECT
 "people_book"."id",
 "people_book"."category"
 FROM
 "people_book"
 WHERE
 "people_book"."id" IN (
 SELECT
 U0."id"
 FROM
 "people_book" U0
 LEFT OUTER JOIN "people_book_people" U1 ON (U0."id" =
 U1."book_id")
 LEFT OUTER JOIN "people_person" U2 ON (U1."person_id" = U2."id")
 WHERE
 U0."id" = ("people_book"."id")
 GROUP BY
 U0."id"
 HAVING
 NOT (STRING_AGG(, ',') FILTER (WHERE U2."first_name") =))
 }}}

 as we can see, the `STRING_AGG argument is wrong.

 The same query without the `filter` works fine:

 {{{
 subquery = (
 Book.objects.annotate(
 _annotated_value=StringAgg(
 "people__first_name", ","
 ),
 )
 .filter(pk=OuterRef("pk"),)
 .exclude(_annotated_value="")
 .values("id")
 )
 Book.objects.filter(id__in=Subquery(subquery))
 }}}

 SQL query:

 {{{
 SELECT
 "people_book"."id",
 "people_book"."category"
 FROM
 "people_book"
 WHERE
 "people_book"."id" IN (
 SELECT
 U0."id"
 FROM
 "people_book" U0
 LEFT OUTER JOIN "people_book_people" U1 ON (U0. "id" =
 U1."book_id")
 LEFT OUTER JOIN "people_person" U2 ON (U1."person_id" = U2."id")
 WHERE
 U0."id" = ("people_book"."id")
 GROUP BY
 U0."id"
 HAVING
 NOT (STRING_AGG(U2."first_name", ',') =))
 }}}


 as well as the same query without using `Subquery`:

 {{{
 query = (
 Book.objects.annotate(
 _annotated_value=StringAgg(
 "people__first_name", ",",
 filter=Q(people__first_name__startswith="Ja")
 ),
 )
 .exclude(_annotated_value="")
 )
 }}}

 SQL query:

 {{{
 SELECT
 "people_book"."id",
 "people_book"."category",
 STRING_AGG("people_person"."first_name", ',') FILTER (WHERE
 "people_person"."first_name"::text LIKE Ja %) AS "_annotated_value"
 FROM
 "people_book"
 LEFT OUTER JOIN "people_book_people" ON ("people_book"."id" =
 "people_book_people"."book_id")
 LEFT OUTER JOIN "people_person" ON ("people_book_people"."person_id" =
 "people_person"."id")
 GROUP BY
 "people_book"."id"
 HAVING
 NOT (STRING_AGG("people_person"."first_name", ',') FILTER (WHERE
 ("people_person"."first_name"::text LIKE Ja %)) =)
 }}}

 Just to make sure I wasn't using an old version, I tried the query from
 #30315, which works fine.

 NB: I originally noticed that bug using ArrayAgg instead of StringAgg, but
 I encountered another bug using ArrayAgg (or at least what I think is a
 bug) while writing the example code, I'll report it later if needed

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

Re: [Django] #22014: `prefetch_related` recursion protection does not cover all cases

2019-12-16 Thread Django 
#22014: `prefetch_related` recursion protection does not cover all cases
-+-
 Reporter:  StillNewb|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  prefetch | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Baptiste Mispelon):

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


Comment:

 Using a modified version of the `prefetch_recursion_protection_fail.diff​`
 patch attached at the top of the ticket, I was able to run the provided
 test against the latest master and the problem seems to have been fixed.

 Using `git bisect`, I found that the commit that fixed the attached
 failing test was bdbe50a491ca41e7d4ebace47bfe8abe50a58211.

 Sadly, link from comment:2 is now dead so I can't reproduce any infinite
 recursion error so I'm going to draw the same conclusion as I did in
 comment:1:

 I'm going to close this ticket as `needsinfo`. Please reopen if you can
 provide some steps to reproduce the issue (ideally in the form of a unit
 test against a current version of Django).

 Thanks.

 For reference, here's the modified testcase I used:
 {{{#!python
 class RecursionProtectionTests(TestCase):
 def setUp(self):
 self.book1 = Book.objects.create()
 self.book2 = Book.objects.create()
 self.author1 = Author.objects.create(first_book=self.book1,
 name='Author #1')
 self.author2 = Author.objects.create(first_book=self.book1,
 name='Author #2')
 self.publisher = Publisher.objects.create()
 self.author1.books.add(self.book1)
 self.author2.books.add(self.book2)
 self.book1.publishers.add(self.publisher)
 self.publisher.authors.add(self.author1, self.author2)

 def walk(self, authors):
 fetched_books = []
 for author in authors:
 for book in author.books.all():
 for publisher in book.publishers.all():
 for published_author in publisher.authors.all():
 for fetched_book in published_author.books.all():
 fetched_books.append(fetched_book)
 return fetched_books

 @override_settings(DEBUG=True)
 def test_descriptors_storing_protection1(self):
 qs1 =
 Author.objects.filter(pk=self.author1.pk).prefetch_related(Prefetch('books',
 Book.objects.prefetch_related('publishers__authors__books')),
 'books__publishers__authors__books')
 qs2 =
 Author.objects.filter(pk=self.author1.pk).prefetch_related(Prefetch('books',
 Book.objects.prefetch_related('publishers__authors__books')),
 'books__publishers__authors__books', 'books__publishers__authors__books')


 def count_queries(qs):
 offset = len(connection.queries)
 results = self.walk(qs)
 return results, len(connection.queries[offset:])

 results1, queries1 = count_queries(qs1)
 results2, queries2 = count_queries(qs2)

 self.assertEqual(len(results1), 2)
 self.assertEqual(len(results2), 2)

 self.assertEqual(queries1, queries2)


 @override_settings(DEBUG=True)
 def test_only_unique_queries(self):
 qs =
 Author.objects.filter(pk=self.author1.pk).prefetch_related(Prefetch('books',
 Book.objects.prefetch_related('publishers__authors__books')),
 'books__publishers__authors__books')
 offset = len(connection.queries)
 self.walk(qs)
 queries = [q['sql'] for q in connection.queries[offset:]]
 self.assertEqual(len(queries), len(set(queries)))
 }}}

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

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

Re: [Django] #31096: Massively improving ManyToMany caching when using in forms

2019-12-16 Thread Django 
#31096: Massively improving ManyToMany caching when using in forms
-+-
 Reporter:  László Károlyi   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM Caching Forms| Triage Stage:
  ManyToMany |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by László Károlyi:

Old description:

> Hey,
>
> after about half a day of investigating, I think I can provide a
> meaningful improvement to Django. Let me describe the issue:
>
> If you have a `ModelForm` that has `ManyToMany` fields after saving the
> relations, the cache — with all the `prefetch_related()` and
> `select_related()` queryset adjustments you might have used on the
> `ModelMultipleChoiceField`'s — will be lost. This often results in tons
> of unnecessary DB queries when using the saved instance from the
> `ModelForm`, because the relations on the newly constructed instance
> won't be cached yet, although they store the already adjusted relations
> from the form.
>
> My solution here goes down to `ManyToManyField.save_form_data()` to fix
> the problem, and patches it to store the cleaned/validated
> `ModelMultipleChoiceField` result on the model instance, thus keeping
> queryset optimizations, and results.
>
> I have a complete module for manipulating Django's ORM query caches on
> `ForeingKey` and `ManyToMany` fields, I'll paste that here for further
> review/improvement (it might not be perfect but works well for me), down
> at the bottom is the hot-replacing of the
> `ManyToManyField.save_form_data()`.
>
> Feel free to comment on it, but as a result, this change have saved me
> lots of DB queries when I log from the saved instance after the
> `ModelForm.save()` part. This module might spark some other ideas on
> behalf of core devs as to how to optimize the ORM further.
>
> The only downside I saw so far with this change is, it seems to ignore
> the `Model` ordering for some reason, so I had to patch my tests for
> flakyness.
>
> Here the module:
>
> {{{
> from typing import Iterable, Optional
>
> from django import VERSION
> from django.db.models.base import Model
> from django.db.models.fields.related import ManyToManyField
> from django.db.models.fields.reverse_related import ManyToOneRel
> from django.db.models.manager import Manager
> from django.db.models.query import QuerySet
>

> def invalidate_onetomany(objs: Iterable[Model], prefetch_keys:
> Iterable[str]):
> """
> Invalidate one-to-many caches. These are remote `ForeignKey` and
> `ManyToManyField` fields fetched with `prefetch_related()`.
> """
> if VERSION[0] == 1 or VERSION[0] == 2:
> for obj in objs:
> if not hasattr(obj, '_prefetched_objects_cache'):
> continue
> for key in prefetch_keys:
> if key not in obj._prefetched_objects_cache:
> continue
> del obj._prefetched_objects_cache[key]
>

> def invalidate_manytoone(objs: Iterable[Model], field_names:
> Iterable[str]):
> """
> Invalidate many-to-one caches. These are `ForeignKey` and
> `OneToOneField` fields fetched with `select_related()` or
> `prefetch_related()`.
> """
> if VERSION[0] == 1:
> for obj in objs:
> for field_name in field_names:
> if not is_fk_cached(obj=obj, field_name=field_name):
> continue
> del obj.__dict__[f'_{field_name}_cache']
> elif VERSION[0] == 2:
> for obj in objs:
> for field_name in field_names:
> if not is_fk_cached(obj=obj, field_name=field_name):
> continue
> del obj._state.fields_cache[field_name]
>

> def get_prefetch_cache_key(relation: Manager) -> str:
> 'Return a key used in the prefetched cache for a relation.'
> try:
> # Works on ManyToMany
> return relation.prefetch_cache_name
> except AttributeError:
> # Is a ForeignKey (OneToMany)
> rel_field = relation.field.remote_field  # type: ManyToOneRel
> if rel_field.related_name:
> return rel_field.related_name
> if VERSION[0] == 1:
> return rel_field.name
> elif VERSION[0] == 2:
> return f'{rel_field.name}_set'
>

> def init_prefetch_cache(obj: Model):
> 'Init a prefetch cache on the model.'
> if VERSION[0] == 1 or VERSION[0] == 2:

Re: [Django] #23051: QuerySet.only() fail to work with reverse o2o relationships

2019-12-16 Thread Django 
#23051: QuerySet.only() fail to work with reverse o2o relationships
-+-
 Reporter:  Vladimir Dmitriev|Owner:  Paulo
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm only reverse | Triage Stage:  Accepted
  relationship OneToOneField |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Baptiste Mispelon):

 As noted in comment:7 above, the usecase is now supported when used in
 conjunction with `select_related`.

 I did some bisecting to track down the commit involved and found out that
 two commits were actually involved:

 1) With 3daa9d60be6672841ceed5bb812b6fb25950dc16, Django started raising
 an error: `FieldError: Invalid field name(s) given in select_related:
 'personextra'. Choices are: personextra`
 2) With 0456a8b9e66608e2e7b7e64035d477f44c259c94, the error message
 disappeared and the feature started working

 For reference, here's the testcase that I used (using the models from the
 original ticket):
 {{{#!python
 class TicketTestCase(TestCase):
 def test_ticket(self):
 p = Person.objects.create(name="Baptiste")
 PersonExtra.objects.create(person=p, bio="yes")

 qs =
 list(Person.objects.select_related('personextra').only('name',
 'personextra__bio'))

 with self.assertNumQueries(0):
 self.assertEqual(len(qs), 1)
 self.assertEqual(qs[0].name, "Baptiste")
 self.assertEqual(qs[0].personextra.bio, "yes")
 }}}

 I haven't looked in details at the proposed pull request, but I do have
 some preliminary questions:

 1) Is it fundamentally impossible to support using a reverse o2o field in
 calls to `only()`? The PR adds an error message but I think it would be
 better if we could fix the issue instead.
 2) It seems that the problem exists for the case of a normal forward o2o
 (`PersonExtra.objects.only('person__name')` in our example) and also for
 reverse M2M (#30124). Does the PR address those too?

 Thanks

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

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

[Django] #31096: Massively improving ManyToMany caching when using in forms

2019-12-16 Thread Django 
#31096: Massively improving ManyToMany caching when using in forms
-+-
   Reporter:  László |  Owner:  nobody
  Károlyi|
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  2.2
  layer (models, ORM)|   Keywords:  ORM Caching Forms
   Severity:  Normal |  ManyToMany
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hey,

 after about half a day of investigating, I think I can provide a
 meaningful improvement to Django. Let me describe the issue:

 If you have a `ModelForm` that has `ManyToMany` fields after saving the
 relations, the cache — with all the `prefetch_related()` and
 `select_related()` queryset adjustments you might have used on the
 `ModelMultipleChoiceField`'s — will be lost. This often results in tons of
 unnecessary DB queries when using the saved instance from the `ModelForm`,
 because the relations on the newly constructed instance won't be cached
 yet, although they store the already adjusted relations from the form.

 My solution here goes down to `ManyToManyField.save_form_data()` to fix
 the problem, and patches it to store the cleaned/validated
 `ModelMultipleChoiceField` result on the model instance, thus keeping
 queryset optimizations, and results.

 I have a complete module for manipulating Django's ORM query caches on
 `ForeingKey` and `ManyToMany` fields, I'll paste that here for further
 review/improvement (it might not be perfect but works well for me), down
 at the bottom is the hot-replacing of the
 `ManyToManyField.save_form_data()`.

 Feel free to comment on it, but as a result, this change have saved me
 lots of DB queries when I log from the saved instance after the
 `ModelForm.save()` part. This module might spark some other ideas on
 behalf of core devs as to how to optimize the ORM further.

 The only downside I saw so far with this change is, it seems to ignore the
 `Model` ordering for some reason, so I had to patch my tests for
 flakyness.

 Here the module:

 {{{
 from typing import Iterable, Optional

 from django import VERSION
 from django.db.models.base import Model
 from django.db.models.fields.related import ManyToManyField
 from django.db.models.fields.reverse_related import ManyToOneRel
 from django.db.models.manager import Manager
 from django.db.models.query import QuerySet


 def invalidate_onetomany(objs: Iterable[Model], prefetch_keys:
 Iterable[str]):
 """
 Invalidate one-to-many caches. These are remote `ForeignKey` and
 `ManyToManyField` fields fetched with `prefetch_related()`.
 """
 if VERSION[0] == 1 or VERSION[0] == 2:
 for obj in objs:
 if not hasattr(obj, '_prefetched_objects_cache'):
 continue
 for key in prefetch_keys:
 if key not in obj._prefetched_objects_cache:
 continue
 del obj._prefetched_objects_cache[key]


 def invalidate_manytoone(objs: Iterable[Model], field_names:
 Iterable[str]):
 """
 Invalidate many-to-one caches. These are `ForeignKey` and
 `OneToOneField` fields fetched with `select_related()` or
 `prefetch_related()`.
 """
 if VERSION[0] == 1:
 for obj in objs:
 for field_name in field_names:
 if not is_fk_cached(obj=obj, field_name=field_name):
 continue
 del obj.__dict__[f'_{field_name}_cache']
 elif VERSION[0] == 2:
 for obj in objs:
 for field_name in field_names:
 if not is_fk_cached(obj=obj, field_name=field_name):
 continue
 del obj._state.fields_cache[field_name]


 def get_prefetch_cache_key(relation: Manager) -> str:
 'Return a key used in the prefetched cache for a relation.'
 try:
 # Works on ManyToMany
 return relation.prefetch_cache_name
 except AttributeError:
 # Is a ForeignKey (OneToMany)
 rel_field = relation.field.remote_field  # type: ManyToOneRel
 if rel_field.related_name:
 return rel_field.related_name
 if VERSION[0] == 1:
 return rel_field.name
 elif VERSION[0] == 2:
 return f'{rel_field.name}_set'


 def init_prefetch_cache(obj: Model):
 'Init a prefetch cache on the model.'
 if VERSION[0] == 1 or VERSION[0] == 2:
 if hasattr(obj, '_prefetched_objects_cache'):
 return
 obj._prefetched_objects_cache = {}


 def is_query_prefetched(relation:

Re: [Django] #31094: Subquery uses ungrouped column "table.column" from outer query.

2019-12-16 Thread Django 
#31094: Subquery uses ungrouped column "table.column" from outer query.
-+-
 Reporter:  Johannes Hoppe   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 Simon Charette):

 * owner:  nobody => Simon Charette
 * status:  new => assigned


Comment:

 I think the correct solution here will be to make
 `Subquery.get_group_by_cols` return all its `OuterRef` expressions when
 `alias is None`; that is the ones contained in its annotations and where
 clause.

 That would result in an additional `GROUP BY T4."position"` in the outer
 query as PostgreSQL expects.

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

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

Re: [Django] #31095: Django Related Manager set method may not work with pk strings (was: Django Related Manager set method)

2019-12-16 Thread Django 
#31095: Django Related Manager set method may not work with pk strings
-+-
 Reporter:  TZanke   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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
-+-

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

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

[Django] #31095: Django Related Manager set method

2019-12-16 Thread Django 
#31095: Django Related Manager set method
-+-
   Reporter:  TZanke |  Owner:  nobody
   Type:  Bug| Status:  new
  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  |
-+-
 To update a complete list of foreignkeys, we use set() method of
 relatedmanager to get a performance gain and avoid remove and add keys not
 touched by user.

 But today i noticed our database removes all foreignkeys and adds them
 again. After some debugging i found the issue in this condition:
 
https://github.com/django/django/blob/master/django/db/models/fields/related_descriptors.py#L1004

 Our form returns all Foreignkeys as list of strings in cleaned_data, but
 the strings do not match the pk (int). After converting the strings to
 int, before calling set(), fixes the problem.

 Question:
 How to avoid this issue? Maybe all code usages of set() are using lists of
 strings, maybe not. I dont know at the moment.
 Is is possible Django fixes this issue? Should Django fix the issue? Maybe
 strings should raise an exception?

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

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

Re: [Django] #31094: Subquery uses ungrouped column "table.column" from outer query.

2019-12-16 Thread Django 
#31094: Subquery uses ungrouped column "table.column" from outer query.
-+-
 Reporter:  Johannes Hoppe   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 felixxm):

 * Attachment "test-31094.diff" added.

 Regression test.

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

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

Re: [Django] #31094: Subquery uses ungrouped column "table.column" from outer query. (was: subquery uses ungrouped column "table.column" from outer query)

2019-12-16 Thread Django 
#31094: Subquery uses ungrouped column "table.column" from outer query.
-+-
 Reporter:  Johannes Hoppe   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 felixxm):

 * cc: Simon Charette (added)
 * stage:  Unreviewed => Accepted
 * severity:  Normal => Release blocker


Comment:

 I was able to reproduce this issue with attached test, thanks for the
 report.

 Regression in fb3f034f1c63160c0ff13c609acd01c18be12f80.

 Reproduced at 972d93a95ec8b37fab84400417070b7439414967.

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

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

Re: [Django] #31088: Added support for webquery search to SearchQuery() on PostgreSQL 11+.

2019-12-16 Thread Django 
#31088: Added support for webquery search to SearchQuery() on PostgreSQL 11+.
-+-
 Reporter:  James Turk   |Owner:  James
 |  Turk
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  search, webquery,| Triage Stage:  Accepted
  postgres   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"ff00a053478fee06bdfb4206c6d4e079e98640ff" ff00a053]:
 {{{
 #!CommitTicketReference repository=""
 revision="ff00a053478fee06bdfb4206c6d4e079e98640ff"
 Fixed #31088 -- Added support for websearch searching in SearchQuery.
 }}}

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

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

Re: [Django] #31034: Add a navigation sidebar to the admin

2019-12-16 Thread Django 
#31034: Add a navigation sidebar to the admin
---+---
 Reporter:  Tom Carrick|Owner:  Tom Carrick
 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:  1
---+---
Changes (by felixxm):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c29b2fd004e0bb40b76861fb533f7960%40djangoproject.com.

Re: [Django] #18174: Model inheritance pointers doesn't refer to parent to refer to grandparents

2019-12-16 Thread Django 
#18174: Model inheritance pointers doesn't refer to parent to refer to 
grandparents
-+-
 Reporter:  phowe|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 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 Baptiste Mispelon):

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


Comment:

 I believe this god fixed but it's hard to pinpoint exactly what commit did
 it.

 Using the provided testcase from comment:6, I was able to bisect but it
 seems that the issue got fixed in two separate steps. Here's a rough
 timeline:

 0) (this issue is reported). Django is at 1.4 and the testcase fails with
 something like `AssertionError: u'appname_top' != 'appname_middle'`.
 1) Enters commit 68985db48212c701a3d975636123a5d79bdc006f (part of the 1.6
 release which changes the error: `OperationalError: no such column:
 appname_middle.b2_id`
 2) Finally with commit 38e24d680d28b92997def9ab46a961d09bb81dce (1.7
 release), the testcase passes.

 The test added with 38e24d680d28b92997def9ab46a961d09bb81dce is not
 exactly the same as the one attached to this ticket but I'm pretty
 confident that they're similar enough:

 * Both involve a 3-step inheritance chain with multiple inheritance in the
 middle model.
 * Both test raise the same error prior to the fix (`OperationalError: no
 such column: appname_middle.b2_id`)


 Therefore I think this ticket can be marked as 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.47e3a4907b4f01b150d911ae816bd7e1%40djangoproject.com.

Re: [Django] #31094: subquery uses ungrouped column "table.column" from outer query

2019-12-16 Thread Django 
#31094: subquery uses ungrouped column "table.column" from outer query
-+-
 Reporter:  Johannes Hoppe   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.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 felixxm):

 I agree that there is probably some regression in such queries, but it's
 really hard to restore the original queryset from a raw SQL. Can you
 provide a queryset? If not I will try to reproduce this issue in our test
 suite.

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

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

Re: [Django] #29682: Admin change form crashes if a view-only model's form has field not on the model

2019-12-16 Thread Django 
#29682: Admin change form crashes if a view-only model's form has field not on 
the
model
-+
 Reporter:  Jones|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 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 felixxm):

 * status:  new => closed
 * version:  2.2 => 2.1
 * resolution:   => fixed


Comment:

 As far as I'm concerned a custom form field cannot be in the
 `readonly_fields`, e.g.

 {{{
 : (admin.E035) The value of
 'readonly_fields[0]' is not a callable, an attribute of 'ArticleAdmin', or
 an attribute of 'admin_views.Article'.
 }}}

 Please open a new ticket with a sample project if you believe that there
 is any issue with `readonly_fields`.

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

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

Re: [Django] #31090: Log when DB transactions are commited and rollbacked.

2019-12-16 Thread Django 
#31090: Log when DB transactions are commited and rollbacked.
-+-
 Reporter:  Petter Strandmark|Owner:  Petter
 |  Strandmark
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Note: `BEGIN` is logged only on SQLite as a workaround to start a
 transaction explicitly in autocommit mode, you will not find it in loggers
 for other databases.

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

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

Re: [Django] #29682: Admin change form crashes if a view-only model's form has field not on the model

2019-12-16 Thread Django 
#29682: Admin change form crashes if a view-only model's form has field not on 
the
model
-+
 Reporter:  Jones|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.2
 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 fu2re):

 * status:  closed => new
 * version:  2.1 => 2.2
 * resolution:  fixed =>


Comment:

 Issue is still persist if a field is readonly as described above.

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

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

Re: [Django] #31094: subquery uses ungrouped column "table.column" from outer query

2019-12-16 Thread Django 
#31094: subquery uses ungrouped column "table.column" from outer query
-+-
 Reporter:  Johannes Hoppe   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.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 Johannes Hoppe):

 A quick diff of the query in both versions, shows a diff in the grouping
 section:

 {{{
 < GROUP BY "camps_offer"."id", "camps_provider"."id"
 ---
 > GROUP BY "camps_offer"."id",
 >  (SELECT U0."id"
 >   FROM "camps_servicepackage" U0
 >INNER JOIN "camps_region" U2 ON (U0."region_id" =
 U2."id")
 >   WHERE (U0."company_id" = 1 AND U0."option" =
 ("camps_offer"."activity_type") AND
 >  ST_Contains(U2."locations", (T4."position")))
 >   LIMIT 1), "camps_provider"."id"
 }}}

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

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

Re: [Django] #31076: dbshell crashes on Windows and Python < 3.8.

2019-12-16 Thread Django 
#31076: dbshell crashes on Windows and Python < 3.8.
-+-
 Reporter:  felixxm  |Owner:  zeynel
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"9d40b6bbf44d0de4d446dde5b9b51cadb60a24a3" 9d40b6bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="9d40b6bbf44d0de4d446dde5b9b51cadb60a24a3"
 Fixed #31076 -- Fixed dbshell crash on Windows with Python < 3.8.

 subprocess.run()'s args parameter accepts path-like objects on Windows
 since Python 3.8.
 }}}

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

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

Re: [Django] #31094: subquery uses ungrouped column "table.column" from outer query

2019-12-16 Thread Django 
#31094: subquery uses ungrouped column "table.column" from outer query
-+-
 Reporter:  Johannes Hoppe   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.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
-+-
Description changed by Johannes Hoppe:

Old description:

> Why upgrading to Django 3.0 I get the following issue:
> {{{
> subquery uses ungrouped column "t4.position" from outer query
> LINE 1: ..."."activity_type" AND ST_Contains(U2."locations",
> T4."positi...
> }}}
>
> It works fine in Django 2.2.8.
>
> Stack:
> Python 3.8
> PostgeSQL 11
> macOS / Ubuntu latest
>
> Full query in 3.0 (pretty)
> {{{
> SELECT DISTINCT "camps_offer"."id", "camps_offer"."title",
> "camps_offer"."slug", "camps_offer"."is_active",
> "camps_offer"."modified", "camps_offer"."created",
> "camps_offer"."provider_id", "camps_offer"."activity_type",
> "camps_offer"."description", "camps_offer"."highlights",
> "camps_offer"."important_information", "camps_offer"."min_age",
> "camps_offer"."max_age", "camps_offer"."food", "camps_offer"."video",
> "camps_offer"."accommodation", "camps_offer"."accommodation_type",
> "camps_offer"."room_type", "camps_offer"."room_size_min",
> "camps_offer"."room_size_max", "camps_offer"."external_url",
> "camps_offer"."application_form", "camps_offer"."caseload",
> "camps_offer"."field_trips", MIN(T4."retail_price") AS
> "min_retail_price", (SELECT U0."id" FROM "camps_servicepackage" U0 INNER
> JOIN "camps_region" U2 ON (U0."region_id" = U2."id") WHERE
> (U0."company_id" = 1 AND U0."option" = "camps_offer"."activity_type" AND
> ST_Contains(U2."locations", T4."position")) LIMIT 1) AS "in_package",
> "camps_provider"."id", "camps_provider"."title", "camps_provider"."slug",
> "camps_provider"."is_active", "camps_provider"."modified",
> "camps_provider"."created", "camps_provider"."logo",
> "camps_provider"."description", "camps_provider"."video",
> "camps_provider"."external_url", "camps_provider"."terms",
> "camps_provider"."cancellation_policy",
> "camps_provider"."privacy_policy", "camps_provider"."application_form"
> FROM "camps_offer" LEFT OUTER JOIN "camps_bookingoption" ON
> ("camps_offer"."id" = "camps_bookingoption"."offer_id") INNER JOIN
> "camps_provider" ON ("camps_offer"."provider_id" = "camps_provider"."id")
> INNER JOIN "camps_bookingoption" T4 ON ("camps_offer"."id" =
> T4."offer_id") WHERE ("camps_offer"."is_active" = True AND
> "camps_provider"."is_active" = True AND T4."end" >= STATEMENT_TIMESTAMP()
> AND T4."is_active" = True AND (SELECT U0."id" FROM "camps_servicepackage"
> U0 INNER JOIN "camps_region" U2 ON (U0."region_id" = U2."id") WHERE
> (U0."company_id" = 1 AND U0."option" = "camps_offer"."activity_type" AND
> ST_Contains(U2."locations", T4."position")) LIMIT 1) IS NOT NULL) GROUP
> BY "camps_offer"."id", "camps_provider"."id" ORDER BY
> "camps_offer"."created" ASC
> }}}
>
> Full query in 2.2 (pretty)
> {{{
> SELECT DISTINCT "camps_offer"."id",
> "camps_offer"."title",
> "camps_offer"."slug",
> "camps_offer"."is_active",
> "camps_offer"."modified",
> "camps_offer"."created",
> "camps_offer"."provider_id",
> "camps_offer"."activity_type",
> "camps_offer"."description",
> "camps_offer"."highlights",
> "camps_offer"."important_information",
> "camps_offer"."min_age",
> "camps_offer"."max_age",
> "camps_offer"."food",
> "camps_offer"."video",
> "camps_offer"."accommodation",
> "camps_offer"."accommodation_type",
> "camps_offer"."room_type",
> "camps_offer"."room_size_min",
> "camps_offer"."room_size_max",
> "camps_offer"."external_url",
> "camps_offer"."application_form",
> "camps_offer"."caseload",
> "camps_offer"."field_trips",
> MIN(T4."retail_price") AS "min_retail_price",
> (SELECT U0."id"
>  FROM "camps_servicepackage" U0
>   INNER JOIN "camps_region" U2 ON (U0."region_id"
> = U2."id")
>  WHERE (U0."company_id" = 1 AND U0."option" =
> ("camps_offer"."activity_type") AND
>

Re: [Django] #31094: subquery uses ungrouped column "table.column" from outer query

2019-12-16 Thread Django 
#31094: subquery uses ungrouped column "table.column" from outer query
-+-
 Reporter:  Johannes Hoppe   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.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
-+-
Changes (by Johannes Hoppe):

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


Old description:

> Why upgrading to Django 3.0 I get the following issue:
> {{{
> subquery uses ungrouped column "t4.position" from outer query
> LINE 1: ..."."activity_type" AND ST_Contains(U2."locations",
> T4."positi...
> }}}
>
> Stack:
> Python 3.8
> PostgeSQL 11
> macOS / Ubuntu latest
>
> Full stack trace
> {{{
> Environment:
>

> Request Method: GET
> Request URL: http://localhost:8000/api/offer-map/
>
> Django Version: 3.0
> Python Version: 3.8.0
> Installed Applications:
> ['django.contrib.auth',
>  'django.contrib.sites',
>  'django.contrib.contenttypes',
>  '...',
>  '',
>  '',
>  'django.contrib.admin',
>  'django.contrib.sessions',
>  'django.contrib.messages',
>  'whitenoise.runserver_nostatic',
>  'django.contrib.staticfiles',
>  'django.contrib.postgres',
>  'django.contrib.gis',
>  'django.forms',
>  'django_dramatiq',
>  'mailauth',
>  'mailauth.contrib.admin',
>  's3file',
>  'stdimage',
>  'adminsortable2',
>  'rest_framework',
>  'rest_framework_gis',
>  'django_filters',
>  'phonenumber_field',
>  '...']
> Installed Middleware:
> ['log_request_id.middleware.RequestIDMiddleware',
>  'voiio.logging.middleware.UserAgentLogMiddleware',
>  'django.middleware.gzip.GZipMiddleware',
>  'django.middleware.security.SecurityMiddleware',
>  'whitenoise.middleware.WhiteNoiseMiddleware',
>  'django.contrib.sessions.middleware.SessionMiddleware',
>  'django.middleware.locale.LocaleMiddleware',
>  'django.middleware.common.CommonMiddleware',
>  'django.middleware.csrf.CsrfViewMiddleware',
>  'django.contrib.auth.middleware.AuthenticationMiddleware',
>  'django.contrib.messages.middleware.MessageMiddleware',
>  'django.middleware.clickjacking.XFrameOptionsMiddleware',
>  's3file.middleware.S3FileMiddleware',
>  'accounts.middleware.CompanyMiddleware']
>

>
> Traceback (most recent call last):
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/django/db/backends/utils.py", line 86, in _execute
> return self.cursor.execute(sql, params)
>
> The above exception (subquery uses ungrouped column "t4.position" from
> outer query
> LINE 1: ..."."activity_type" AND ST_Contains(U2."locations",
> T4."positi...
>  ^
> ) was the direct cause of the following exception:
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/django/core/handlers/exception.py", line 34, in inner
> response = get_response(request)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/django/core/handlers/base.py", line 115, in _get_response
> response = self.process_exception_by_middleware(e, request)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/django/core/handlers/base.py", line 113, in _get_response
> response = wrapped_callback(request, *callback_args,
> **callback_kwargs)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
> return view_func(*args, **kwargs)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/rest_framework/viewsets.py", line 114, in view
> return self.dispatch(request, *args, **kwargs)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/rest_framework/views.py", line 505, in dispatch
> response = self.handle_exception(exc)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/rest_framework/views.py", line 465, in handle_exception
> self.raise_uncaught_exception(exc)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/rest_framework/views.py", line 476, in
> raise_uncaught_exception
> raise exc
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/rest_framework/views.py", line 502, in dispatch
> response = handler(request, *args, **kwargs)
>

Re: [Django] #31094: subquery uses ungrouped column "table.column" from outer query

2019-12-16 Thread Django 
#31094: subquery uses ungrouped column "table.column" from outer query
-+-
 Reporter:  Johannes Hoppe   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 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 felixxm):

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


Comment:

 Can you provide a queryset? We'll not be able to reproduce this issue
 without it. Can you also confirm that it works with Django 2.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.26ef3e272bae436acf3cff524469ce44%40djangoproject.com.

Re: [Django] #31094: subquery uses ungrouped column "table.column" from outer query

2019-12-16 Thread Django 
#31094: subquery uses ungrouped column "table.column" from outer query
-+-
 Reporter:  Johannes Hoppe   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.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
-+-
Description changed by Johannes Hoppe:

Old description:

> Why upgrading to Django 3.0 I get the following issue:
> {{{
> subquery uses ungrouped column "t4.position" from outer query
> LINE 1: ..."."activity_type" AND ST_Contains(U2."locations",
> T4."positi...
> }}}
>

> Full stack trace
> {{{
> Environment:
>

> Request Method: GET
> Request URL: http://localhost:8000/api/offer-map/
>
> Django Version: 3.0
> Python Version: 3.8.0
> Installed Applications:
> ['django.contrib.auth',
>  'django.contrib.sites',
>  'django.contrib.contenttypes',
>  '...',
>  '',
>  '',
>  'django.contrib.admin',
>  'django.contrib.sessions',
>  'django.contrib.messages',
>  'whitenoise.runserver_nostatic',
>  'django.contrib.staticfiles',
>  'django.contrib.postgres',
>  'django.contrib.gis',
>  'django.forms',
>  'django_dramatiq',
>  'mailauth',
>  'mailauth.contrib.admin',
>  's3file',
>  'stdimage',
>  'adminsortable2',
>  'rest_framework',
>  'rest_framework_gis',
>  'django_filters',
>  'phonenumber_field',
>  '...']
> Installed Middleware:
> ['log_request_id.middleware.RequestIDMiddleware',
>  'voiio.logging.middleware.UserAgentLogMiddleware',
>  'django.middleware.gzip.GZipMiddleware',
>  'django.middleware.security.SecurityMiddleware',
>  'whitenoise.middleware.WhiteNoiseMiddleware',
>  'django.contrib.sessions.middleware.SessionMiddleware',
>  'django.middleware.locale.LocaleMiddleware',
>  'django.middleware.common.CommonMiddleware',
>  'django.middleware.csrf.CsrfViewMiddleware',
>  'django.contrib.auth.middleware.AuthenticationMiddleware',
>  'django.contrib.messages.middleware.MessageMiddleware',
>  'django.middleware.clickjacking.XFrameOptionsMiddleware',
>  's3file.middleware.S3FileMiddleware',
>  'accounts.middleware.CompanyMiddleware']
>

>
> Traceback (most recent call last):
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/django/db/backends/utils.py", line 86, in _execute
> return self.cursor.execute(sql, params)
>
> The above exception (subquery uses ungrouped column "t4.position" from
> outer query
> LINE 1: ..."."activity_type" AND ST_Contains(U2."locations",
> T4."positi...
>  ^
> ) was the direct cause of the following exception:
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/django/core/handlers/exception.py", line 34, in inner
> response = get_response(request)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/django/core/handlers/base.py", line 115, in _get_response
> response = self.process_exception_by_middleware(e, request)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/django/core/handlers/base.py", line 113, in _get_response
> response = wrapped_callback(request, *callback_args,
> **callback_kwargs)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
> return view_func(*args, **kwargs)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/rest_framework/viewsets.py", line 114, in view
> return self.dispatch(request, *args, **kwargs)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/rest_framework/views.py", line 505, in dispatch
> response = self.handle_exception(exc)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/rest_framework/views.py", line 465, in handle_exception
> self.raise_uncaught_exception(exc)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/rest_framework/views.py", line 476, in
> raise_uncaught_exception
> raise exc
>   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
> /site-packages/rest_framework/views.py", line 502, in dispatch
> response = handler(request, *args, **kwargs)
>   File "/Users/johannes/GitHub/voiio/voiio-platform/camps/viewsets.py",
> line 344, in list
> page =

[Django] #31094: subquery uses ungrouped column "table.column" from outer query

2019-12-16 Thread Django 
#31094: subquery uses ungrouped column "table.column" from outer query
-+-
   Reporter:  Johannes   |  Owner:  nobody
  Hoppe  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  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  |
-+-
 Why upgrading to Django 3.0 I get the following issue:
 {{{
 subquery uses ungrouped column "t4.position" from outer query
 LINE 1: ..."."activity_type" AND ST_Contains(U2."locations", T4."positi...
 }}}


 Full stack trace
 {{{
 Environment:


 Request Method: GET
 Request URL: http://localhost:8000/api/offer-map/

 Django Version: 3.0
 Python Version: 3.8.0
 Installed Applications:
 ['django.contrib.auth',
  'django.contrib.sites',
  'django.contrib.contenttypes',
  '...',
  '',
  '',
  'django.contrib.admin',
  'django.contrib.sessions',
  'django.contrib.messages',
  'whitenoise.runserver_nostatic',
  'django.contrib.staticfiles',
  'django.contrib.postgres',
  'django.contrib.gis',
  'django.forms',
  'django_dramatiq',
  'mailauth',
  'mailauth.contrib.admin',
  's3file',
  'stdimage',
  'adminsortable2',
  'rest_framework',
  'rest_framework_gis',
  'django_filters',
  'phonenumber_field',
  '...']
 Installed Middleware:
 ['log_request_id.middleware.RequestIDMiddleware',
  'voiio.logging.middleware.UserAgentLogMiddleware',
  'django.middleware.gzip.GZipMiddleware',
  'django.middleware.security.SecurityMiddleware',
  'whitenoise.middleware.WhiteNoiseMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.locale.LocaleMiddleware',
  'django.middleware.common.CommonMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware',
  'django.middleware.clickjacking.XFrameOptionsMiddleware',
  's3file.middleware.S3FileMiddleware',
  'accounts.middleware.CompanyMiddleware']



 Traceback (most recent call last):
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/django/db/backends/utils.py", line 86, in _execute
 return self.cursor.execute(sql, params)

 The above exception (subquery uses ungrouped column "t4.position" from
 outer query
 LINE 1: ..."."activity_type" AND ST_Contains(U2."locations", T4."positi...
  ^
 ) was the direct cause of the following exception:
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/django/core/handlers/exception.py", line 34, in inner
 response = get_response(request)
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/django/core/handlers/base.py", line 115, in _get_response
 response = self.process_exception_by_middleware(e, request)
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/django/core/handlers/base.py", line 113, in _get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
 return view_func(*args, **kwargs)
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/rest_framework/viewsets.py", line 114, in view
 return self.dispatch(request, *args, **kwargs)
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/rest_framework/views.py", line 505, in dispatch
 response = self.handle_exception(exc)
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/rest_framework/views.py", line 465, in handle_exception
 self.raise_uncaught_exception(exc)
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/rest_framework/views.py", line 476, in
 raise_uncaught_exception
 raise exc
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/rest_framework/views.py", line 502, in dispatch
 response = handler(request, *args, **kwargs)
   File "/Users/johannes/GitHub/voiio/voiio-platform/camps/viewsets.py",
 line 344, in list
 page = self.paginate_queryset(queryset)
   File "/Users/johannes/GitHub/voiio/voiio-platform/venv/lib/python3.8
 /site-packages/rest_framework/generics.py", line 171, in paginate_queryset
 return self.paginator.paginate_queryset(queryset,

Re: [Django] #31076: dbshell crashes on Windows and Python < 3.8.

2019-12-16 Thread Django 
#31076: dbshell crashes on Windows and Python < 3.8.
-+-
 Reporter:  felixxm  |Owner:  zeynel
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


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

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

Re: [Django] #31090: Log when DB transactions are commited and rollbacked.

2019-12-16 Thread Django 
#31090: Log when DB transactions are commited and rollbacked.
-+-
 Reporter:  Petter Strandmark|Owner:  Petter
 |  Strandmark
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_docs:  0 => 1


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

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

Re: [Django] #31093: Extend permission backend with get_queryset(user, model). (was: Extend permission backend with get_queryset(user, model))

2019-12-16 Thread Django 
#31093: Extend permission backend with get_queryset(user, model).
--+--
 Reporter:  James Pic |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by felixxm):

 * status:  new => closed
 * version:  3.0 => master
 * resolution:   => wontfix


Comment:

 Django's Admin already handles permissions properly. IMO a generic method
 for filtering a queryset based on an user object (and/or a permission
 name) shouldn't be added to the builtin authentication back-ends. You can
 start a discussion on DevelopersMailingList if you don't agree.

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

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