Re: [Django] #27620: Add a TransactionMiddleware

[Django]

#27620: Add a TransactionMiddleware
--+-
 Reporter:  Tim Graham|Owner:  luojiebin
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 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 luojiebin):

 Do this middleware want to do the same thing as the one in Django 1.7
 except that it applies only to view functions, not including those
 middleware modules coming after it? Can you explain it in more detail?
 Thanks.
  to [ticket:27620 Tim Graham]:
 > With new-style middleware, it should be feasible to write a
 `TransactionMiddleware` that works properly (as opposed to the version in
 Django 1.7 and older).

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

Re: [Django] #27620: Add a TransactionMiddleware

[Django]

#27620: Add a TransactionMiddleware
--+-
 Reporter:  Tim Graham|Owner:  luojiebin
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 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 luojiebin):

 * owner:  nobody => luojiebin
 * status:  new => assigned


Comment:

 Do this middleware want to do the same thing as the one in Django 1.7
 except that it applies only to view functions, not including those
 middleware modules coming after it? Can you explain it in more detail?
 Thanks.

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

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

Re: [Django] #24423: Combine i18n template tag tests

[Django]

#24423: Combine i18n template tag tests
-+-
 Reporter:  Preston Timmons  |Owner:  Andy
 Type:   |  Craze
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Andy Craze):

 * owner:  (none) => Andy Craze
 * status:  new => assigned


Comment:

 Added a PR with all the i18n template tags reorganized into
 syntax_tests/i18n:
 https://github.com/django/django/pull/7724

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

Re: [Django] #26369: Allow override of hardcoded defaults in model Field.formfield()

[Django]

#26369: Allow override of hardcoded defaults in model Field.formfield()
-+-
 Reporter:  James Pic|Owner:  James Pic
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by James Pic):

 I'm unsure if I wouldn't prefer to just be able to define a project-level
 default formfield callback, because that's going to depend on what the
 INSTALLED_APPS provide. Then for example, to make all relations to Foo a
 particular widget instead of Select, and to make all CharFields have a
 text field:

 {{{
 # settings.py:
 DEFAULT_FORMFIELD='project.forms.project_formfield'

 # project/forms.py
 def project_formfield(db_field, form_class, defaults):
 if db_field.rel.to == Foo:
 defaults['widget'] = forms.RadioSelect

 if db_field.model == Foo and isinstance(db_field, models.CharField):
 defaults['widget'] = forms.Textarea

 return form_class(**defaults)
 }}}

 This seems even more powerful, anybody would like to take a look at such
 an implementation ?

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

Re: [Django] #26369: Allow override of hardcoded defaults in model Field.formfield()

[Django]

#26369: Allow override of hardcoded defaults in model Field.formfield()
-+-
 Reporter:  James Pic|Owner:  James Pic
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by James Pic):

 * owner:  nobody => James Pic
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * status:  new => assigned


Comment:

 PR: https://github.com/django/django/pull/7723

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

Re: [Django] #25492: Check deferred foreign key constraints before dropping them

[Django]

#25492: Check deferred foreign key constraints before dropping them
--+
 Reporter:  Joey Wilhelm  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  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
--+
Changes (by Simon Charette):

 * stage:  Ready for checkin => Accepted


Comment:

 I adjusted the patch to perform `SET CONSTRAINT %(name)s IMMEDIATE` before
 dropping a constraint only on PostgreSQL as it's the only backend that
 supports both deferrable foreign keys and transactional DDL which are the
 two conditions required for this issue to arise.

 I used feature detection with `skipUnlessDbFeature` to make sure the test
 will be run on SQLite If we were to make foreign keys `DEFERRABLE
 INITIALLY DEFERRED`
 [https://code.djangoproject.com/ticket/14204#comment:19 like they are on
 PostgreSQL and Oracle].

 @shai
 > Haven't got time to review the patch, just wanted to note that mixing
 schema-altering operations with data-modifying operations can have other
 issues, mostly related to deferred SQL

 Don't worry, this patch isn't about encouraging  both types of alteration
 to be performed in the same migration which is another can of worm. It's
 focusing on making sure we perform the pending checks on foreign key
 constraints before dropping 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/069.1edb53fe11d8afb4913849861dabadef%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27489: Renaming a model doesn't rename the permission name and codename

[Django]

#27489: Renaming a model doesn't rename the permission name and codename
--+-
 Reporter:  Tim Graham|Owner:  Morgan Aubert
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


Comment:

 I left comments for improvement on the patch.

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

Re: [Django] #27600: Support reading commands from stdin in shell command

[Django]

#27600: Support reading commands from stdin in shell command
-+-
 Reporter:  James Pic|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"bf6392bb7565c21f01ed6f682b8558dcf1cc8070" bf6392bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="bf6392bb7565c21f01ed6f682b8558dcf1cc8070"
 Fixed #27600 -- Suppressed the REPL during shell's reading from stdin.

 Thanks Adam Chainz for review and guidance.
 }}}

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

Re: [Django] #27612: Add a check that URL instance namespaces are unique across a project

[Django]

#27612: Add a check that URL instance namespaces are unique across a project
-+-
 Reporter:  Tim Graham   |Owner:  Andrew
 Type:   |  Nester
  Cleanup/optimization   |   Status:  closed
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"24fa728a476a6da3e565dbe33959ea62c02c250b" 24fa728a]:
 {{{
 #!CommitTicketReference repository=""
 revision="24fa728a476a6da3e565dbe33959ea62c02c250b"
 Fixed #27612 -- Added a check for duplicate URL instance namespaces.
 }}}

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

Re: [Django] #27498: Filtering annotated field in SQLite returns wrong results

[Django]

#27498: Filtering annotated field in SQLite returns wrong results
-+-
 Reporter:  Tim Düllmann |Owner:  Peter
 |  Inglesby
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite,  | Triage Stage:  Accepted
  annotations, filter|
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


Comment:

 Comments for improvement are on the 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.b602cf86cc0da5cb425709ae5e5ef4c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27458: Oracle backend giving ORA-00911 : Invalid Character, querying with a literal "%s"

[Django]

#27458: Oracle backend giving ORA-00911 : Invalid Character, querying with a
literal "%s"
-+-
 Reporter:  Gabriel Canto de |Owner:  Andrew
  Souza  |  Nester
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle   | 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
 * stage:  Ready for checkin => Accepted


Comment:

 I left some comments for improvement on the PR and closed #18514 as a
 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 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.1f50d1815b159c2e7a1c7659ae8dab4f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18514: Creating sequences fails with Oracle 01741 error on custom table name with quotes (was: Syncdb + Oracle + custom table name with quotes = Oracle 01741 error)

[Django]

#18514: Creating sequences fails with Oracle 01741 error on custom table name 
with
quotes
-+-
 Reporter:  obmuc|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  oracle   | Triage Stage:  Accepted
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:   => duplicate


Comment:

 The offending query is:
 {{{
 BEGIN
 SELECT COUNT(1) INTO i FROM USER_SEQUENCES
 WHERE SEQUENCE_NAME = '"DJANGOTEST"."TABLE_NAME"_SQ';
 IF i = 0 THEN
 EXECUTE IMMEDIATE 'CREATE SEQUENCE
 ""DJANGOTEST"."TABLE_NAME"_SQ"';
 END IF;
 END;
 }}}
 Looks like this is fixed by #27458.

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

Re: [Django] #25753: Cache formats retrieved from django settings in formats.get_format

[Django]

#25753: Cache formats retrieved from django settings in formats.get_format
-+-
 Reporter:  Jaap Roes|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 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
-+-

Comment (by Claude Paroz ):

 In [changeset:"1206d7fa5793a86ffadeacb2e9280b11d474a58a" 1206d7fa]:
 {{{
 #!CommitTicketReference repository=""
 revision="1206d7fa5793a86ffadeacb2e9280b11d474a58a"
 Refs #25753 -- Reset l10n cache when format settings change

 Thanks Jaap Roes for the initial patch.
 }}}

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

Re: [Django] #25753: Cache formats retrieved from django settings in formats.get_format

[Django]

#25753: Cache formats retrieved from django settings in formats.get_format
-+-
 Reporter:  Jaap Roes|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 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 Claude Paroz ):

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


Comment:

 In [changeset:"3188b49ee29bb8c7183b55bda784e642a6ec3011" 3188b49e]:
 {{{
 #!CommitTicketReference repository=""
 revision="3188b49ee29bb8c7183b55bda784e642a6ec3011"
 Fixed #25753 -- Made get_format() cache the formats from Django settings
 }}}

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

Re: [Django] #27258: Raise an exception if RequestContext is used with template.backends.django.Template.render()

[Django]

#27258: Raise an exception if RequestContext is used with
template.backends.django.Template.render()
-+-
 Reporter:  Andi Albrecht|Owner:  reficul31
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  1 => 0


Comment:

 I fixed up the [https://github.com/django/django/pull/7675 PR] according
 to what I had in mind. The idea is that Jinja's `render()` doesn't work
 with a non-dict, so to encourage code that works with multiple template
 engines, Django shouldn't accept a non-dict there either.

 I think making this change as a bug fix rather than having a deprecation
 path is advantageous to avoid developers writing incorrect code for
 another 2 releases of Django. Also, it's possible to fix existing code
 (change `Context` to  `dict` as done in the csrf view) without breaking
 compatibility with older versions of Django so a deprecation doesn't
 provide any benefit in that respect.

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

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

[Django] #27620: Add a TransactionMiddleware

[Django]

#27620: Add a TransactionMiddleware
+
   Reporter:  Tim Graham|  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  Core (Other)  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 With new-style middleware, it should be feasible to write a
 `TransactionMiddleware` that works properly (as opposed to the version in
 Django 1.7 and older).

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

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

Re: [Django] #14204: Take advantage of SQLite support for FK constraints

[Django]

#14204: Take advantage of SQLite support for FK constraints
-+-
 Reporter:  Ramiro Morales   |Owner:  Claude
 |  Paroz
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, foreign key  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 I don't have the time to investigate right now, but if it can help
 someone, I rebased the commit which is now
 
https://github.com/claudep/django/commit/15ceb2cc05262fe5f24f16cc31367fe6b5b698c1

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

Re: [Django] #27458: Oracle backend giving ORA-00911 : Invalid Character, querying with a literal "%s"

[Django]

#27458: Oracle backend giving ORA-00911 : Invalid Character, querying with a
literal "%s"
-+-
 Reporter:  Gabriel Canto de |Owner:  Andrew
  Souza  |  Nester
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle   | 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 Simon Charette):

 * cc: Simon Charette (added)
 * version:  1.10 => master
 * stage:  Accepted => Ready for checkin


Comment:

 LGTM pending a final docstring review of the `strip_trailing_quotes`
 function from a native speaker.

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

Re: [Django] #23919: Cleanups for when we drop Python 2 compatibility

[Django]

#23919: Cleanups for when we drop Python 2 compatibility
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Tim Graham:

Old description:

> This is a tracking ticket of things that we can remove when we drop
> Python 2 compatibility in Django 2.0. Please edit the description of the
> ticket as you come across new items.
>
> * `django.core.mail.message.make_msgid()` #23905
> * `django.dispatch.weakref_backports`
> * `django.http.cookie` workarounds
> * `django.utils.2to3_fixes`
> * `django.utils.decorators.ContextDecorator`
> * `django.utils.encoding`
>  * `@python_2_unicode_compatible`
>  * force/smart _unicode
>  * either force/smart _text or force/smart _str
> * `django.utils.html_parser.use_workaround`
> * `django.utils.http` functions like `urlquote_plus` -- I think the
> versions of these functions on Python 3 don't have the unicode characters
> bug we are working around.
> * `django.utils.lru_cache`
> * `django.utils.six`
> * `from __future__ import unicode_literals`
> * `str()` stuff for environment variables, e.g.
> 0bfb53866199f366ed140d49938fd185e5898156
> * Inheriting from `object` in `django.core.servers.basehttp` (and perhaps
> other places) ala 4ee06ec3fc8e94d164afbd2f9c880c60c658a9ac
> * `git grep 'long int'` (mostly docs)
> * `django.utils._os [npath,upath]`
> * In tests: `contextlib.closing(self.urlopen` (`contextlib.closing` no
> longer needed)
> * Support for pysqlite (doesn't support Python 3)
> * Replace `super(ClassName, self)` with `super()`
> * Remove `# -*- coding: utf-8 -*-` source file encoding (that's the
> default on Python 3)
> * Evaluate replacement of custom `__del__` methods by
> [https://docs.python.org/3/library/weakref.html#weakref.finalize
> weakref.finalize]
> * Remove `__ne__` from objects already defining a `__eq__`
> * Remove note about PYTHONHASHSEED (see #26243)
> * Remove Field.creation_counter (replace by metaclass `__prepare__`
> returning `OrderedDict()`,
> https://docs.python.org/3/reference/datamodel.html#preparing-the-class-
> namespace)
> * `django.test.utils.reset_warning_registry()`
> * Replace `errno` checks by `IOError` subclasses defined by
> [https://www.python.org/dev/peps/pep-3151/ PEP 3151]
> * `django.utils.glob`
> * `django.utils.cookies.SimpleCookie`
> * `django.test.mock`
> * Replace `tempfile.mkdtemp` + remove with `tempfile.TemporaryDirectory`
> context manager
> * Replace `io.open()` by a plain `open()`
> * Evaluate need for `assertRegex`, `assertRaisesRegex` in tests. Some
> usage is merely to account for differences in messages between Python 2
> and 3.

New description:

 This is a tracking ticket of things that we can remove when we drop Python
 2 compatibility in Django 2.0. Please edit the description of the ticket
 as you come across new items.

 * `django.core.mail.message.make_msgid()` #23905
 * `django.dispatch.weakref_backports`
 * `django.http.cookie` workarounds
 * `django.utils.2to3_fixes`
 * `django.utils.decorators.ContextDecorator`
 * `django.utils.encoding`
  * `@python_2_unicode_compatible`
  * force/smart _unicode
  * either force/smart _text or force/smart _str
 * `django.utils.html_parser.use_workaround`
 * `django.utils.http` functions like `urlquote_plus` -- I think the
 versions of these functions on Python 3 don't have the unicode characters
 bug we are working around.
 * `django.utils.lru_cache`
 * `django.utils.six`
 * `from __future__ import unicode_literals`
 * `str()` stuff for environment variables, e.g.
 0bfb53866199f366ed140d49938fd185e5898156
 * Inheriting from `object` in `django.core.servers.basehttp` (and perhaps
 other places) ala 4ee06ec3fc8e94d164afbd2f9c880c60c658a9ac
 * `git grep 'long int'` (mostly docs)
 * `django.utils._os [npath,upath]`
 * In tests: `contextlib.closing(self.urlopen` (`contextlib.closing` no
 longer needed)
 * Support for pysqlite (doesn't support Python 3)
 * Replace `super(ClassName, self)` with `super()`
 * Remove `# -*- coding: utf-8 -*-` source file encoding (that's the
 default on Python 3)
 * Evaluate replacement of custom `__del__` methods by
 [https://docs.python.org/3/library/weakref.html#weakref.finalize
 weakref.finalize]
 * Remove `__ne__` from objects already defining a `__eq__`
 * Remove note about PYTHONHASHSEED (see 

Re: [Django] #25484: static template tag outputs invalid HTML if storage class's url() returns a URI with '&' characters.

[Django]

#25484: static template tag outputs invalid HTML if storage class's url() 
returns a
URI with '&' characters.
-+
 Reporter:  João Miguel Neves|Owner:  alix-
 Type:  Bug  |   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:  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/064.beef81f44b07098a262856a8957428e2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27619: Queries where column name includes a '%' character break when using MySQL

[Django]

#27619: Queries where column name includes a '%' character break when using 
MySQL
-+-
 Reporter:  Zach Zundel  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * component:  Uncategorized => Database layer (models, ORM)
 * resolution:   => duplicate
 * type:  Uncategorized => Bug


Comment:

 Duplicate of #6343

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

Re: [Django] #27518: HTTP Referer leaks password reset link

[Django]

#27518: HTTP Referer leaks password reset link
-+-
 Reporter:  Romain Garrigues |Owner:  Romain
 Type:   |  Garrigues
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  password reset   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Romain Garrigues):

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

Re: [Django] #27612: Add a check that URL instance namespaces are unique across a project

[Django]

#27612: Add a check that URL instance namespaces are unique across a project
-+-
 Reporter:  Tim Graham   |Owner:  Andrew
 Type:   |  Nester
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 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 Andrew Nester):

 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0


Comment:

 I updated pull request according to requested changes and added
 documentation for new check

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

Re: [Django] #27619: Queries where column name includes a '%' character break when using MySQL

[Django]

#27619: Queries where column name includes a '%' character break when using 
MySQL
---+--
 Reporter:  Zach Zundel|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Zach Zundel):

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

[Django] #27619: Queries where column name includes a '%' character break when using MySQL

[Django]

#27619: Queries where column name includes a '%' character break when using 
MySQL
-+
   Reporter:  Zach Zundel|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.10
   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  |
-+
 Sorry about this nonsense, but...

 I have a table in MySQL with a column name '%exp'. I know this is a poor
 choice for a column name.

 When calling the objects.all(), I was getting a rather frustrating error
 message from pyMySQL, "not enough arguments for format string." I couldn't
 figure out what was causing it until I printed result of calling
 QuerySet.Query.sql_with_params() on the resulting QuerySet. I saw that
 there were no params, but the string contained %e, which python
 interpreted as trying to format the string.

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