Re: [Django] #28862: Removing a field from index_together/unique_together and from the model generates a migration that crashes

[Django]

#28862: Removing a field from index_together/unique_together and from the model
generates a migration that crashes
---+
 Reporter:  Artem Maslovskiy   |Owner:  Jeff
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  models migrations  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Simon Charette):

 I had a look at the issue and I came to the conclusion that the only
 solution for now is to disable `AlterFooTogether` optimization when a
 `RemoveField` on the same model is involved.

 As mentioned by Ramiro we'd need to have access to the ''previous''
 `foo_together` value to determine whether or not the optimization can take
 place. This is a class of problem that also came up when working on #27768
 where I had to disable an optimization from taking place because I didn't
 have the ''previous'' context of a `RemoveField`.

 I guess I'd be possible to have newly generated operation embed a such a
 ''previous'' state to allow the optimization to take place but I figured
 out what I believe is a clever way of working around this disabled
 optimization. By implementing `CreateModel`/`AlterFooOperation` reduction
 most of the negative side effect during migration squashing where the
 optimizer perform a complete reduction are gone because the former is able
 to reduce `RemoveField` operation.

 All of these ideas are implemented in this
 [https://github.com/django/django/pull/10178 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/063.05c44dd9062f806f93f1cb5cdd2a3903%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29528: Make URLValidator reject invalid characters in the username and password (was: Invalid URLs passing validation by URLValidator)

[Django]

#29528: Make URLValidator reject invalid characters in the username and password
--+
 Reporter:  Tim Bell  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

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

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

Re: [Django] #11927: Allow manage.py dumpdata to dump YAML in block style

[Django]

#11927: Allow manage.py dumpdata to dump YAML in block style
-+-
 Reporter:  sampablokuper|Owner:  Matthijs
 |  Kooijman
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.5f9aaf59628c37e1872288c9ff633c56%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29542: Annotated field created by subquery, referenced inside of F() generates invalid SQL

[Django]

#29542: Annotated field created by subquery, referenced inside of F() generates
invalid SQL
-+-
 Reporter:  Joey Wilhelm |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 Tim Graham):

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

Re: [Django] #26291: loaddata cannot deserialize fixtures with forward references and natural foreign keys

[Django]

#26291: loaddata cannot deserialize fixtures with forward references and natural
foreign keys
-+-
 Reporter:  Peter Inglesby   |Owner:  Peter
 |  Inglesby
 Type:  New feature  |   Status:  closed
Component:  Core |  Version:  1.9
  (Serialization)|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"312eb5cb11d09c0c41b2740e2e9aef838d60c8b5" 312eb5cb]:
 {{{
 #!CommitTicketReference repository=""
 revision="312eb5cb11d09c0c41b2740e2e9aef838d60c8b5"
 Fixed #26291 -- Allowed loaddata to handle forward references in
 natural_key fixtures.
 }}}

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

Re: [Django] #28566: Allow full filepath ignore pattern matching on collectstatic command

[Django]

#28566: Allow full filepath ignore pattern matching on collectstatic command
-+-
 Reporter:  Daniel Wiesmann  |Owner:  Daniel
 Type:   |  Wiesmann
  Cleanup/optimization   |   Status:  closed
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"8f75d21a2e6d255848ae441d858c6ea819e3d100" 8f75d21a]:
 {{{
 #!CommitTicketReference repository=""
 revision="8f75d21a2e6d255848ae441d858c6ea819e3d100"
 Fixed #28566 -- Added path matching to collectstatic ignore patterns.
 }}}

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

Re: [Django] #29548: Add official support for MariaDB

[Django]

#29548: Add official support for MariaDB
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"c28bf990d71a8befb954482e3d6a925e89f3176f" c28bf990]:
 {{{
 #!CommitTicketReference repository=""
 revision="c28bf990d71a8befb954482e3d6a925e89f3176f"
 Refs #29548 -- Fixed GIS tests on MariaDB
 }}}

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

Re: [Django] #29563: SQLite and Queryset.iterator() support

[Django]

#29563: SQLite and Queryset.iterator() support
-+-
 Reporter:  Andrew Brown |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Schneier):

 Django 2.2 only supports Python 3.5+ anyway.

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

Re: [Django] #29563: SQLite and Queryset.iterator() support

[Django]

#29563: SQLite and Queryset.iterator() support
-+-
 Reporter:  Andrew Brown |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ramiro Morales):

 * stage:  Unreviewed => Accepted


Comment:

 Accepting tentatively based on the analysis Andrew did.

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

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ole Laursen):

 * cc: Ole Laursen (added)


Comment:

 Daniel Miller: Can I humbly suggest you raise this on django-developers? I
 would guess this needs a discussion of the actual API for adding the table
 expressions and joining with them.

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

Re: [Django] #29563: SQLite and Queryset.iterator() support

[Django]

#29563: SQLite and Queryset.iterator() support
-+-
 Reporter:  Andrew Brown |Owner:  nobody
 Type:  Uncategorized|   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
-+-
Changes (by Ryan P Kilby):

 * cc: Ryan P Kilby (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/065.bdb2891afdebc19ec4828f6ef09a65b2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28944: Chaining values()/values_list() after QuerySet.select_for_update(of=()) crashes

[Django]

#28944: Chaining values()/values_list() after QuerySet.select_for_update(of=())
crashes
-+-
 Reporter:  Thierry Bastian  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 Anssi started a [https://github.com/django/django/pull/9984 PR] but
 doesn't have time to finish it.

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

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

[Django] #29563: SQLite and Queryset.iterator() support

[Django]

#29563: SQLite and Queryset.iterator() support
-+-
   Reporter:  Andrew |  Owner:  nobody
  Brown  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  master
  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  |
-+-
 I’m writing a non-web app that uses Django as the ORM and SQLite as the
 backend, and I have a need to iterate over large tables efficiently.
 Django’s documentation says Queryset.iterator() does not work on SQLite
 [#ref1 (1)] [#ref2 (2)] but I tried it anyways, and discovered that it
 works: results are not read into memory in entirety, but streamed from the
 database in chunks. I traced this to an apparent logic error in the
 SQLCompiler.execute_sql() method [#ref3 (3)] and the interpretation of the
 can_use_chunked_reads flag. More on this below.

 But I was curious why it didn’t crash or get some error from the SQLite
 library despite the Django documentation saying SQLite doesn’t support
 streaming queries. Careful reading of the SQLite documentation seems to
 indicate there’s no problem reading a query in one cursor and writing to
 the database (even the same table) in another. There’s a caveat about
 isolation [#ref4 (4)] to watch out for, but otherwise seems like a
 perfectly supported mode of operation.

 So I dug into Django’s history and I came upon Django bug #7411. This bug
 was written in June 2008. At the time, the latest version of SQLite was
 3.5.9, which didn’t support database commits interleaved with partially
 read cursors. So the workaround implemented was to read the entire query
 result into memory. The database feature flag “can_use_chunked_reads” was
 added, and this was set to False in the SQLite backend. Code was added to
 the SQLCompiler.execute_sql() method to wrap the result iterator in
 list(result) if that flag was false [3b37c8151a]. I call this a
 “workaround” because it’s working around a limitation SQLite had at the
 time.

 However, later that year SQLite version 3.6.5 was released, which added
 the ability to run COMMIT simultaneously with other read operations [#ref5
 (5)]. I was not able to reproduce bug #7411 using SQLite versions >=
 3.6.5. This version was released in November 2008.

 So about that bug in SQLCompiler.execute_sql(). From what I can tell,
 Django ticket #16614 committed a change [f3b7c05936] which introduced a
 logic bug to the relevant code in June 2016, reproduced below [#ref3 (3)]:

 {{{#!python
 if not chunked_fetch and not
 self.connection.features.can_use_chunked_reads:
 try:
 # If we are using non-chunked reads, we return the same data
 # structure as normally, but ensure it is all read into memory
 # before going any further. Use chunked_fetch if requested.
 return list(result)
 finally:
 # done with the cursor
 cursor.close()
 return result
 }}}

 Notice the condition will skip the if statement body if either
 chunked_fetch is True or if can_use_chunked_reads is True. Since calling
 queryset.iterator() sets chunked_fetch to True, the can_use_chunked_reads
 flag is ignored and the if statement skipped. I believe the “and” should
 be an “or”, which would return list(result) if the database doesn’t
 support chunked reads regardless of the chunked_fetch value.

 Regardless of that bug, I suggest the workaround be removed entirely since
 it hasn’t been necessary since 2008 and hasn’t been functional since 2016.
 If we need to support the can_use_chunked_reads flag for compatibility
 with custom and third-party database backends, then we can fix the logic
 error and set SQLite’s flag to True. Documentation should be updated
 accordingly.

 If there is a reason for keeping chunked reads disabled for SQLite (such
 as the SQLite caveats on isolation [#ref4 (4)], or needing to support
 older versions of SQLite <3.6.5), then the logic error should be fixed.

 I’m willing to put in a pull request, but since the situation is quite
 complicated (the workaround also inadvertently helped avoid a related bug
 in Python’s sqlite3 driver, [[https://bugs.python.org/issue10513|#10513]],
 fixed as of Python 2.7.13 and 3.5.3) I wanted to keep this report as short
 as I could to get some feedback first.

 [=#ref1 (1)] https://docs.djangoproject.com/en/2.0/ref/models/querysets
 /#without-server-side-cursors
 [=#ref2 (2)]
 
https://github.com/django/django/blob/2.0.7/django/db/backends/sqlite3/features.py#L9
 

Re: [Django] #29425: Auto language redirect does not work if prefix_default_language=False in root URLConf

[Django]

#29425: Auto language redirect does not work if prefix_default_language=False in
root URLConf
-+-
 Reporter:  Nathan Humphreys |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 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 Tim Graham):

 * cc: Krzysztof Urbaniak (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/069.d03a414ecde16d4f90d5324aba95e983%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23976: ValidationError crashes if initialized with a list of empty dicts

[Django]

#23976: ValidationError crashes if initialized with a list of empty dicts
-+-
 Reporter:  archivarius888   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  exceptions,  | Triage Stage:  Accepted
  ValidationError|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


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

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

Re: [Django] #29562: Allow the cache template tag to take a function that adds context data (was: An idea for improving the template fragment cache)

[Django]

#29562: Allow the cache template tag to take a function that adds context data
-+--
 Reporter:  HongWeipeng  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Tim Graham):

 * status:  new => closed
 * component:  Core (Cache system) => Template system
 * resolution:   => wontfix


Comment:

 I think the proposed functionality is clever but it's too magical for my
 liking. Allowing the template tag's "fragment name" to be a function whose
 return value, if a dictionary, is added to the context looks like it
 wouldn't help template readability.

 Also, I don't think the enhancement is in line with the philosophy of the
 Django template language, "the template system is meant to express
 presentation, not program logic." What I would probably do is write a
 custom get_data template tag and have that also take care of the caching.
 Your template tag can call `template.render()`. See
 TicketClosingReasons/UseSupportChannels for places to get help if needed.

 If you disagree with my assessment, you can write to the
 DevelopersMailingList to get other opinions.

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

Re: [Django] #29544: Django 2.0.7 broke regex lookup on MariaDB

[Django]

#29544: Django 2.0.7 broke regex lookup on MariaDB
-+-
 Reporter:  Michal Čihař |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.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 Adam (Chainz) Johnson):

 * cc: Adam (Chainz) Johnson (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/063.991170f7e062c0ecd1eb2ac324fad65f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.