Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  Jacob|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Peter Thomassen):

 * cc: Peter Thomassen (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.2317a3920e2cedf1f38e93427c68fb7c%40djangoproject.com.

Re: [Django] #25582: Add a way to build URLs with query strings

[Django]

#25582: Add a way to build URLs with query strings
+---
 Reporter:  Thomas Güttler  |Owner:  Daniel Rios
 Type:  New feature |   Status:  assigned
Component:  Core (URLs) |  Version:  dev
 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 Carsten Fuchs):

 * cc: Carsten Fuchs (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.870622f8175918736458c6e81c84e9b8%40djangoproject.com.

Re: [Django] #10941: Add a templatetag to generate querystrings

[Django]

#10941: Add a templatetag to generate querystrings
-+
 Reporter:  Ben Spaulding|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  pagination   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Carsten Fuchs):

 * cc: Carsten Fuchs (added)


Comment:

 I too had reinvented this wheel a couple of years ago, unaware of this
 ticket. Other implementations above are more powerful, but this one is
 short:
 {{{
 #!python
 @register.simple_tag
 def query_string(*args, **kwargs):
 """
 Combines dictionaries of query parameters and individual query
 parameters
 and builds an encoded URL query string from the result.
 """
 query_dict = QueryDict(mutable=True)

 for a in args:
 query_dict.update(a)

 remove_keys = []

 for k, v in kwargs.items():
 if v is None:
 remove_keys.append(k)
 elif isinstance(v, list):
 query_dict.setlist(k, v)
 else:
 query_dict[k] = v

 for k in remove_keys:
 if k in query_dict:
 del query_dict[k]

 qs = query_dict.urlencode()
 if not qs:
 return ""
 return "?" + qs
 }}}

 It cannot do everything, but covers all my use cases: Keep most of the
 existing source parameters, but delete, add or change some. Examples:
 {{{
 {# Just repeat the parameters: #}
 {% query_string request.GET %}

 {# Add a parameter: #}
 {% query_string request.GET format='pdf' %}

 {# Change a parameter: #}
 {% query_string request.GET page=next_page_number %}

 {# Overwrite month and year with precomputed values, e.g. with
 next_month_year = {'month': 1, 'year': 2022}, and clear the day: #}
 {% query_string request.GET next_month_year day=None %}
 }}}

 I'm aware that posting yet another implementation does not achieve true
 progress and that the more elaborate implementations above may be more
 appropriate for inclusion in Django.
 Still, I wanted to mention this because in my opinion it keeps the balance
 between features and simplicity.

-- 
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.d2273be992549f011746ef202b3d403f%40djangoproject.com.

Re: [Django] #33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature mismatch.

[Django]

#33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature 
mismatch.
-+-
 Reporter:  Nick Pope|Owner:  Alexander
 |  Filimonov
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  gismodeladmin,   | Triage Stage:
  gis_widget_kwargs  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Please don't reopen closed ticket. The fix is backward compatible and it
 introduces unnecessary limitation.

-- 
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.2babf8850be25549cdb9536e581f26c7%40djangoproject.com.

Re: [Django] #33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature mismatch.

[Django]

#33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature 
mismatch.
-+-
 Reporter:  Nick Pope|Owner:  Alexander
 |  Filimonov
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  gismodeladmin,   | Triage Stage:
  gis_widget_kwargs  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Alexander Filimonov):

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


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

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

Re: [Django] #33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature mismatch.

[Django]

#33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature 
mismatch.
-+-
 Reporter:  Nick Pope|Owner:  Alexander
 |  Filimonov
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  gismodeladmin,   | Triage Stage:
  gis_widget_kwargs  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 > I'd support Nick here and say that it is not a good way to use a
 dictionary to fill a single attribute.

 As far as I'm aware Nick agreed that the current implementation makes
 sense. Of course, it's worth adding test coverage and a short example in
 docs.

-- 
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.780221424dcb7a0409436cf5ccfeafa6%40djangoproject.com.

Re: [Django] #33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature mismatch.

[Django]

#33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature 
mismatch.
-+-
 Reporter:  Nick Pope|Owner:  Alexander
 |  Filimonov
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  gismodeladmin,   | Triage Stage:
  gis_widget_kwargs  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Alexander Filimonov):

 Replying to [comment:4 Nick Pope]:
 > Replying to [comment:3 Mariusz Felisiak]:
 > > I wouldn't say it's broken, you can set `gis_widget_kwargs = {'attrs':
 {...}}`. Defining widgets with more than `attrs` or a different signature
 is reasonable (e.g. `SplitDateTimeWidget` or `ChoiceWidget`). IMO we
 should leave wide support for all options.
 >
 > I see. That makes sense, but I can also see that it is confusing.
 > Perhaps the documentation can be updated with an example? (If only to
 avoid reports of this in the future.)
 > In addition, this is not tested - it should be to ensure that
 `gis_widget_kwargs` continues to work as expected.

 I'd support Nick here and say that it is not a good way to use a
 dictionary to fill a single attribute.
 I have a fix for this with a test to check if arguments are passed
 correctly
 https://github.com/django/django/pull/15211
 Please review the pull request

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

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

Re: [Django] #33376: django.contrib.auth.urls don't function when enclosed within an application namespace.

[Django]

#33376: django.contrib.auth.urls don't function when enclosed within an 
application
namespace.
-+-
 Reporter:  Yash Pathak  |Owner:  Yash
 Type:   |  Pathak
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  success_url  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Please don't reopen closed ticket. This is a duplicate, you can add a
 comment to the original ticket, however creating a new setting is always
 controversial. You can raise the idea on the DevelopersMailingList to
 reach a wider audience and see what other think, but I don't think there
 would be consensus to add that complexity.

-- 
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.ad1b712409e03ad595e657439bebe653%40djangoproject.com.

Re: [Django] #33376: django.contrib.auth.urls don't function when enclosed within an application namespace.

[Django]

#33376: django.contrib.auth.urls don't function when enclosed within an 
application
namespace.
-+-
 Reporter:  Yash Pathak  |Owner:  Yash
 Type:   |  Pathak
  Cleanup/optimization   |   Status:  new
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  success_url  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Yash Pathak):

 * cc: Yash Pathak (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.228d567681a9985de02700039672384e%40djangoproject.com.

Re: [Django] #33376: django.contrib.auth.urls don't function when enclosed within an application namespace.

[Django]

#33376: django.contrib.auth.urls don't function when enclosed within an 
application
namespace.
-+-
 Reporter:  Yash Pathak  |Owner:  Yash
 Type:   |  Pathak
  Cleanup/optimization   |   Status:  new
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  success_url  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Yash Pathak):

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


-- 
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.935e35c40ea47fe2f7132c893c9f12a8%40djangoproject.com.

Re: [Django] #33376: django.contrib.auth.urls don't function when enclosed within an application namespace.

[Django]

#33376: django.contrib.auth.urls don't function when enclosed within an 
application
namespace.
-+-
 Reporter:  Yash Pathak  |Owner:  Yash
 Type:   |  Pathak
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  success_url  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Yash Pathak):

 * has_patch:  0 => 1
 * type:  New feature => Cleanup/optimization


-- 
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.a262cef02a896e14fccbd35308fadca3%40djangoproject.com.

Re: [Django] #33376: django.contrib.auth.urls don't function when enclosed within an application namespace.

[Django]

#33376: django.contrib.auth.urls don't function when enclosed within an 
application
namespace.
--+---
 Reporter:  Yash Pathak   |Owner:  Yash Pathak
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  4.0
 Severity:  Normal|   Resolution:  duplicate
 Keywords:  success_url   | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+---
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * type:  Cleanup/optimization => New feature
 * resolution:   => duplicate


Comment:

 Duplicate of #32349.

-- 
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.8b4b5fcfc852899dacf9bd55bc3b3cc7%40djangoproject.com.

Re: [Django] #33373: Support expressions on rhs for __has_keys, __has_any_keys JSONField lookups.

[Django]

#33373: Support expressions on rhs for __has_keys, __has_any_keys JSONField
lookups.
-+-
 Reporter:  john-parton  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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
-+-

Comment (by john-parton):

 Thanks for the feedback.

 Examples in documentation aren't necessarily meant to be exhaustive.
 Obviously it's impractical to give an example for every way a feature can
 be use.

 I do think it's a violation of expectations.

 At the very least, I think it would be helpful to update the documentation
 so that it notes that only iterables of strings are valid values for that
 transformation.

 It sounds like the ?& operator only works on Postgres, and not Oracle or
 other database backends. Is that right?

 Are we amenable to making it work with the Postgres backend, and
 continuing to produce the current error for the other backends?

-- 
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/069.337ef47a19b1d013db127ef901ec0f6c%40djangoproject.com.

[Django] #33376: django.contrib.auth.urls don't function when enclosed within an application namespace.

[Django]

#33376: django.contrib.auth.urls don't function when enclosed within an 
application
namespace.
-+-
   Reporter: |  Owner:  Yash Pathak
  FuriousBluffer |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component: |Version:  4.0
  contrib.auth   |
   Severity:  Normal |   Keywords:  success_url
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 If you define the application namespace in a urls.py file of an app and
 include the auth URLs provided by Django, they return errors associating
 to Exception Type: NoReverseMatch.

 {{{
 from django.urls import path, include
 from .apps import UsersConfig

 app_name = UsersConfig.name

 urlpatterns = [
 path('accounts/', include("django.contrib.auth.urls")),
 ]
 }}}

 The success_url fails to redirect to the correct url since they are more
 or less defined in a static manner.

 By making a few changes in the auth/views.py file, this issue can be
 fixed. One additional change, that needs to be done by the developer, is
 to define the app name in the settings.py file separately(Just like
 LOGIN_REDIRECT_URL). For Example:

 {{{
 LOGIN_REDIRECT_URL = 'onboarding'

 LOGOUT_REDIRECT_URL = "onboarding"

 AUTH_APPLICATION_NAMESPACE = 'users'
 }}}
 'users' is the name of my app as defined in the former code snippet.

-- 
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/057.1773d35f758861d3abadc7cadaf433c8%40djangoproject.com.

Re: [Django] #33375: Admin changelist_formset does not use the Admin queryset

[Django]

#33375: Admin changelist_formset does not use the Admin queryset
--+--
 Reporter:  François Freitag  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  dev
 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 François Freitag):

 * cc: François Freitag (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.b17b43dc1530b1529433e21728182183%40djangoproject.com.

Re: [Django] #33375: Admin changelist_formset does not use the Admin queryset

[Django]

#33375: Admin changelist_formset does not use the Admin queryset
--+--
 Reporter:  François Freitag  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  dev
 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 François Freitag):

 * Attachment "failing-test.patch" added.

 A failing test to reproduce the issue. The response status can be
 commented out to verify the objects in the DB are actually not updated.

-- 
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/073.70b588ea98e0578384bb6df2c0549e80%40djangoproject.com.

[Django] #33375: Admin changelist_formset does not use the Admin queryset

[Django]

#33375: Admin changelist_formset does not use the Admin queryset
+
   Reporter:  François Freitag  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.admin |Version:  dev
   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 |
+
 I’m implementing soft-deletion for `models.Model`s with a `BooleanField`
 named `deleted`. For the entire system (except Django admin), an object
 `deleted=True` no longer exist. That is implemented by setting the default
 manager to an `objects` manager that ignores `deleted=True` rows.
 For the admin, I’m overriding the queryset to include `deleted=True`.

 When using `list_editable = ["deleted"]`, the soft-deleted objects cannot
 be re-activated. The reason is that the `id` field in the
 `changelist_formset` uses the `_default_manager` (`objects`).
 I do not want to make `include_deleted` the default manager, as any model
 field in the system would use that instead of the `objects`, unless
 overridden.

 IMO, the admin should be using the result of `get_queryset()` for the
 changelist_formset `id` field Queryset.
 Happy to attempt patching if the ticket is 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/058.00ea2e31f4fc1773b9c45134eb77731a%40djangoproject.com.

Re: [Django] #33355: Optimize SQLite backend connection functions

[Django]

#33355: Optimize SQLite backend connection functions
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   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 Nick Pope):

 * stage:  Accepted => Ready for checkin


Comment:

 Thanks Adam. I think this is ready.

-- 
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/068.6f526fb8f6daabbff106de45ed47386d%40djangoproject.com.

Re: [Django] #33374: ExpressionWrapper for ~Q(pk__in=[]) crashes. (was: ExpressionWrapper for ~Q(pk__in=[]) broken)

[Django]

#33374: ExpressionWrapper for ~Q(pk__in=[]) crashes.
-+-
 Reporter:  Stefan Brand |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * component:  Uncategorized => Database layer (models, ORM)
 * stage:  Unreviewed => Accepted


Comment:

 Good catch!

 {{{#!python
 >>> books =
 Book.objects.annotate(selected=ExpressionWrapper(~Q(pk__in=[]),
 output_field=BooleanField())).values('selected')
 >>> list(books)
 Traceback (most recent call last):
   File "/django/django/db/backends/utils.py", line 85, in _execute
 return self.cursor.execute(sql, params)
   File "/django/django/db/backends/sqlite3/base.py", line 420, in execute
 return Database.Cursor.execute(self, query, params)
 sqlite3.OperationalError: near "AS": syntax error
 }}}

-- 
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/069.e93ee1d642e966b50e322929f087dee5%40djangoproject.com.

Re: [Django] #33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature mismatch.

[Django]

#33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature 
mismatch.
-+-
 Reporter:  Nick Pope|Owner:  Alexander
 |  Filimonov
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  gismodeladmin,   | Triage Stage:
  gis_widget_kwargs  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:4 Nick Pope]:
 > Perhaps the documentation can be updated with an example? (If only to
 avoid reports of this in the future.)

 Sounds reasonable. Maybe a short example with changing `default_lon` and
 `default_lat`.

 > In addition, this is not tested - it should be to ensure that
 `gis_widget_kwargs` continues to work as expected.

 Extra tests coverage is always warm welcome.

-- 
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.d4fefa2928c482e61c240d760d18a15b%40djangoproject.com.

Re: [Django] #33374: ExpressionWrapper for ~Q(pk__in=[]) broken

[Django]

#33374: ExpressionWrapper for ~Q(pk__in=[]) broken
---+--
 Reporter:  Stefan Brand   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  3.1
 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 Stefan Brand:

Old description:

> == Problem Description
>
> I'm reducing some Q objects (similar to what is described in
> ticket:32554. Everything is fine for the case where the result is
> `ExpressionWrapper(Q(pk__in=[]))`. However, when I reduce to
> `ExpressionWrapper(~Q(pk__in=[]))` the query breaks.
>
> == Symptoms
>
> === Working for `ExpressionWrapper(Q(pk__in=[]))`
> {{{#!python
> print(queryset.annotate(foo=ExpressionWrapper(Q(pk__in=[]),
> output_field=BooleanField())).values("foo").query)
> }}}
>
> {{{#!sql
> SELECT 0 AS "foo" FROM "agri_data_declaration"
> }}}
>
> === Not working for `ExpressionWrapper(~Q(pk__in=[]))`
>
> {{{#!python
> print(queryset.annotate(foo=ExpressionWrapper(~Q(pk__in=[]),
> output_field=BooleanField())).values("foo").query)
> }}}
> {{{#!sql
> SELECT  AS "foo" FROM "agri_data_declaration"
> }}}

New description:

 == Problem Description

 I'm reducing some Q objects (similar to what is described in ticket:32554.
 Everything is fine for the case where the result is
 `ExpressionWrapper(Q(pk__in=[]))`. However, when I reduce to
 `ExpressionWrapper(~Q(pk__in=[]))` the query breaks.

 == Symptoms

 === Working for `ExpressionWrapper(Q(pk__in=[]))`
 {{{#!python
 print(queryset.annotate(foo=ExpressionWrapper(Q(pk__in=[]),
 output_field=BooleanField())).values("foo").query)
 }}}

 {{{#!sql
 SELECT 0 AS "foo" FROM "table"
 }}}

 === Not working for `ExpressionWrapper(~Q(pk__in=[]))`

 {{{#!python
 print(queryset.annotate(foo=ExpressionWrapper(~Q(pk__in=[]),
 output_field=BooleanField())).values("foo").query)
 }}}
 {{{#!sql
 SELECT  AS "foo" FROM "table"
 }}}

--

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

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

Re: [Django] #33374: ExpressionWrapper for ~Q(pk__in=[]) broken

[Django]

#33374: ExpressionWrapper for ~Q(pk__in=[]) broken
---+--
 Reporter:  StefanBrand|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  3.1
 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 StefanBrand:

Old description:

> == Problem Description
>
> I'm reducing some Q objects (similar to what is described in
> ticket:32554. Everything is fine for the case where the result is
> `ExpressionWrapper(Q(pk__in=[]))`. However, when I reduce to
> `ExpressionWrapper(~Q(pk__in=[]))` the query breaks.
>
> == Symptoms
>
> === Working for `ExpressionWrapper(Q(pk__in=[]))`
> {{{#!python
> print(queryset.annotate(foo=ExpressionWrapper(Q(pk__in=[]),
> output_field=BooleanField())).values("foo").query)
> }}}
>
> {{{#!sql
> SELECT 0 AS "foo" FROM "agri_data_declaration"
> }}}
>
> === Not working for `ExpressionWrapper(~Q(pk__in=[]))`
>
> {{{#!python
> print(declarations.annotate(foo=ExpressionWrapper(~Q(pk__in=[]),
> output_field=BooleanField())).values("foo").query)
> }}}
> {{{#!sql
> SELECT  AS "foo" FROM "agri_data_declaration"
> }}}

New description:

 == Problem Description

 I'm reducing some Q objects (similar to what is described in ticket:32554.
 Everything is fine for the case where the result is
 `ExpressionWrapper(Q(pk__in=[]))`. However, when I reduce to
 `ExpressionWrapper(~Q(pk__in=[]))` the query breaks.

 == Symptoms

 === Working for `ExpressionWrapper(Q(pk__in=[]))`
 {{{#!python
 print(queryset.annotate(foo=ExpressionWrapper(Q(pk__in=[]),
 output_field=BooleanField())).values("foo").query)
 }}}

 {{{#!sql
 SELECT 0 AS "foo" FROM "agri_data_declaration"
 }}}

 === Not working for `ExpressionWrapper(~Q(pk__in=[]))`

 {{{#!python
 print(queryset.annotate(foo=ExpressionWrapper(~Q(pk__in=[]),
 output_field=BooleanField())).values("foo").query)
 }}}
 {{{#!sql
 SELECT  AS "foo" FROM "agri_data_declaration"
 }}}

--

-- 
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/069.5f2ff48c7128235d8845f7278d8145d9%40djangoproject.com.

[Django] #33374: ExpressionWrapper for ~Q(pk__in=[]) broken

[Django]

#33374: ExpressionWrapper for ~Q(pk__in=[]) broken
-+
   Reporter:  StefanBrand|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  3.1
   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  |
-+
 == Problem Description

 I'm reducing some Q objects (similar to what is described in ticket:32554.
 Everything is fine for the case where the result is
 `ExpressionWrapper(Q(pk__in=[]))`. However, when I reduce to
 `ExpressionWrapper(~Q(pk__in=[]))` the query breaks.

 == Symptoms

 === Working for `ExpressionWrapper(Q(pk__in=[]))`
 {{{#!python
 print(queryset.annotate(foo=ExpressionWrapper(Q(pk__in=[]),
 output_field=BooleanField())).values("foo").query)
 }}}

 {{{#!sql
 SELECT 0 AS "foo" FROM "agri_data_declaration"
 }}}

 === Not working for `ExpressionWrapper(~Q(pk__in=[]))`

 {{{#!python
 print(declarations.annotate(foo=ExpressionWrapper(~Q(pk__in=[]),
 output_field=BooleanField())).values("foo").query)
 }}}
 {{{#!sql
 SELECT  AS "foo" FROM "agri_data_declaration"
 }}}

-- 
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/054.916f9560eb2d4bff78031d1cf42dff5a%40djangoproject.com.

Re: [Django] #33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature mismatch.

[Django]

#33372: GISModelAdmin.gis_widget_kwargs cannot be used due to signature 
mismatch.
-+-
 Reporter:  Nick Pope|Owner:  Alexander
 |  Filimonov
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  gismodeladmin,   | Triage Stage:
  gis_widget_kwargs  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Nick Pope):

 Replying to [comment:3 Mariusz Felisiak]:
 > I wouldn't say it's broken, you can set `gis_widget_kwargs = {'attrs':
 {...}}`. Defining widgets with more than `attrs` or a different signature
 is reasonable (e.g. `SplitDateTimeWidget` or `ChoiceWidget`). IMO we
 should leave wide support for all options.

 I see. That makes sense, but I can also see that it is confusing.
 Perhaps the documentation can be updated with an example? (If only to
 avoid reports of this in the future.)
 In addition, this is not tested - it should be to ensure that
 `gis_widget_kwargs` continues to work as expected.

-- 
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.ca69dbbab64a386662dd9bca92599b72%40djangoproject.com.

Re: [Django] #33366: Migration autodetector doesn't handle placeholders in related_name for ForeignKey.

[Django]

#33366: Migration autodetector doesn't handle placeholders in related_name for
ForeignKey.
-+-
 Reporter:  Andrew Chen Wang |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"7e6a2e3b4555c069c50cb949404938345bfb2ea6" 7e6a2e3b]:
 {{{
 #!CommitTicketReference repository=""
 revision="7e6a2e3b4555c069c50cb949404938345bfb2ea6"
 [4.0.x] Fixed #33366 -- Fixed case handling with swappable setting
 detection in migrations autodetector.

 The migration framework uniquely identifies models by case insensitive
 labels composed of their app label and model names and so does the app
 registry in most of its methods (e.g. AppConfig.get_model) but it
 wasn't the case for get_swappable_settings_name() until this change.

 This likely slipped under the radar for so long and only regressed in
 b9df2b74b98b4d63933e8061d3cfc1f6f39eb747 because prior to the changes
 related to the usage of model states instead of rendered models in the
 auto-detector the exact value settings value was never going through a
 case folding hoop.

 Thanks Andrew Chen Wang for the report and Keryn Knight for the
 investigation.

 Backport of 43289707809c814a70f0db38ca4f82f35f43dbfd from main
 }}}

-- 
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/074.329ad9abc9919b9a16afa3db0a0460e2%40djangoproject.com.

Re: [Django] #33366: Migration autodetector doesn't handle placeholders in related_name for ForeignKey.

[Django]

#33366: Migration autodetector doesn't handle placeholders in related_name for
ForeignKey.
-+-
 Reporter:  Andrew Chen Wang |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (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:"43289707809c814a70f0db38ca4f82f35f43dbfd" 4328970]:
 {{{
 #!CommitTicketReference repository=""
 revision="43289707809c814a70f0db38ca4f82f35f43dbfd"
 Fixed #33366 -- Fixed case handling with swappable setting detection in
 migrations autodetector.

 The migration framework uniquely identifies models by case insensitive
 labels composed of their app label and model names and so does the app
 registry in most of its methods (e.g. AppConfig.get_model) but it
 wasn't the case for get_swappable_settings_name() until this change.

 This likely slipped under the radar for so long and only regressed in
 b9df2b74b98b4d63933e8061d3cfc1f6f39eb747 because prior to the changes
 related to the usage of model states instead of rendered models in the
 auto-detector the exact value settings value was never going through a
 case folding hoop.

 Thanks Andrew Chen Wang for the report and Keryn Knight for the
 investigation.
 }}}

-- 
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/074.2ff39b472b502d277f8ae384e5d4bd6f%40djangoproject.com.