date:20160830

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

2016-08-30 Thread Django

#26401: Allow auth machinery to be used without installing auth app
--+
 Reporter:  satchamo  |Owner:  andkon
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  auth  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by jdufresne):

 [https://github.com/django/django/pull/7188 PR] implementing the
 `AppConfig`s described above.

 Not sure how to best add a test for this though. Looking for advice.
 Details in 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/066.27448c30b71c6cc6a6029cc96b0178f6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27153: HttpResponseBase should check for valid HTTP status code

2016-08-30 Thread Django

#27153: HttpResponseBase should check for valid HTTP status code
-+-
 Reporter:  ryangallen   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  1.10
 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 Tim Graham ):

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


Comment:

 In [changeset:"190d2ff4a7a392adfe0b12552bd71871791d87aa" 190d2ff4]:
 {{{
 #!CommitTicketReference repository=""
 revision="190d2ff4a7a392adfe0b12552bd71871791d87aa"
 Fixed #27153 -- Added validation for HttpResponse status.
 }}}

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

Re: [Django] #27081: Allow migrations to serialize methods on pypy

2016-08-30 Thread Django

#27081: Allow migrations to serialize methods on pypy
+
 Reporter:  Kurdakov|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.9
 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 GitHub ):

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


Comment:

 In [changeset:"96ee486ea415a532dbded3209114b98736031118" 96ee486e]:
 {{{
 #!CommitTicketReference repository=""
 revision="96ee486ea415a532dbded3209114b98736031118"
 Fixed #27081 -- Allowed migrations to serialize methods on pypy.
 }}}

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

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

Re: [Django] #27145: Discrepenacy between documentation and docstring for Storage.save method

2016-08-30 Thread Django

#27145: Discrepenacy between documentation and docstring for Storage.save method
-+-
 Reporter:  pacahon  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 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 Tim Graham ):

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


Comment:

 In [changeset:"3f16e4df494dc9143d110b886c8e8608f9d2b584" 3f16e4df]:
 {{{
 #!CommitTicketReference repository=""
 revision="3f16e4df494dc9143d110b886c8e8608f9d2b584"
 Fixed #27145 -- Updated Storage.save() docs for refs #18899.
 }}}

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

Re: [Django] #27145: Discrepenacy between documentation and docstring for Storage.save method

2016-08-30 Thread Django

#27145: Discrepenacy between documentation and docstring for Storage.save method
-+-
 Reporter:  pacahon  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 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
-+-

Comment (by Tim Graham ):

 In [changeset:"f79dce16bc8b326e1ab61a71f8e841495c52c6ff" f79dce16]:
 {{{
 #!CommitTicketReference repository=""
 revision="f79dce16bc8b326e1ab61a71f8e841495c52c6ff"
 [1.10.x] Fixed #27145 -- Updated Storage.save() docs for refs #18899.

 Backport of 3f16e4df494dc9143d110b886c8e8608f9d2b584 from master
 }}}

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

Re: [Django] #18899: FileSystemStorage.save should support any file-like objects

2016-08-30 Thread Django

#18899: FileSystemStorage.save should support any file-like objects
-+-
 Reporter:  vzima|Owner:  biern
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  File |  Version:  1.4
  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
-+-

Comment (by Tim Graham ):

 In [changeset:"f79dce16bc8b326e1ab61a71f8e841495c52c6ff" f79dce16]:
 {{{
 #!CommitTicketReference repository=""
 revision="f79dce16bc8b326e1ab61a71f8e841495c52c6ff"
 [1.10.x] Fixed #27145 -- Updated Storage.save() docs for refs #18899.

 Backport of 3f16e4df494dc9143d110b886c8e8608f9d2b584 from master
 }}}

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

Re: [Django] #18899: FileSystemStorage.save should support any file-like objects

2016-08-30 Thread Django

#18899: FileSystemStorage.save should support any file-like objects
-+-
 Reporter:  vzima|Owner:  biern
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  File |  Version:  1.4
  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
-+-

Comment (by Tim Graham ):

 In [changeset:"3f16e4df494dc9143d110b886c8e8608f9d2b584" 3f16e4df]:
 {{{
 #!CommitTicketReference repository=""
 revision="3f16e4df494dc9143d110b886c8e8608f9d2b584"
 Fixed #27145 -- Updated Storage.save() docs for refs #18899.
 }}}

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

Re: [Django] #27110: makemigrations shouldn't create `django_migrations` table in external databases

2016-08-30 Thread Django

#27110: makemigrations shouldn't create `django_migrations` table in external
databases
-+-
 Reporter:  direx|Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 An alternate proposal about consulting database routers is under
 discussion in #27142. It would be nice to have some confirmation that it
 solves your use case.

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

Re: [Django] #27113: Test that setting HttpRequest.encoding clears POST (was: Add tests for setting HttpRequest.encoding)

2016-08-30 Thread Django

#27113: Test that setting HttpRequest.encoding clears POST
--+
 Reporter:  timgraham |Owner:  PREM1980
 Type:  Cleanup/optimization  |   Status:  closed
Component:  HTTP handling |  Version:  1.10
 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
--+

Comment (by timgraham):

 I created #27156 for the follow up ticket.

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

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

[Django] #27156: Setting HttpRequest.encoding should clear GET

2016-08-30 Thread Django

#27156: Setting HttpRequest.encoding should clear GET
-+
   Reporter:  timgraham  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  HTTP handling  |Version:  1.10
   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  |
-+
 Discovered in #27113, commit d7a4b156d935ffcb8cdd9290688457453fc06b24
 broke clearing of `request.GET` when `request.encoding` changes. I think
 the line in the `encoding.settr` needs to use `del self.GET` instead of
 `del self._get`.

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

Re: [Django] #27113: Add tests for setting HttpRequest.encoding

2016-08-30 Thread Django

#27113: Add tests for setting HttpRequest.encoding
--+
 Reporter:  timgraham |Owner:  PREM1980
 Type:  Cleanup/optimization  |   Status:  closed
Component:  HTTP handling |  Version:  1.10
 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:"c41fd66f774b0d67876d3d22beeb783ab5bfa442" c41fd66f]:
 {{{
 #!CommitTicketReference repository=""
 revision="c41fd66f774b0d67876d3d22beeb783ab5bfa442"
 Fixed #27113 -- Tested that setting HttpRequest.encoding clears POST.
 }}}

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

Re: [Django] #26685: Implement Spatialite PtDistWithin() in GeoDjango

2016-08-30 Thread Django

#26685: Implement Spatialite PtDistWithin() in GeoDjango
-+-
 Reporter:  deed02392|Owner:
 |  kevswanberg
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  spatialite dwithin   | 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:"35504f74a8c3b45d308969a77488d11443ce4348" 35504f74]:
 {{{
 #!CommitTicketReference repository=""
 revision="35504f74a8c3b45d308969a77488d11443ce4348"
 Fixed #26685 -- Added dwithin lookup support on SpatiaLite.
 }}}

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

Re: [Django] #27149: Filtering with generic relation

2016-08-30 Thread Django

#27149: Filtering with generic relation
-+-
 Reporter:  MikiSoft |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by MikiSoft):

 Exactly, timgraham. Thanks for clearing it up instead of 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0f11ae3dd8bd79ddb76a5de232c7bd38%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27149: Filtering with generic relation

2016-08-30 Thread Django

#27149: Filtering with generic relation
-+-
 Reporter:  MikiSoft |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I think the intention of this ticket was to present a case where
 `QuerySet.extra` is required. If we want to deprecate it, we need to
 provide an alternative for accomplishing this.

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

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

Re: [Django] #25109: MigrationLoader.load_disk hides ImportError for invalid MIGRATION_MODULES

2016-08-30 Thread Django

#25109: MigrationLoader.load_disk hides ImportError for invalid 
MIGRATION_MODULES
+-
 Reporter:  blueyed |Owner:  berkerpeksag
 Type:  Bug |   Status:  closed
Component:  Migrations  |  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 Simon Charette ):

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


Comment:

 In [changeset:"0d7929266ec9d8f6bcf9e41a40b281259cba6a79" 0d79292]:
 {{{
 #!CommitTicketReference repository=""
 revision="0d7929266ec9d8f6bcf9e41a40b281259cba6a79"
 Fixed #25109 -- Stopped silencing explicitly specified migration modules
 import errors.

 Thanks Tim for the review.
 }}}

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

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

Re: [Django] #27149: Filtering with generic relation

2016-08-30 Thread Django

Comment (by shaib):

Hi,

Thanks for the suggestion; the code, as given, is not fit for general use
because it makes assumptions which are not guaranteed to hold:
- it assumes the `model` and `target` belong to the same app
- it assumes the modles use the default table names (i.e. none of the
models specifies `Meta.db_table`)
- it assumes the default app label (a different one can be set via
`AppConfig` objects)
- it assumes the names `content_type_id` and `object_id` for the
components of the generic FK -- these are not even defaults, but only a
convention

Further, the code uses `target` in a way which bakes some of these
assumptions into the API, not just the implementation.

I suggest you bring the idea up on the DevelopersMailingList, to get a
wider discussion of whether the feature fits for inclusion in Django, and
if so, to define an API everyone agrees on. When you do, please make sure
you present the problem before you suggest your solution.

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

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

Re: [Django] #27142: makemigrations fails on special database connections

2016-08-30 Thread Django

#27142: makemigrations fails on special database connections
-+
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by shaib):

 Replying to [comment:7 timgraham]:
 >
 > I think it's possible to use multiple databases without using database
 routers. For example, `migrate` requires a database alias, so if you have
 a read-only database, it's usable without a router as long as you don't
 try to migrate it. (I didn't test it so I could be incorrect but perhaps
 someone can confirm that.)
 >
 > I think consulting database routers could still be a backwards-
 incompatible change for some users since it would now require routers to
 be setup for read-only databases.

 No database routers would mean that, by default, all queries would run
 against the `default` database; perhaps in that case we should only check
 for consistency against it. If the history were consistent in `default`
 and inconsistent elsewhere, it would suggest to me that the problem is in
 that database rather than migration files, and so catching it in `migrate`
 would be sufficient.

 Perhaps even generally, if `default` allows migrating the app, there is no
 need to check for consistency on other databases.

 Replying to [comment:8 sjoerdjob]:
 > How about the intermediate option of adding a `--no-check-consistency`
 command line argument.

 I'm -0 on this as a feature, and -1 on an interim solution. I am neutral 0
 on a `--no-force-consistency` which turns all errors encountered in
 consistency checking into warnings.

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

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

Re: [Django] #27155: makemigrations --no-check-consistency command line argument

2016-08-30 Thread Django

#27155: makemigrations --no-check-consistency command line argument
-+-
 Reporter:  sjoerdjob|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  makemigrations,  | Triage Stage:
  check_consistent_history   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization


Comment:

 It's a non-trivial amount of work to add and documentation a new option
 and then to deprecate it if we fix things later, so I'm not in favor. If
 it's truly a blocker for a project, a workaround is to add your own
 `makemigrations` command without the consistency check, so the issue is
 really not that critical.

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

Re: [Django] #27113: Add tests for setting HttpRequest.encoding

2016-08-30 Thread Django

#27113: Add tests for setting HttpRequest.encoding
--+
 Reporter:  timgraham |Owner:  PREM1980
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  HTTP handling |  Version:  1.10
 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
--+

Comment (by PREM1980):

 Replying to [comment:4 timgraham]:

 Fixed all the issues and included test for POST request. As mentioned
 earlier, GET as a different problem and will open a different ticket to
 track it.
 https://github.com/django/django/pull/7185

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

[Django] #27155: makemigrations --no-check-consistency command line argument

2016-08-30 Thread Django

To quote Tim Graham in #27142:

> I'm beginning to think that makemigrations shouldn't have this check in
the first place due to the many issues that have been reported (#27054,
#27110, #27141) and the more and more complexity that seems needed to add
to fix it. Other opinions welcome. In my view, the most natural thing to
do after creating a migration is to apply it, so it doesn't seem like
delaying the check from makemigrations to migrate would have a huge
drawback.

I propose that we add a command line argument `--no-check-consistent-
history` (or something similar, bikeshed away!) which skips the calls to
`check_consistent_history`.

To me it seems like this should be possible to add in the next release and
takes the pressure off fixing the corner-cases a bit to make sure we can
come up with a good solution.

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

Re: [Django] #27142: makemigrations fails on special database connections

2016-08-30 Thread Django

#27142: makemigrations fails on special database connections
-+
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by sjoerdjob):

 How about the intermediate option of adding a `--no-check-consistency`
 command line argument.

 The benefit of this is that it allows the gradual improvement of the
 checking algorithm, while still providing an easy to use workaround for
 when one hits a corner case. Because right now, if you use 1.10, you're
 blocked for 1.10.1 to fix it.

 Then, for 1.11 we can still re-consider the consistency-checking.

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

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

Re: [Django] #27146: template shows empty string instead of actual content when it contains characters like \x93 and \x94

2016-08-30 Thread Django

#27146: template shows empty string instead of actual content when it contains
characters like \x93 and \x94
-+--
Reporter: bricas |Owner: nobody
Type: Bug | Status: closed
Component: Template system | Version: 1.8
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+--

Comment (by bricas):

Thanks for the update -- I also saw the same result when i tried to add a
test. I suspect there are other encoding-related issues happening.

To elaborate on the *actual* scenario we're dealing with: We have a small
Django app that parses `git diff` output and shows what those changes are.
The files being diff'ed could come from a variety of OSes in who-knows-
what encoding (including CP-1252). I have a feeling that properly reading
in the diff output would solve the issue.

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

Re: [Django] #27149: Filtering with generic relation

2016-08-30 Thread Django

#27149: Filtering with generic relation
-+-
 Reporter:  MikiSoft |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by MikiSoft:

Old description:

> The following function is used for filtering by generic relation (and
> also by one column in the model where it is) which isn't natively
> supported by Django.
>
> {{{
> def generic_rel_filter(model, target, column, id):
> return model.objects.extra(where=['''
> {app_label}_{model}.id in (select object_id
> from {app_label}_{target}
> where content_type_id = (select id from django_content_type where
> model = '{model}')
> and {column} =
> {id})'''.format(app_label=os.path.basename(os.path.dirname(__file__)),
> model=model.__name__.lower(), target=target, column=column, id=id)])
> }}}
>
> ''Example:'' If I have Event and Like model, and the second one has
> generic relation to the first one (i.e. it has `content_type`,
> `object_id` and `content_object` fields), then if I want to get all
> events which current user liked, I would just make this call in a view:
> `generic_rel_filter(Event, 'like', 'person', self.request.user.pk)`
>
> '''Note that this function isn't intended to be used with user specified
> parameters, otherwise it's prone to SQL injection attacks.'''
>
> P.S. It can be done with ORM but then it would go with three queries,
> which is much slower than the method above (which uses only one query to
> do the same):
> `Event.objects.filter(pk__in=Like.objects.filter(content_type=ContentType.objects.get(model='event'),
> person=self.request.user).values_list('object_id', flat=True))`

New description:

 The following function is used for filtering by generic relation (and also
 by one column in the model where it is) which isn't natively supported by
 Django.

 {{{
 APP_LABEL = os.path.basename(os.path.dirname(__file__))
 def generic_rel_filter(model, target, column, id):
 return model.objects.extra(where=['''
 {app_label}_{model}.id in (select object_id
 from {app_label}_{target}
 where content_type_id = (select id from django_content_type where
 model = '{model}')
 and {column} = {id})'''.format(app_label=APP_LABEL,
 model=model.__name__.lower(), target=target, column=column, id=id)])
 }}}

 ''Example:'' If I have Event and Like model, and the second one has
 generic relation to the first one (i.e. it has `content_type`, `object_id`
 and `content_object` fields), then if I want to get all events which
 current user liked, I would just make this call in a view:
 `generic_rel_filter(Event, 'like', 'person', self.request.user.pk)`

 '''Note that this function isn't intended to be used with user specified
 parameters, otherwise it's prone to SQL injection attacks.'''

 P.S. It can be done with ORM but then it would go with three queries,
 which is much slower than the method above (which uses only one query to
 do the same):
 
`Event.objects.filter(pk__in=Like.objects.filter(content_type=ContentType.objects.get(model='event'),
 person=self.request.user).values_list('object_id', flat=True))`

--

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

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

Re: [Django] #27146: template shows empty string instead of actual content when it contains characters like \x93 and \x94

2016-08-30 Thread Django

#27146: template shows empty string instead of actual content when it contains
characters like \x93 and \x94
-+--
 Reporter:  bricas   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timgraham):

 * Attachment "27146-test.diff" added.


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

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

Re: [Django] #27146: template shows empty string instead of actual content when it contains characters like \x93 and \x94

2016-08-30 Thread Django

#27146: template shows empty string instead of actual content when it contains
characters like \x93 and \x94
-+--
 Reporter:  bricas   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timgraham):

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


Comment:

 Thanks, I attached the quick test I wrote up to try to reproduce but it
 passes on Python 2 and 3, so there's probably some missing information
 about the exact steps to reproduce. Please reopen or change the resolution
 based on your investigation.

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

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

Re: [Django] #27153: HttpResponseBase should check for valid HTTP status code

2016-08-30 Thread Django

#27153: HttpResponseBase should check for valid HTTP status code
-+-
 Reporter:  ryangallen   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  1.10
 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 timgraham):

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

Re: [Django] #27128: A method model.objects.get(pk=obj.pk) returns many objects, but in a database is one.

2016-08-30 Thread Django

#27128: A method model.objects.get(pk=obj.pk) returns many objects, but in a
database is one.
-+-
 Reporter:  setivolkylany|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  GenericRelation, | Triage Stage:
  Testing, Models|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by setivolkylany):

 Replying to [comment:8 shaib]:
 > Replying to [comment:7 setivolkylany]:
 >
 > Hi,
 >
 > You are unlikely to get any more responses on this ticket -- it looks
 like your original problem is not caused by a bug in Django, and now you
 have started to ask about a different issue.
 >
 > Please use the support channels (#django IRC channel, django-users
 mailing list)  to ask more questions.

 I just made an assumption, but I just in case I am sorry about it, if this
 caused offence in you

 And about the the #django IRC channel the django-users mailing list much
 help there can not be obtained

 So, I am try to resolve my problems alone.

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

Re: [Django] #27150: Document that a name should be provided when wrapping file-like objects that don't have one with File (was: Wrong File object behavior if file object has no name attribute)

2016-08-30 Thread Django

#27150: Document that a name should be provided when wrapping file-like objects
that don't have one with File
--+
Reporter: pacahon |Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.10
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 timgraham):

* component: Core (Other) => Documentation
* type: Bug => Cleanup/optimization
* stage: Unreviewed => Accepted

Comment:

See #26495 for a case where this came up. Unless investigation yields
otherwise, I think documenting that you should pass a name for file-like
objects that don't have one is the best course of action. I'm not sure if
raising an error for that case might be acceptable (there might be use
cases where providing `name` isn't needed) but if so, they would likely be
even more helpful.

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

Re: [Django] #27142: makemigrations fails on special database connections

2016-08-30 Thread Django

Comment (by timgraham):

On [https://github.com/django/django/pull/5977#discussion_r52391536 an old
pull request], Shai said:

The reason `makemigrations` should fail is that the more likely reason
for inconsistent history is a change in the migrations code (in
particular, dependencies), rather than direct manipulation of the
database. If the code of existing migrations is suspicious, we should
avoid building more migrations on it.

I think it's possible to use multiple databases without using database
routers. For example, `migrate` requires a database alias, so if you have
a read-only database, it's usable without a router as long as you don't
try to migrate it. (I didn't test it so I could be incorrect but perhaps
someone can confirm that.)

I think consulting database routers could still be a backwards-
incompatible change for some users since it would now require routers to
be setup for read-only databases.

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

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

Re: [Django] #26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a type of a field is ForeignKey and value to_field is not pk (in my case it is UUID).

2016-08-30 Thread Django

#26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a
type of a field is ForeignKey and value to_field is not pk (in my case it
is UUID).
-+-
 Reporter:  setivolkylany|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Admin, ForeignKey,   | Triage Stage:
  models |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 There isn't a ticket status for unfixed bugs in older version of Django.
 "Fixed" simply means "fixed in some version of Django."

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

Re: [Django] #27113: Add tests for setting HttpRequest.encoding

2016-08-30 Thread Django

#27113: Add tests for setting HttpRequest.encoding
--+
 Reporter:  timgraham |Owner:  PREM1980
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  HTTP handling |  Version:  1.10
 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 timgraham):

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

Re: [Django] #26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a type of a field is ForeignKey and value to_field is not pk (in my case it is UUID).

2016-08-30 Thread Django

#26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a
type of a field is ForeignKey and value to_field is not pk (in my case it
is UUID).
-+-
Reporter: setivolkylany|Owner: nobody
Type: Bug | Status: closed
Component: contrib.admin| Version: 1.9
Severity: Normal | Resolution: fixed
Keywords: Admin, ForeignKey, | Triage Stage:
models | Unreviewed
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+-

Comment (by setivolkylany):

Replying to [comment:6 timgraham]:
> As far as I can tell this issue is fixed in Django 1.10 by the commit I
mentioned. Per our [https://docs.djangoproject.com/en/dev/internals
/release-process/#supported-versions supported versions policy], Django
1.9.x is receiving only security and data loss fixes.

Thus it is bug in the Django 1.9.7 and it must be change status
from
#26979 closed Bug (fixed)
to
#26979 open Bug (unfixed)

Are you make it?

Other developers must be know about this problem.

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

Re: [Django] #25109: MigrationLoader.load_disk hides ImportError for invalid MIGRATION_MODULES

2016-08-30 Thread Django

#25109: MigrationLoader.load_disk hides ImportError for invalid 
MIGRATION_MODULES
+-
 Reporter:  blueyed |Owner:  berkerpeksag
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  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
+-
Changes (by timgraham):

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

Re: [Django] #27146: template shows empty string instead of actual content when it contains characters like \x93 and \x94

2016-08-30 Thread Django

#27146: template shows empty string instead of actual content when it contains
characters like \x93 and \x94
-+--
 Reporter:  bricas   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by bricas):

 I apologies for the lack of details. Python & Django are not things I use
 on a daily basis.

 I originally enquired about my issue in #django and didn't get much more
 than a "that's strange" as a response.

 I will spend a little time and try to write up a test.

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

Re: [Django] #27152: Comma-delimited servers list not supported in memcached caches `LOCATION`

2016-08-30 Thread Django

#27152: Comma-delimited servers list not supported in memcached caches 
`LOCATION`
--+
 Reporter:  edmorley  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  Version:  1.10
 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 timgraham):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I guess `server.replace(',', ';').split(';')` should work.

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

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

Re: [Django] #27153: HttpResponseBase should check for valid HTTP status code

2016-08-30 Thread Django

#27153: HttpResponseBase should check for valid HTTP status code
--+
 Reporter:  ryangallen|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  HTTP handling |  Version:  1.10
 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 timgraham):

 * needs_better_patch:  0 => 1
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #27131: send_mail() error on Python 2 if smtp server uses CRAM-MD5 auth method (was: send_mail error if smtp server uses CRAM-MD5 auth method)

2016-08-30 Thread Django

#27131: send_mail() error on Python 2 if smtp server uses CRAM-MD5 auth method
-+-
 Reporter:  slavugan |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  send_mail| 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 timgraham):

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

Re: [Django] #27097: Add introspection for index type

2016-08-30 Thread Django

#27097: Add introspection for index type
-+-
 Reporter:  akki |Owner:  akki
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  introspection db-| Triage Stage:  Accepted
  indexes 1.11   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Introspection doesn't seem to work on MySQL 5.5.

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

Re: [Django] #27154: Minor difference in behavior between CallableFalse/CallableTrue and False/True.

2016-08-30 Thread Django

#27154: Minor difference in behavior between CallableFalse/CallableTrue and
False/True.
--+
 Reporter:  tomchristie   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  1.10
 Severity:  Release blocker   |   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 timgraham):

 * severity:  Normal => Release blocker


Comment:

 The implementation can follow commit
 54afa960d1ee8c63635225a0f0a2489971b5aab5.

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

Re: [Django] #26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a type of a field is ForeignKey and value to_field is not pk (in my case it is UUID).

2016-08-30 Thread Django

#26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a
type of a field is ForeignKey and value to_field is not pk (in my case it
is UUID).
-+-
 Reporter:  setivolkylany|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Admin, ForeignKey,   | Triage Stage:
  models |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * resolution:  needsinfo => fixed


Comment:

 As far as I can tell this issue is fixed in Django 1.10 by the commit I
 mentioned. Per our [https://docs.djangoproject.com/en/dev/internals
 /release-process/#supported-versions supported versions policy], Django
 1.9.x is receiving only security and data loss fixes.

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

Re: [Django] #26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a type of a field is ForeignKey and value to_field is not pk (in my case it is UUID).

2016-08-30 Thread Django

#26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a
type of a field is ForeignKey and value to_field is not pk (in my case it
is UUID).
-+-
 Reporter:  setivolkylany|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Admin, ForeignKey,   | Triage Stage:
  models |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by setivolkylany):

 Replying to [comment:4 timgraham]:
 > After 815f4d206dfea41bdff167283c2cac43a71524ac, the sample project shows
 "Cannot find 'comment' on Utility object, 'comment' is an invalid
 parameter to prefetch_related()".

 Sorry, but this commit related with a Django`s version 1.10, I am using
 the 1.9.7 (if you see requirements.txt).

 The problem is in a field models.UUIDField, because with a field
 models.AutoField() all working properly (I am tested it)

 Thus, please explain me, how "Added support for "__" lookup in
 RelatedOnlyFieldList" is related with UUIDField

 Second, I had mistake in code (I corrected it in new commit)

 Instead of

 {{{
 qs = qs.prefetch_related('comment')
 }}}

 must be

 {{{
 qs = qs.prefetch_related('comments')
 }}}


 Thirdly
 In real projects I am using PostgreSQL, no SQLite. But, I think it is not
 have sense for this problem.

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

Re: [Django] #27154: Minor difference in behavior between CallableFalse/CallableTrue and False/True.

2016-08-30 Thread Django

#27154: Minor difference in behavior between CallableFalse/CallableTrue and
False/True.
--+
 Reporter:  tomchristie   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  1.10
 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 bmispelon):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 The change seems simple enough and I don't see any drawbacks to adding it.

 If we can make our users' lives easier, I'm +1 on it.

 If anyone is interested in tackling this, the
 `CallableFalse`/`CallableTrue` classes are defined in
 `django/utils/deprecation.py`.


 Once the change is made, I think we should also discuss backporting it.


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

Re: [Django] #27153: HttpResponseBase should check for valid HTTP status code

2016-08-30 Thread Django

#27153: HttpResponseBase should check for valid HTTP status code
-+-
 Reporter:  ryangallen   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by ryangallen):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Github PR: https://github.com/django/django/pull/7165

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

[Django] #27153: HttpResponseBase should check for valid HTTP status code

2016-08-30 Thread Django

#27153: HttpResponseBase should check for valid HTTP status code
--+
 Reporter:  ryangallen|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  HTTP handling |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  0
--+
 Currently, the HttpResponseBase class does not check for Type or Value
 Error on the HTTP status code. If a bad value such as a string is passed
 it, an exception is not thrown until it reaches:

 {{{
 File "django/http/utils.py", line 17, in conditional_content_removal
 if 100 <= response.status_code < 200 or response.status_code in (204,
 304):
 TypeError: unorderable types: int() <= str()
 }}}

 Proposed fix:
 - Valid status values in the form of a string should be coerced to an
 integer if possible.
 - Integer values less than 100 or greater than 599 should also be rejected
 based on [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html W3C
 Status Code Definitions RFC 2612]

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

[Django] #27154: Minor difference in behavior between CallableFalse/CallableTrue and False/True.

2016-08-30 Thread Django

#27154: Minor difference in behavior between CallableFalse/CallableTrue and
False/True.
--+
Reporter: tomchristie | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: contrib.auth |Version: 1.10
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 1 | UI/UX: 0
--+
Original raised as a ticket in REST framework:
https://github.com/tomchristie/django-rest-framework/issues/4439

Something that may confuse users calling `.is_authenticated`...

There's a slight difference in behavior between how the
CallableFalse/CallableTrue instances behave compare to how False/True
behave.

The Python boolean type happens to support the bitwise OR operator, and
its behavior in this case is exactly equivalent to the `or` operator. Eg.
`False | True` returns `True`

The backwards compat CallableFalse/CallableTrue instances do not support
this usage, and will fail with eg. `TypeError: unsupported operand type(s)
for |: 'instance' and 'bool'`

Their behavior is reasonable enough, and the user should really be using
the boolean `or` operator, but we might introduce slightly less friction
(ie don't raise a slightly opaque error message to the user) if we simply
support and allow the bitwise operator in the same way as the boolean
equivalents.

I'm probably a +0 on resolving this, as think it'd save a few folks a bit
of head banging. Certainly wouldn't dispute a `wontfix` categorization.

Tip for easy pickings folks: Should be resolvable by including an `__or__`
method on the CallableFalse/CallableTrue classes.

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

Re: [Django] #27098: Deprecate DatabaseIntrospection.get_indexes

2016-08-30 Thread Django

#27098: Deprecate DatabaseIntrospection.get_indexes
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  introspection db-| Triage Stage:  Accepted
  indexes|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"4c7bf83cde9f698cad019a9b808dbe45a832d9c3" 4c7bf83c]:
 {{{
 #!CommitTicketReference repository=""
 revision="4c7bf83cde9f698cad019a9b808dbe45a832d9c3"
 Refs #27097, #27098 -- Moved PostgreSQL index type introspection to
 get_constraints().
 }}}

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

Re: [Django] #27097: Add introspection for index type

2016-08-30 Thread Django

#27097: Add introspection for index type
-+-
 Reporter:  akki |Owner:  akki
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  introspection db-| Triage Stage:  Accepted
  indexes 1.11   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"4c7bf83cde9f698cad019a9b808dbe45a832d9c3" 4c7bf83c]:
 {{{
 #!CommitTicketReference repository=""
 revision="4c7bf83cde9f698cad019a9b808dbe45a832d9c3"
 Refs #27097, #27098 -- Moved PostgreSQL index type introspection to
 get_constraints().
 }}}

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

[Django] #27152: Comma-delimited servers list not supported in memcached caches `LOCATION`

2016-08-30 Thread Django

#27152: Comma-delimited servers list not supported in memcached caches 
`LOCATION`
-+
 Reporter:  edmorley |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Cache system)  |Version:  1.10
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Currently Django's memcached backends only support a semicolon delimited
 servers list in the cache config, such as:

 {{{
 CACHES = {
 'default': {
 'LOCATION': 'server1.foo.com;server2.foo.com',
 },
 }
 }}}

 This is because the backend
 
[https://github.com/django/django/blob/1.10/django/core/cache/backends/memcached.py#L16
 just does]:
 {{{
 self._servers = server.split(';')
 }}}

 However cloud memcached offerings such as Memcachier and Memcached Cloud
 typically use a comma-delimited list in the automatically set environment
 variable, eg:

 {{{
 MEMCACHIER_SERVERS='foo.us-east-5.heroku.prod.memcachier.com:11211,bar.us-
 east-5.heroku.prod.memcachier.com:11211'
 }}}

 Given that the caches `LOCATION` parameter contains only domain name and
 port (and not say passwords), it should never contain a comma - so we
 should be fine to also split on them too.

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

Re: [Django] #26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a type of a field is ForeignKey and value to_field is not pk (in my case it is UUID).

2016-08-30 Thread Django

#26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a
type of a field is ForeignKey and value to_field is not pk (in my case it
is UUID).
-+-
 Reporter:  setivolkylany|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Admin, ForeignKey,   | Triage Stage:
  models |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 After 815f4d206dfea41bdff167283c2cac43a71524ac, the sample project shows
 "Cannot find 'comment' on Utility object, 'comment' 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 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.491d53a331f85e031080b019d53f9bd8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27151: FK index created two times if referenced table PK is varchar

2016-08-30 Thread Django

#27151: FK index created two times if referenced table PK is varchar
-+--
 Reporter:  kkujawinski  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 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 timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Could you please check if the issue still exists on Django master?

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

Re: [Django] #23273: MigrationRecorder does not obey db_router allow_migrate rules

2016-08-30 Thread Django

#23273: MigrationRecorder does not obey db_router allow_migrate rules
+
 Reporter:  froomzy |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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 intgr):

 * cc: marti@… (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.61904701df2dfd8e1113a76952143438%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a type of a field is ForeignKey and value to_field is not pk (in my case it is UUID).

2016-08-30 Thread Django

#26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a
type of a field is ForeignKey and value to_field is not pk (in my case it
is UUID).
-+-
 Reporter:  setivolkylany|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Admin, ForeignKey,   | Triage Stage:
  models |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by setivolkylany):

 Replying to [comment:2 timgraham]:
 > What's the error? I can't reproduce a crash in 1.10, 1.9, or 1.8 but
 maybe I didn't reproduce it correctly. If you can put together a
 simplified sample project without any third-party dependencies, that makes
 the issue much easier to triage.

 I created mini-project for the Django`s Team

 https://bitbucket.org/setivolkylany/testdjango

 If you need more details, do not be shy and contact with 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 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.ff65cc49b445ccde76ba0bbb24778387%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27150: Wrong File object behavior if file object has no name attribute

2016-08-30 Thread Django

#27150: Wrong File object behavior if file object has no name attribute
--+--
 Reporter:  pacahon   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  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:  0 |UI/UX:  0
--+--

Comment (by pacahon):

 Hi.
 Sure, it makes sense. I'll try to investigate failed tests ASAP. Think
 it's the best place to begin.

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

Re: [Django] #27142: makemigrations fails on special database connections

2016-08-30 Thread Django

Comment (by sjoerdjob):

From my perspective, `makemigrations` would not really be the place to
check database consistency. Especially when trying to build a reusable
app, you should not have to know what database connection your app will be
used in.

I just tested this (somewhat superficially), but in Django 1.9.7 I can run
`makemigrations` without even having a database connection configured. The
minimum requirement seems to be that *if* there is a database configured,
the `ENGINE` field makes sense.

Django 1.10 raises the bar significantly (the bar is being lowered again a
bit, which I think is great!)
* All databases you configured need to have a `django_migrations` table
(or the ability to create one). (#27054)
* The `django_migrations` table needs to be readable. (#27141)
* The configured database must support enough of SQL to make sense of the
checks (#27142).
* The data in that table needs to be consistent with your project/app (I
expect), even though it might be a read-only connection to a database
"owned" by another Django project where you just want to have a "sneak
peak" into a specific table. (probably the issue I would have reported if
the `django_migrations` table in #27142 *was* readable).

Sure, consulting database routers might be some form of win, but how much
of a win? Will it solve all current problems, including the ones we
haven't found yet?

(During some investigation, I also found that Django 1.9.7 already
consults the database routers for some model-checks, for instance in
`_check_long_column_names`. If I were to write a reusable app, I think it
might be better to check all possible engines, and not just the ones
routed to.)

From what I have seen so far, I would kindly request that `makemigrations`
will stop checking database consistency, and make sure that no database
queries will be made. I think that would be the most pragmatic choice. To
me the question is: will it be removed in the 1.10.x series, or in 1.11?

[[remark: please don't take the above the wrong way. I understand that
this feature has been developed based on good intentions, and I really
appreciate the effort that has gone into creating and enhancing Django. I
am trying not to hurt anyone's feelings and hope the above does not come
off as such.]]

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

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

Re: [Django] #27150: Wrong File object behavior if file object has no name attribute

2016-08-30 Thread Django

#27150: Wrong File object behavior if file object has no name attribute
--+--
 Reporter:  pacahon   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  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:  0 |UI/UX:  0
--+--
Changes (by bmispelon):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Hi,

 As far as I can tell, `File.__bool__` is not documented but it does seem
 to be used internally and is somewhat tested (though maybe not directly):
 changing it to `return False` yields quite a few errors and failures in
 the test suite.


 Because of this lack of documentation, it's hard to tell if the behavior
 you're describing is a bug.

 I think it'd be worth it to:

 1) Document `File.__bool__` (both in the reference docs and in the
 docstring)
 2) Figure out if we can improve it by handling underlying files with no
 names as you suggest.


 What do you think?

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

[Django] #27151: FK index created two times if referenced table PK is varchar

2016-08-30 Thread Django

#27151: FK index created two times if referenced table PK is varchar
-+
 Reporter:  kkujawinski  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Migrations   |Version:  1.8
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Django version: 1.8.14


 '''Scenario 1. with creating index only'''

 1. Initial models:

 {{{
 class Foo(models.Model):
 guid = models.CharField(max_length=36, primary_key=True)


 class Bar(models.Model):
 key = models.ForeignKey(Foo, db_index=False)
 }}}



 2. Initial migration:



 {{{
 class Migration(migrations.Migration):

 dependencies = []

 operations = [
 migrations.CreateModel(
 name='Bar',
 fields=[
 ('id', models.AutoField(verbose_name='ID',
 serialize=False, auto_created=True, primary_key=True)),
 ],
 ),
 migrations.CreateModel(
 name='Foo',
 fields=[
 ('guid', models.CharField(max_length=36, serialize=False,
 primary_key=True)),
 ],
 ),
 migrations.AddField(
 model_name='bar',
 name='key',
 field=models.ForeignKey(to='myapp.Foo', db_index=False),
 ),
 ]

 }}}


 3. Changes in to model:


 {{{
 -key = models.ForeignKey(Foo, db_index=False)
 +key = models.ForeignKey(Foo, db_index=True)

 }}}


 4. Migration:



 {{{
 class Migration(migrations.Migration):

 dependencies = [
 ('myapp', '0001_initial'),
 ]

 operations = [
 migrations.AlterField(
 model_name='bar',
 name='key',
 field=models.ForeignKey(to='myapp.Foo'),
 ),
 ]

 }}}


 5. Applying migration logs:


 {{{
 Operations to perform:
   Apply all migrations: myapp
 Running migrations:
   Rendering model states... DONE
   Applying myapp.0002_auto_20160829_1936...[2016-08-29 19:37:55,385
 pid=11084] DEBUG| django.db.backends.schema | ALTER TABLE "myapp_bar"
 DROP CONSTRAINT "myapp_bar_key_id_1647a22de55ad985_fk_myapp_foo_id";
 (params [])
 [2016-08-30 11:26:19,228 pid=25347] DEBUG| django.db.backends.schema |
 ALTER TABLE "myapp_bar" DROP CONSTRAINT
 "myapp_bar_key_id_1647a22de55ad985_fk_myapp_foo_guid"; (params [])
 [2016-08-30 11:26:19,230 pid=25347] DEBUG| django.db.backends.schema |
 CREATE INDEX "myapp_bar_key_id_1647a22de55ad985_uniq" ON "myapp_bar"
 ("key_id"); (params [])
 [2016-08-30 11:26:19,230 pid=25347] DEBUG| django.db.backends.schema |
 CREATE INDEX "myapp_bar_key_id_1647a22de55ad985_uniq" ON "myapp_bar"
 ("key_id"); (params [])
 [2016-08-30 11:26:19,235 pid=25347] DEBUG| django.db.backends.schema |
 ALTER TABLE "myapp_bar" ADD CONSTRAINT
 "myapp_bar_key_id_1647a22de55ad985_fk_myapp_foo_guid" FOREIGN KEY
 ("key_id") REFERENCES "myapp_foo" ("guid") DEFERRABLE INITIALLY DEFERRED;
 (params [])
 [2016-08-30 11:26:19,235 pid=25347] DEBUG| django.db.backends.schema |
 ALTER TABLE "myapp_bar" ADD CONSTRAINT
 "myapp_bar_key_id_1647a22de55ad985_fk_myapp_foo_guid" FOREIGN KEY
 ("key_id") REFERENCES "myapp_foo" ("guid") DEFERRABLE INITIALLY DEFERRED;
 (params [])
 [2016-08-30 11:26:19,237 pid=25347] DEBUG| django.db.backends.schema |
 CREATE INDEX "myapp_bar_key_id_1647a22de55ad985_like" ON "myapp_bar"
 ("key_id" varchar_pattern_ops); (params [])
 [2016-08-30 11:26:19,237 pid=25347] DEBUG| django.db.backends.schema |
 CREATE INDEX "myapp_bar_key_id_1647a22de55ad985_like" ON "myapp_bar"
 ("key_id" varchar_pattern_ops); (params [])
  OK


 }}}

 6. Indexes created in postgres database


 {{{
 SELECT i.relname as indname, i.relowner as indowner,
 idx.indrelid::regclass, am.amname as indam, idx.indkey,
ARRAY(SELECT pg_get_indexdef(idx.indexrelid, k + 1, true) FROM
 generate_subscripts(idx.indkey, 1) as k
  ORDER BY k) as indkey_names, idx.indexprs IS NOT NULL as
 indexprs, idx.indpred IS NOT NULL as indpred,
idx.indisunique
 FROM   pg_index as idx JOIN pg_class as i ON i.oid = idx.indexrelid JOIN
 pg_am as am ON i.relam = am.oid
 WHERE  idx.indrelid::regclass='myapp_bar'::regclass;

 indname | indowner | indrelid  | indam |
 indkey | indkey_names | indexprs | indpred | indisunique
 
+--+---+---++--+--+-+-
  myapp_bar_key_id_1647a22de55ad985_like |16384 | myapp_bar | btree | 2
 | {key_id} | f| f   | f
  myapp_bar_key_id_1647a22de55ad985_uniq |16384 | myapp_bar | btree | 2
 | {key_id} | f| f   | f
  myapp_bar_pkey |16384 | myapp_bar | btree | 1
 | {id} | f| f   | t


 }}}

 '''Scenario 2. indexes created in first

[Django] #27150: Wrong File object behavior if file object has no name attribute

2016-08-30 Thread Django

#27150: Wrong File object behavior if file object has no name attribute
--+
 Reporter:  pacahon   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Other)  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 [https://docs.djangoproject.com/en/1.10/ref/files/file/#the-file-class
 django.core.files.base.File] supports file-like objects (synonym to file
 object in python glossary) and in fact can't rely on additional `name`
 attribute, but in current implementation of `__bool__` method it does:

 {{{
 def __bool__(self):
 return bool(self.name)
 }}}

 For example, until `tempfile.SpooledTemporaryFile` isn't large enough to
 have been written to disk, his `name` attribute is `None` and `if`
 statement will return False.
 {{{
 import tempfile
 from django.core.files.base import File
 python_file_like_object = tempfile.SpooledTemporaryFile()
 file_obj = File(python_file_like_object)  # name keyword is None by
 default
 if file_object:  # Falsy, because python_file_like_object.name is None
 print("42")
 }}}
 The same behavior with streams (BytesIO, StringIO).
 Maybe `__bool__` method should rely on `self.file` attribute to avoid this
 behavior?

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

Re: [Django] #27149: Filtering with generic relation

2016-08-30 Thread Django

#27149: Filtering with generic relation
-+-
 Reporter:  MikiSoft |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by MikiSoft):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> The following function is used for filtering by generic relation (and
> also by one column in the model where it is) which isn't natively
> supported by Django.
>
> {{{
> def generic_rel_filter(model, target, column, id):
> return model.objects.extra(where=['''
> {app_label}_{model}.id in (select object_id
> from {app_label}_{target}
> where content_type_id = (select id from django_content_type where
> model = '{model}')
> and {column} =
> {id})'''.format(app_label=os.path.basename(os.path.dirname(__file__)),
> model=model.__name__.lower(), target=target, column=column, id=id)])
> }}}
>
> ''Example:'' If I have Event and Like model, and the second one has
> generic relation to the first one (i.e. it has `content_type`,
> `object_id` and `content_object` fields), then if I want to get all
> events which current user liked, I would just make this call in a view:
> `generic_rel_filter(Event, 'like', 'person', self.request.user.pk)`
>
> '''Note that this function isn't intended to be used with user specified
> parameters, otherwise it's prone to SQL injection attacks.'''

New description:

 The following function is used for filtering by generic relation (and also
 by one column in the model where it is) which isn't natively supported by
 Django.

 {{{
 def generic_rel_filter(model, target, column, id):
 return model.objects.extra(where=['''
 {app_label}_{model}.id in (select object_id
 from {app_label}_{target}
 where content_type_id = (select id from django_content_type where
 model = '{model}')
 and {column} =
 {id})'''.format(app_label=os.path.basename(os.path.dirname(__file__)),
 model=model.__name__.lower(), target=target, column=column, id=id)])
 }}}

 ''Example:'' If I have Event and Like model, and the second one has
 generic relation to the first one (i.e. it has `content_type`, `object_id`
 and `content_object` fields), then if I want to get all events which
 current user liked, I would just make this call in a view:
 `generic_rel_filter(Event, 'like', 'person', self.request.user.pk)`

 '''Note that this function isn't intended to be used with user specified
 parameters, otherwise it's prone to SQL injection attacks.'''

 P.S. It can be done with ORM but then it would go with three queries,
 which is much slower than the method above (which uses only one query to
 do the same):
 
`Event.objects.filter(pk__in=Like.objects.filter(content_type=ContentType.objects.get(model='event'),
 person=self.request.user).values_list('object_id', flat=True))`

--

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

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

[Django] #27149: Filtering with generic relation

2016-08-30 Thread Django

#27149: Filtering with generic relation
--+
 Reporter:  MikiSoft  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:
 Severity:  Normal|   Keywords:  QuerySet.extra
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The following function is used for filtering by generic relation (and also
 by one column in the model where it is) which isn't natively supported by
 Django.

 {{{
 def generic_rel_filter(model, target, column, id):
 return model.objects.extra(where=['''
 {app_label}_{model}.id in (select object_id
 from {app_label}_{target}
 where content_type_id = (select id from django_content_type where
 model = '{model}')
 and {column} =
 {id})'''.format(app_label=os.path.basename(os.path.dirname(__file__)),
 model=model.__name__.lower(), target=target, column=column, id=id)])
 }}}

 ''Example:'' If I have Event and Like model, and the second one has
 generic relation to the first one (i.e. it has `content_type`, `object_id`
 and `content_object` fields), then if I want to get all events which
 current user liked, I would just make this call in a view:
 `generic_rel_filter(Event, 'like', 'person', self.request.user.pk)`

 '''Note that this function isn't intended to be used with user specified
 parameters, otherwise it's prone to SQL injection attacks.'''

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

59 matches

Mail list logo