date:20170708

Re: [Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

2017-07-08 Thread Django

#28378: QuerySet.union() with queryset that raises EmptyResultSet results in an
empty set
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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
-+-
Description changed by Sergey Fedoseev:

Old description:

> Similar and followup to ticket #28293. Tested on Django 1.11.3.
>
> As QuerySet.union() uses the SQL UNION operator, I would expect "SET1
> UNION " to result in SET1. If the empty set is the results of
> [https://github.com/django/django/blob/5b450b84e14f42302f58ec1f15a67a368e64d85c/django/db/models/sql/where.py#L97
> EmpytResultSet being raised], the `.uion()` result is an empty set, not
> SET1.
>
> Example test case:
>
> {{{
> >>> import django
> >>> django.__version__
> '1.11.3'
> >>> from django.contrib.auth.models import User
> >>> qs1 = User.objects.all()
> >>> qs1.count()
> 100
> >>> qs2 = User.objects.filter(pk__in=[])
> >>> qs2.count()
> 0
> >>> list(qs1.union(qs2))
> []
> }}}

New description:

 Similar and followup to ticket #28293. Tested on Django 1.11.3.

 As QuerySet.union() uses the SQL UNION operator, I would expect "SET1
 UNION " to result in SET1. If the empty set is the results of
 
[https://github.com/django/django/blob/5b450b84e14f42302f58ec1f15a67a368e64d85c/django/db/models/sql/where.py#L97
 EmpytResultSet being raised], the `.union()` result is an empty set, not
 SET1.

 Example test case:

 {{{
 >>> import django
 >>> django.__version__
 '1.11.3'
 >>> from django.contrib.auth.models import User
 >>> qs1 = User.objects.all()
 >>> qs1.count()
 100
 >>> qs2 = User.objects.filter(pk__in=[])
 >>> qs2.count()
 0
 >>> list(qs1.union(qs2))
 []
 }}}

--

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

[Django] #28379: Improve handling lack of permissions in AccessMixin

2017-07-08 Thread Django

#28379: Improve handling lack of permissions in AccessMixin
-+-
Reporter: Dylan | Owner: nobody
Verheul|
Type: | Status: new
Cleanup/optimization |
Component: |Version: 1.11
contrib.auth |
Severity: Normal | Keywords: permissions
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+-
`AccessMixin` and derived classes offer a great way to handle permission
testing for class based views. However, the current default workflow for
handling failed permissions can lead to an endless loop of redirects, and
is hard to fix without resorting to writing a custom `AccessMixin` for
each project.

**Why is the current workflow wrong?**

The default way of handling "no permission" is to check for
`AccessMixin.raise_exception` (default: `False`). If
`AccessMixin.raise_exception` is `True`, then the `PermissionDenied`
exception is raised. Else (the default behavior), the user is redirected
to the `login_url`.

The `PermissionDenied` exception can be customized in Django by providing
a `403.html`. In this template, it is easy to explain to the user that
access was denied, and to check for possible solutions, such as loggin in
an authorized user. In my opinion, this should always be the default. Lack
of permissions in a Python application calls for an exception to be
raised.

However, the default behavior is to redirect to the `login_url`. What
happens to a **user that has not yet logged in** this scenario?

1. The anonymous user visits a URL, let's call it `show_me_something`
2. Permission is denied
3. The user is redirected to a login page, without any explanation
4. Upon successful login, the user will probably be redirected to the
original intent `show_me_something`

This isn't pretty, the user doesn't know what is going on. In my apps I
would always go for the exception to be raised and to show a 403 page that
explains that the uses has insufficient rights to view
`show_me_something`, offer the user a link to login and signup, and carry
over the url to `show_me_something` as a redirect upon succesful login.

What's worse is what happens to a user that is already logged in.

1. The authenticated user visits a URL, let's call it `show_me_something`
2. Permission is denied
3. The user is redirected to a login page, without any explanation, but
already logged in. Some login pages may even refuse access to a logged in
user and redirect them. More confusion!
4. The only logical thing for the user to do is to provide login
credentials again.
5. Upon successful login, the user will probably be redirected to the
original intent `show_me_something`, where permission will be denied
again, goto 1.

**What should be improved**

My suggestions are:

1. All in all I'd say always raise the `PermissionDenied` exception and
have one way to handle missing permissions (DRY). That would mean at least
changing the default value for `AccessMixin.raise_exception` to `True`,
and possible even deprecate it. Currently, setting `raise_exception` to
False is a recipe for writing views that confuse users and even make them
end up in endless loops.

2. If raising the exception is not the behavior in the AccessMixin, never
redirect a logged in user to the `login_url`, but raise `PermissionDenied`
instead. So change `handle_no_permission` to:

{{{
def handle_no_permission(self):
if self.raise_exception or self.request.user.is_authenticated:
raise PermissionDenied(self.get_permission_denied_message())
return redirect_to_login(self.request.get_full_path(),
self.get_login_url(), self.get_redirect_field_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 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/047.3d83bd9fa1e3bc5a64c810f4605fa24a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20880: Split clone() to clone() and pre_next_op()

2017-07-08 Thread Django

#20880: Split clone() to clone() and pre_next_op()
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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:

 Here's a [https://github.com/django/django/pull/8716 PR] without the
 "inplace" stuff. I think we can leave that to a separate ticket/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 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.0d1a07546cc4e69bc89e147dc9a81e4d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

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

2017-07-08 Thread Django

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

Comment (by Marcus Renno):

 Hi, any updates regarding this ticket?

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

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

Re: [Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

2017-07-08 Thread Django

#28378: QuerySet.union() with queryset that raises EmptyResultSet results in an
empty set
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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: felixxm (added)


Comment:

 I attached tests.

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

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

Re: [Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

2017-07-08 Thread Django

#28378: QuerySet.union() with queryset that raises EmptyResultSet results in an
empty set
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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 "28378.diff" added.


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

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

Re: [Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

2017-07-08 Thread Django

#28378: QuerySet.union() with queryset that raises EmptyResultSet results in an
empty set
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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 felixxm):

 `difference` is also affected.

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

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

Re: [Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

2017-07-08 Thread Django

#28378: QuerySet.union() with queryset that raises EmptyResultSet results in an
empty set
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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):

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


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

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

Re: [Django] #28373: TIME_ZONE value in DATABASES settings is not used for date lookup

2017-07-08 Thread Django

#28373: TIME_ZONE value in DATABASES settings is not used for date lookup
-+-
 Reporter:  Victor Talpaert  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  settings ORM lookup  | Triage Stage:  Accepted
  mysql timezone |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Looks reasonable at a brief review.

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

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

Re: [Django] #28377: Retain order of form media assets during aggregation

2017-07-08 Thread Django

#28377: Retain order of form media assets during aggregation
--+
 Reporter:  Johannes Hoppe|Owner:  info@…
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Forms |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/8667 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 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.033c2a0ab866867da0f4b8e081b1be08%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

2017-07-08 Thread Django

#28378: QuerySet.union() with queryset that raises EmptyResultSet results in an
empty set
-+-
   Reporter:  Jon|  Owner:  nobody
  Dufresne   |
   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  |
-+-
 Similar and followup to ticket #28293. Tested on Django 1.11.3.

 As QuerySet.union() uses the SQL UNION operator, I would expect "SET1
 UNION " to result in SET1. If the empty set is the results of
 
[https://github.com/django/django/blob/5b450b84e14f42302f58ec1f15a67a368e64d85c/django/db/models/sql/where.py#L97
 EmpytResultSet being raised], the `.uion()` result is an empty set, not
 SET1.

 Example test case:

 {{{
 >>> import django
 >>> django.__version__
 '1.11.3'
 >>> from django.contrib.auth.models import User
 >>> qs1 = User.objects.all()
 >>> qs1.count()
 100
 >>> qs2 = User.objects.filter(pk__in=[])
 >>> qs2.count()
 0
 >>> list(qs1.union(qs2))
 []
 }}}

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

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

[Django] #28377: Retain order of form media assets during aggregation

2017-07-08 Thread Django

#28377: Retain order of form media assets during aggregation
--+--
   Reporter:  Johannes Hoppe  |  Owner:  info@…
   Type:  Bug | Status:  assigned
  Component:  Forms   |Version:  1.11
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
 The order of static asset can matter, be it JavaScript code, that depends
 on jQuery or CSS files, that overwrite each other.
 Currently Django does not retain the order specified in the ``Media``
 property. When merging to Media objects, like widget and form media,
 unique entries only get amended which can change the order of assets.

 Example:


 {{{
 >>> from django.forms import Media
 >>> m1 = Media(js=('jQuery.js', 'script.js', 'noConflict.js'))
 >>> m2 = Media(js=('jQuery.js', 'yet_another_script.js', 'noConflict.js'))
 >>> print(m1 + m2)
 
 
 
 
 }}}

 Here the very important order of assets for m2 has changed.

 Using proper merging, the order can be maintained. Furthermore Django
 should warn developers, if two media classes have the same assets in a
 reversed order.

 This is how the order should be:

 {{{
 >>> from django.forms import Media
 >>> m1 = Media(js=('jQuery.js', 'script.js', 'noConflict.js'))
 >>> m2 = Media(js=('jQuery.js', 'yet_another_script.js', 'noConflict.js'))
 >>> print(m1 + m2)
 
 
 
 
 }}}

 or

 {{{
 >>> from django.forms import Media
 >>> m1 = Media(js=('jQuery.js', 'script.js', 'noConflict.js'))
 >>> m2 = Media(js=('jQuery.js', 'yet_another_script.js', 'noConflict.js'))
 >>> print(m1 + m2)
 
 
 
 
 }}}

 Both cases have no duplicates and the order of both individual form media
 assets is preserved.

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

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

Re: [Django] #28375: QuerySet.prefetch_related() crashes with KeyError if model uses to_field and string primary key (was: prefetch_related bug with string primary key.)

2017-07-08 Thread Django

#28375: QuerySet.prefetch_related() crashes with KeyError if model uses to_field
and string primary key
-+-
 Reporter:  Maks Y   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related | Triage Stage:  Accepted
  string primary key.|
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/065.3540ec9700f6aeea9828e4c0cfa1399b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28371: Cast generating invalid SQL for SQLite and PostgreSQL

2017-07-08 Thread Django

#28371: Cast generating invalid SQL for SQLite and PostgreSQL
-+-
 Reporter:  jamesdoherty |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 confirm that if you use `Cast` with `CharField()` without `max_length`
 argument then SQL is invalid. On the other hand I'm not convinced that
 it's a bug because `max_length` is required for `CharField`'s.

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

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

Re: [Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

[Django] #28379: Improve handling lack of permissions in AccessMixin

Re: [Django] #20880: Split clone() to clone() and pre_next_op()

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

Re: [Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

Re: [Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

Re: [Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

Re: [Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

Re: [Django] #28373: TIME_ZONE value in DATABASES settings is not used for date lookup

Re: [Django] #28377: Retain order of form media assets during aggregation

[Django] #28378: QuerySet.union() with queryset that raises EmptyResultSet results in an empty set

[Django] #28377: Retain order of form media assets during aggregation

Re: [Django] #28375: QuerySet.prefetch_related() crashes with KeyError if model uses to_field and string primary key (was: prefetch_related bug with string primary key.)

Re: [Django] #28371: Cast generating invalid SQL for SQLite and PostgreSQL

14 matches

Site Navigation

Mail list logo

Footer information