Re: [Django] #32716: ManifestStaticFilesStorage crashes with max_post_process_passes = 0.

[Django]

#32716: ManifestStaticFilesStorage crashes with max_post_process_passes = 0.
-+-
 Reporter:  Markus Bertheau  |Owner:
 |  aryabartar
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  staticfiles  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by aryabartar):

 * cc: aryabartar (added)
 * keywords:   => staticfiles
 * owner:  kingliar420 => aryabartar


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

Re: [Django] #32810: django.utils.formats.number_format calculates a value for use_l10n which isn't re-used for calls to get_format

[Django]

#32810: django.utils.formats.number_format calculates a value for use_l10n which
isn't re-used for calls to get_format
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  dev
 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 Mariusz Felisiak):

 * easy:  0 => 1
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1de7f4ccd6e57d0b2601dec495e91800%40djangoproject.com.

Re: [Django] #32811: Annotate removes Meta.ordering

[Django]

#32811: Annotate removes Meta.ordering
-+-
 Reporter:  pirelle  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  invalid
 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 Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => invalid
 * easy:  1 => 0


Comment:

 This is an expected behavior. `Meta.ordering` doesn't affect `GROUP BY`
 queries after 0ddb4ebf7bfcc4730c80a772dd146a49ef6895f6 (which was
 deprecated in 1b1f64ee5a78cc217fead52cbae23114502cf564).

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

Re: [Django] #32508: Raise proper exceptions instead of using "assert".

[Django]

#32508: Raise proper exceptions instead of using "assert".
--+
 Reporter:  Adam Johnson  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  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
--+

Comment (by Jacob Walls):

 Replying to [comment:22 Nishant Sagar]:
 > May I take this ticket and if yes can anyone suggests me the ways to
 proceed as I'm fairly new to this

 Thanks for your interest. Daniyal handled the bulk of what was left here
 in [https://github.com/django/django/pull/14173 PR 14173], so if you want
 to tackle the rest, be sure to skip the django.db module, which was the
 focus of that PR.

 Toward getting started, this is a great time to learn about grep, e.g.
 `grep 'assert\s' django/* -r`. Here's what's left excluding django.db and
 the test suite itself:

 {{{
 django/contrib/auth/hashers.py:assert password is not None
 django/contrib/auth/hashers.py:assert salt and '$' not in salt
 django/contrib/auth/hashers.py:assert algorithm == self.algorithm
 django/contrib/auth/hashers.py:assert algorithm == self.algorithm
 django/contrib/auth/hashers.py:assert algorithm == self.algorithm
 django/contrib/auth/hashers.py:assert algorithm == self.algorithm
 django/contrib/auth/hashers.py:assert algorithm == self.algorithm
 django/contrib/auth/hashers.py:assert password is not None
 django/contrib/auth/hashers.py:assert salt and '$' not in salt
 django/contrib/auth/hashers.py:assert algorithm == self.algorithm
 django/contrib/auth/hashers.py:assert password is not None
 django/contrib/auth/hashers.py:assert salt and '$' not in salt
 django/contrib/auth/hashers.py:assert algorithm == self.algorithm
 django/contrib/auth/hashers.py:assert salt == ''
 django/contrib/auth/hashers.py:assert encoded.startswith('sha1$$')
 django/contrib/auth/hashers.py:assert salt == ''
 django/contrib/auth/hashers.py:assert len(salt) == 2
 django/contrib/auth/hashers.py:assert hash is not None  # A
 platform like OpenBSD with a dummy crypt module.
 django/contrib/auth/hashers.py:assert algorithm == self.algorithm
 django/contrib/auth/views.py:assert 'uidb64' in kwargs and 'token'
 in kwargs
 django/contrib/staticfiles/storage.py:assert
 url_path.startswith(settings.STATIC_URL)
 django/dispatch/dispatcher.py:assert callable(receiver),
 "Signal receivers must be callable."
 django/http/multipartparser.py:assert remaining > 0,
 'remaining bytes to read should never go negative'
 django/test/client.py:assert self.__len >= num_bytes, "Cannot read
 more than the available bytes from the HTTP incoming data."
 django/test/utils.py:assert not kwargs
 django/test/utils.py:assert not args
 django/test/testcases.py:assert not self.reset_sequences,
 'reset_sequences cannot be used on TestCase instances'
 django/utils/version.py:assert len(version) == 5
 django/utils/version.py:assert version[3] in ('alpha', 'beta',
 'rc', 'final')
 django/utils/regex_helper.py:assert not flags, (
 django/views/decorators/debug.py:assert isinstance(request,
 HttpRequest), (
 }}}

 The work to finish this off is to decide which ones remaining are worth
 changing given comments above from Tim and Chris. I suspect not many. The
 last one in the list could be; it's potentially user-facing and already
 has a nice exception message, so we can just change to `TypeError`. The
 ones in contrib.auth.hashers look like sanity checks we don't need to
 touch.

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

Re: [Django] #32812: prefetch_related() crashes with values_list(named=True). (was: ORM issue with values_list named=True)

[Django]

#32812: prefetch_related() crashes with values_list(named=True).
-+-
 Reporter:  pirelle  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (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 Jacob Walls):

 * version:  3.2 => dev
 * severity:  Release blocker => Normal
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 Similar to #26264 I don't think `prefetch_related()` has any effect here,
 but we could just gracefully ignore instead of raising (again, similar to
 #26264). Barring that raise a more informative error.

 Straightforward workaround (avoid prefetching) suggests this isn't a
 release blocker.

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

Re: [Django] #29865: Add XOR for use in Q Queries

[Django]

#29865: Add XOR for use in Q Queries
-+-
 Reporter:  Griffith Rees|Owner:  Ryan
 |  Heard
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  xor  | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * owner:  nobody => Ryan Heard
 * status:  new => assigned
 * has_patch:  0 => 1


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

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

Re: [Django] #27925: Document how to deploy using pip installed mod_wsgi

[Django]

#27925: Document how to deploy using pip installed mod_wsgi
-+-
 Reporter:  Vincent Lefoulon |Owner:  Kshitij
 Type:   |  Raghav
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  mod_wsgi, apache | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * 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/063.d9d63a9f862553ab6e5ae997fd117412%40djangoproject.com.

[Django] #32812: ORM issue with values_list named=True

[Django]

#32812: ORM issue with values_list named=True
-+-
   Reporter:  pirelle|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Two same queries, but "named=True" in the end of second query throws
 exception

 {{{
 ipdb>
 Order.objects.prefetch_related("comments").annotate(orders_count=Count("pk",
 distinct=True)).values_list("delivery__delivery_method","orders_count")
 

 ipdb>
 Order.objects.prefetch_related("comments").annotate(orders_count=Count("pk",
 distinct=True)).values_list("delivery__delivery_method","orders_count",
 named=True)
 *** AttributeError: Cannot find 'comments' on Row object, 'comments' is an
 invalid parameter to prefetch_related()
 }}}

-- 
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/050.590dfd8d9037eba540e092aca1b36538%40djangoproject.com.

Re: [Django] #27590: Allow configuration of where to save staticfiles manifest.

[Django]

#27590: Allow configuration of where to save staticfiles manifest.
-+-
 Reporter:  David Sanders|Owner:  Jarosław
 |  Wygoda
 Type:  New feature  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  dev
 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 Jacob Walls):

 * needs_better_patch:  1 => 0
 * version:  1.10 => dev
 * needs_docs:  1 => 0


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

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

Re: [Django] #29865: Add XOR for use in Q Queries

[Django]

#29865: Add XOR for use in Q Queries
-+-
 Reporter:  Griffith Rees|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  xor  | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ryan Heard):

 Replying to [ticket:29865 Griffith Rees]:
 > XOR seems to be available in [https://www.postgresql.org/docs/8.4/static
 /functions-math.html Postgresql], [https://dev.mysql.com/doc/refman/8.0/en
 /logical-operators.html MySQL], [https://docs.microsoft.com/en-us/sql/mdx
 /xor-mdx?view=sql-server-2017 SequelServer] and
 [https://docs.oracle.com/cd/E17952_01/mysql-5.1-en/logical-operators.html
 Oracle] but NOT [https://stackoverflow.com/questions/2294137/sqlite-
 exclusive-or-how-do-i-clear-a-flag sqlite]. Two stackoverflow questions
 cover this sort of thing: [https://stackoverflow.com/questions/50408142
 /django-models-xor-at-the-model-level] and
 [https://stackoverflow.com/questions/14711203/perform-a-logical-exclusive-
 or-on-a-django-q-object].
 >
 > I propose adding XOR to work with Q queries like the
 [https://stackoverflow.com/a/21220712/678486 answer]  to the second
 question above. This will be my first time making a major contribution so
 we'll see how this goes (apologies in advance if this is annoying!).
 I started on this hoping to use it on my own postgres site, only to
 realize that postgres does not support logical XOR. Too bad, as it would
 help with not executing large subqueries multiple times.

 Never-the-less I have created a PR with the proposed changes for this
 [https://github.com/django/django/pull/14480 here], which probably needs
 some TLC from a more advanced contributor. This code should add support
 for XOR across the codebase, to both `Q` objects and `QuerySets`, and
 ensure it gets down the SQL fed to the database.

 Note that a TypeError is raised if XOR is attempted on an unsupported
 backend. This seemed safer than converting on the fly to (A AND ~B) OR (~A
 AND B), since doing that could lead to some unintended results when the
 user is expecting XOR to be used. If it is decided that a conversion would
 be more desirable, then the code can be changed.

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

[Django] #32811: Annotate removes Meta.ordering

[Django]

#32811: Annotate removes Meta.ordering
-+-
   Reporter:  pirelle|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 This is very simplified example

 {{{
 In [5]: str(Order.objects.values("id", "ordered_at").all().query)
 Out[5]: 'SELECT "orders_order"."id", "orders_order"."ordered_at" FROM
 "orders_order" ORDER BY "orders_order"."ordered_at" DESC'

 In [6]: str(Order.objects.values("id",
 "ordered_at").annotate(c=Count("id")).all().query)
 Out[6]: 'SELECT "orders_order"."id", "orders_order"."ordered_at",
 COUNT("orders_order"."id") AS "c" FROM "orders_order" GROUP BY
 "orders_order"."id"'
 }}}
 As you can see ORDER BY disappears when annotate with Count exists.
 It used to work on 3.0, but stopped working in 3.1 and 3.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/050.c0f80843eadf63a337cf739184a1b425%40djangoproject.com.

Re: [Django] #26591: Incorrect Manifest Keys for ManifestStaticFilesStorage on Windows

[Django]

#26591: Incorrect Manifest Keys for ManifestStaticFilesStorage on Windows
-+-
 Reporter:  David Sanders|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  staticfiles  | Triage Stage:  Accepted
  manifest   |
  manifeststaticfileststorage|
  windows|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

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


Comment:

 Fixed in 53bffe8d03f01bd3214a5404998cb965fb28cd0b. The attached test case
 became `assertPostCondition()`. The author explained in PR comments
 finding, reporting, and fixing the issue in the same 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/068.dbdfccbb82f51a01c2958d7e7a210f3f%40djangoproject.com.

Re: [Django] #27590: Allow configuration of where to save staticfiles manifest.

[Django]

#27590: Allow configuration of where to save staticfiles manifest.
-+-
 Reporter:  David Sanders|Owner:  Jarosław
 |  Wygoda
 Type:  New feature  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * type:  Cleanup/optimization => New feature


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

Re: [Django] #32783: Auoreloader crashes in a conda env.

[Django]

#32783: Auoreloader crashes in a conda env.
-+-
 Reporter:  JonathanNickelson|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  3.2
  commands)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Daniel Hahler):

 Just for reference: the crash also happened with `python -m pdb
 ./manage.py runserver`.

-- 
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/075.0800c51ec63cb83ffe5a5843eb02dc4e%40djangoproject.com.

Re: [Django] #30427: Descriptors not accessible for inherited models.

[Django]

#30427: Descriptors not accessible for inherited models.
-+-
 Reporter:  Jarek Glowacki   |Owner:  Jarek
 |  Glowacki
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  inherited| Triage Stage:  Accepted
  descriptor deferred|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * needs_better_patch:  1 => 0


Comment:

 Resetting flag to match PR discussion.

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

Re: [Django] #32205: sqlmigrate crashes after removing squashed migrations.

[Django]

#32205: sqlmigrate crashes after removing squashed migrations.
-+-
 Reporter:  老广 |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  sqlmigrate   | 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):

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


Comment:

 Thanks Stian! I missed that it's already documented, the second point is
 crucial:
  "Updating all migrations that depend on the deleted migrations to depend
 on the squashed migration instead."

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

Re: [Django] #32205: sqlmigrate crashes after removing squashed migrations.

[Django]

#32205: sqlmigrate crashes after removing squashed migrations.
-+-
 Reporter:  老广 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlmigrate   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Stian Jensen):

 What is not mentioned in the CLI output, but in the documentation is the
 following:

 > You must then transition the squashed migration to a normal migration
 by:
 >
 > * Deleting all the migration files it replaces.
 > * Updating all migrations that depend on the deleted migrations to
 depend on the squashed migration instead.
 > * Removing the replaces attribute in the Migration class of the squashed
 migration (this is how Django tells that it is a squashed migration).

 https://docs.djangoproject.com/en/3.2/topics/migrations/#squashing-
 migrations

 Did you also do that?

 Maybe it should be better explained also from the CLI.

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

Re: [Django] #32809: Filtering with Q and OR gets duplicated entries

[Django]

#32809: Filtering with Q and OR gets duplicated entries
-+-
 Reporter:  Ismael Jerez |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  queryset, Q, | Triage Stage:
  filtering, OR, annotation, |   |  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:  new => closed
 * resolution:   => needsinfo


Comment:

 Thanks for this report, unfortunately we will not be able to reproduce the
 issue or confirm that it's a regression without a queryset. It looks like
 a regression in c8b659430556dca0b2fe27cf2ea0f8290dbafecd but again it's
 hard to confirm without a queryset.

 Can you provide models and filters? Can you confirm that it's a regression
 in 3.2.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.ddd864a4049829ec0dfb6f08b8a8e855%40djangoproject.com.

[Django] #32810: django.utils.formats.number_format calculates a value for use_l10n which isn't re-used for calls to get_format

[Django]

#32810: django.utils.formats.number_format calculates a value for use_l10n which
isn't re-used for calls to get_format
+
   Reporter:  Keryn Knight  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Utilities |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 |
+
 Currently, the first thing `number_format` does is:

 {{{
 if use_l10n or (use_l10n is None and settings.USE_L10N):
 lang = get_language()
 else:
 lang = None
 }}}

 so that it can pass the `lang` (string/None) and `use_l10n` (boolean/None)
 through to the `get_format` function. The `get_format` function is used 3
 times for the one `number_format` call  (which in turn is used for every
 call to `localize` via `render_value_in_context`)

 The first thing `get_format` does, meanwhile, is much the same:
 {{{
 use_l10n = use_l10n or (use_l10n is None and settings.USE_L10N)
 if use_l10n and lang is None:
 lang = get_language()
 }}}

 As far as I can tell, a small micro-optimisation is available in
 `number_format` to pre-calculate the `use_l10n` value and if it's truthy
 avoid a few comparisons. I don't **think** it's subject to any threadlocal
 values changing in between:

 {{{
 def number_format(value, decimal_pos=None, use_l10n=None,
 force_grouping=False):
 ...
 use_l10n = use_l10n or (use_l10n is None and settings.USE_L10N)
 if use_l10n:
 lang = get_language()
 else:
 lang = None
 ...
 }}}
 At worst it'd continue re-calculating the use_l10n value within
 `get_format` because it's previously been evaluated as falsy, I think.

 (Addendum: Having briefly glanced at it, I don't think this affects/steps
 on the toes of #25762 which sounds like a much bigger/better win)

-- 
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/052.4da04648e4e7d77005fcad19f49dcf93%40djangoproject.com.

Re: [Django] #32808: DiscoverRunner.build_suite() does not restore self.test_loader.testNamePatterns

[Django]

#32808: DiscoverRunner.build_suite() does not restore
self.test_loader.testNamePatterns
-+-
 Reporter:  Chris Jerdonek   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  3.2
 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 Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14478 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/067.da5c4cef419c3e2b2a78e23c30cf298a%40djangoproject.com.

Re: [Django] #32808: DiscoverRunner.build_suite() does not restore self.test_loader.testNamePatterns

[Django]

#32808: DiscoverRunner.build_suite() does not restore
self.test_loader.testNamePatterns
-+-
 Reporter:  Chris Jerdonek   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  3.2
 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):

 * owner:  nobody => Mariusz Felisiak
 * status:  new => assigned


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

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

Re: [Django] #32809: Filtering with Q and OR gets duplicated entries

[Django]

#32809: Filtering with Q and OR gets duplicated entries
-+-
 Reporter:  Ismael Jerez |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset, Q, | Triage Stage:
  filtering, OR, annotation, |   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ismael Jerez):

 * Attachment "ss2.png" 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.6d6fd8bea23311182344e328a48fcac6%40djangoproject.com.

Re: [Django] #32809: Filtering with Q and OR gets duplicated entries

[Django]

#32809: Filtering with Q and OR gets duplicated entries
-+-
 Reporter:  Ismael Jerez |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset, Q, | Triage Stage:
  filtering, OR, annotation, |   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ismael Jerez):

 * Attachment "ss1.png" 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.48bb301fae27692a501617bbdbd04ac0%40djangoproject.com.

[Django] #32809: Filtering with Q and OR gets duplicated entries

[Django]

#32809: Filtering with Q and OR gets duplicated entries
-+-
   Reporter:  Ismael |  Owner:  nobody
  Jerez  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|   Keywords:  queryset, Q,
   Severity:  Normal |  filtering, OR, annotation, |
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi:

 Django version: 3.2.4
 Python version: 3.8

 I cannot reproduce this bug in a simple example, so I can only show you
 screenshots from my Pycharm Debug Tool, I am sorry.

 I have one queryset with 3 objects which contains annotations, CharField
 and ManyToManyField attributes. Then I filter by a query using Q like
 this:
 {{{
 (OR: ('created_date_dt_custom__icontains', 'a'), ('id__icontains', 'a'),
 ('title__unaccent__icontains', 'a'), ('created_date_dt_custom__icontains',
 'a'), ('id__icontains', 'a'), ('title__unaccent__icontains', 'a'),
 ('promoters__in', , ]>))
 }}}
 And gets a queryset with 4 objects as a result, one of the objects is
 duplicated. If I delete the last filter ('promoters__in', , ]>) it works fine, so the problem is on
 this filter or maybe the concatenation of filters with this kind.

 I have no problem on Django version ~= 2.

 Here are the screenshots of my debug tool showing the problem:
 - Screenshot of the code: https://i.ibb.co/Fnb53rn/ss1.png
 - Screenshot of debug tool with variable values (Project object (19)
 duplicated): https://i.ibb.co/b34FwSM/ss2.png

 Thank you in advance, hope it is fixed soon,
 Ismael.

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

Re: [Django] #32641: Log the number of tests found in DiscoverRunner.build_suite()

[Django]

#32641: Log the number of tests found in DiscoverRunner.build_suite()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Girish
 Type:   |  Sontakke
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  DiscoverRunner,build_suite |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"1b4d1675b230cd6d47c2ffce41893d1881bf447b" 1b4d1675]:
 {{{
 #!CommitTicketReference repository=""
 revision="1b4d1675b230cd6d47c2ffce41893d1881bf447b"
 Refs #32641 -- Made DiscoverRunner's "Found X tests" message work for
 finding one test.

 This also removes passing level to log() as logging.INFO is the default.
 }}}

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

Re: [Django] #28154: Infinite loop in collectstatic with broken symlinks

[Django]

#28154: Infinite loop in collectstatic with broken symlinks
-+-
 Reporter:  Matthew Somerville   |Owner:  Jacob
 |  Walls
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  dev
  uploads/storage|
 Severity:  Normal   |   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:"ec2727efef605437eb572d51ca9afbb3a60eda40" ec2727ef]:
 {{{
 #!CommitTicketReference repository=""
 revision="ec2727efef605437eb572d51ca9afbb3a60eda40"
 Fixed #28154 -- Prevented infinite loop in FileSystemStorage.save() when a
 broken symlink with the same name exists.
 }}}

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

Re: [Django] #32642: RuntimeError: 'apps.core.apps' declares more than one default AppConfig on custom admin setup

[Django]

#32642: RuntimeError: 'apps.core.apps' declares more than one default AppConfig 
on
custom admin setup
---+--
 Reporter:  Ron|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:  invalid
 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 Mariusz Felisiak):

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


Comment:

 The current docs works for me.

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

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

Re: [Django] #32642: RuntimeError: 'apps.core.apps' declares more than one default AppConfig on custom admin setup

[Django]

#32642: RuntimeError: 'apps.core.apps' declares more than one default AppConfig 
on
custom admin setup
---+--
 Reporter:  Ron|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  3.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
---+--
Changes (by Julien Chiron):

 * cc: Julien Chiron (added)
 * status:  closed => new
 * resolution:  invalid =>


Comment:

 Having encountered the same kind of issue while implemeting site-wide
 custom AdminSite, I found a workaround to make it work.
 It seems the documentation should be updated accordingly.

 {{{
 from django.contrib.admin.apps import AdminConfig

 class MyAdminConfig(AdminConfig):
 default_site = 'myproject.admin.MyAdminSite'
 }}}

 This raises an exception:

 {{{RuntimeError: 'myproject.apps' declares more than one default
 AppConfig: 'AdminConfig', 'MyAdminConfig'.}}}

 It is solved by importing django.contrib.admin.apps instead of
 django.contrib.admin.apps.AdminConfig:

 {{{
 from django.contrib.admin import apps

 class MyAdminConfig(apps.AdminConfig):
 default_site = 'myproject.admin.MyAdminSite'
 }}}

 Then the exception moves on:

 {{{django.core.exceptions.ImproperlyConfigured: Application labels aren't
 unique, duplicates: admin}}}

 This is caused by the settings.py configuration:

 {{{
 INSTALLED_APPS = [
 'myproject.apps.MyAdminConfig',  #replaces django.contrib.admin
...
 }}}

 It is solved by removing the 'MyAdminConfig' from the settings:

 {{{
 INSTALLED_APPS = [
 'myproject.apps', #replaces django.contrib.admin
...
 }}}

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

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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 Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

 Here is a first PR: https://github.com/django/django/pull/14477

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

Re: [Django] #32641: Log the number of tests found in DiscoverRunner.build_suite()

[Django]

#32641: Log the number of tests found in DiscoverRunner.build_suite()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Girish
 Type:   |  Sontakke
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  DiscoverRunner,build_suite |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 > I would use "Found 1 test(s)."

 I made a PR for this: https://github.com/django/django/pull/14476

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

Re: [Django] #32577: Add support for `UUIDAutoField` `DEFAULT_AUTO_FIELD`

[Django]

#32577: Add support for `UUIDAutoField` `DEFAULT_AUTO_FIELD`
-+-
 Reporter:  Tomasz Wójcik|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (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
-+-

Comment (by Samuel Bishop):

 Replying to [comment:10 Mariusz Felisiak]:
 > Note: Fixing this ticket will also resolve #17337.

 This would be an interesting development, and it will be great to make
 some progress on the nonrel front.

 

 Replying to [comment:11 Nick Pope]:
 > - It was named `DEFAULT_AUTO_FIELD` to indicate that it referred to the
 ''automatically generated'' `id` field.
 >   - This was instead of `DEFAULT_AUTOFIELD` which would imply that it
 could only ever be related to `AutoField`.
 >   - Another suggestion had been `DEFAULT_MODEL_PK`, but we weren't ready
 to allow other fields without `AutoField`-like semantics.
 > - We could lift the restriction to allow other non-`AutoField` types,
 but the concept of an ''automatically generated'' `id` field needs to be
 decoupled from `AutoField` a bit.
 While the situation currently doesn't support it, having a
 `DEFAULT_MODEL_PK` which accepts any field which sets `primary_key=True`
 and `unique=True` would be very very useful as there are lots of use
 cases, such as legacy and interoperability scenarios, where having the
 primary key generation logic in python is going to be necessary, and its
 good to hear that the situation is "were not ready" not "we don't want to
 do this".

 > - Add a `db_generated`/`is_auto` (or another better name) flag to
 `AutoFieldMixin`. (See
 [https://code.djangoproject.com/ticket/24042#comment:5 my comment]. I'm
 not convinced #24042 should have been closed.)
 Reading through that, I agree, it feels like closing the ticket was based
 on the smallest possible interpretation of the issue.

 > Note that this field would also be limited to databases that have a
 function to generate a UUID.
 This is another one of reasons why I think `DEFAULT_MODEL_PK` (and thus
 lifting the need to have the database generate the primary key value),
 should be the ultimate goal, as someone maintaining a ULID Field library
 for use as a primary key, even if I go the extra mile and write/maintain
 multiple independent database functions/stored procedures (and all the
 extra management code to ensure they are loaded, updated, etc) for each
 supported database (currently Sqlite, MySQL, MariaDB, PostgreSQL,
 CockroachDB, with MSSQL on the horizon), I would "still" like to support
 generating the ULID value in python code for the broadest possible
 compatibility.

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

Re: [Django] #28154: Infinite loop in collectstatic with broken symlinks

[Django]

#28154: Infinite loop in collectstatic with broken symlinks
-+-
 Reporter:  Matthew Somerville   |Owner:  Jacob
 |  Walls
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  dev
  uploads/storage|
 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 Mariusz Felisiak):

 * 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/064.09ab18295f71fa8c2179bb99aef1586c%40djangoproject.com.

Re: [Django] #32485: Django ORM icontains Operator Performance and Response Problem

[Django]

#32485: Django ORM icontains Operator Performance and Response Problem
-+-
 Reporter:  Mesut Öncel  |Owner:  Mesut
 |  Öncel
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Django ORM,  | Triage Stage:
  icontains, ilike, performance  |  Unreviewed
  tuning |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 [https://groups.google.com/g/django-developers/c/buSJ6A07rxE/m/coQpjG-
 cAAAJ Discussion on the django-developers mailing list]

-- 
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/066.f773972611f8424e26f6982ca45d815b%40djangoproject.com.

Re: [Django] #32803: Not obvious interaction between Postgresql trgm index and icontains lookup

[Django]

#32803: Not obvious interaction between Postgresql trgm index and icontains 
lookup
-+-
 Reporter:  Dmitri Emelianov |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  postgresql   | Triage Stage:
  icontains lookup search|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  (none) => nobody
 * resolution:   => duplicate
 * status:  new => closed
 * component:  contrib.postgres => Database layer (models, ORM)
 * type:  Uncategorized => New feature


Comment:

 Closing as duplicate of #32485 and #20775.

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