date:20141015

Re: [Django] #21733: @python_2_unicode_compatible causes infinite recursion when module imported more than once

2014-10-15 Thread Django

#21733: @python_2_unicode_compatible causes infinite recursion when module
imported
more than once
---+--
Reporter: ntucker|Owner: nobody
Type: Bug| Status: closed
Component: Utilities | Version: 1.6
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 |UI/UX: 0
---+--

Comment (by hwkns):

Thanks for tracking down the cause of this! I wanted to stop the double
imports from happening and be able to use relative imports where possible,
so I did some more digging and found this SO post:
http://stackoverflow.com/questions/23527435/python-path-not-consistent-in-
django-double-module-imports

I still had an `__init__.py` in my project root directory -- deleting that
file stopped the double imports and thus stopped the infinite recursion
for me.

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

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

Re: [Django] #23659: Lost annotation ordering with values_list() and annotate()

2014-10-15 Thread Django

#23659: Lost annotation ordering with values_list() and annotate()
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Accepted => Ready for checkin


Comment:

 Except the two flake8 warnings the patch is RFC.

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

Re: [Django] #23657: Migrations framework doesn't properly handle factory-generated base classes.

2014-10-15 Thread Django

#23657: Migrations framework doesn't properly handle factory-generated base
classes.
+--
 Reporter:  jfialkoff   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:  wontfix
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by carljm):

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


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

Re: [Django] #23657: Migrations framework doesn't properly handle factory-generated base classes.

2014-10-15 Thread Django

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

Comment:

This strikes me as an atypical edge-case where the only feasible answer is
"modify the generated migration." Migration files are editable Python code
for a reason; autodetection will never handle everything someone might do.

In this case, I don't think it is possible for the autodetector to handle
this the way you want - it can't know via runtime introspection that your
base class was created via factory. (Well, with `__qualname__` in Python 3
it might be possible, but we have to maintain Python 2 compatibility for
quite some time still).

Closing wontfix; if any other core dev with more hands-on migration
experience disagrees, feel free to reopen.

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

Re: [Django] #23660: pull sort_dependencies helper into core

2014-10-15 Thread Django

#23660: pull sort_dependencies helper into core
--+
 Reporter:  collinanderson|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Serialization)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Loic Bistuer ):

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


Comment:

 In [changeset:"a6a8268d1974778d93e112c739b4cf0564b7e043"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a6a8268d1974778d93e112c739b4cf0564b7e043"
 Fixed #23660 -- Moved sort_dependencies to core.
 }}}

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

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

Re: [Django] #19508: Implement URL decoding according to RFC 3987

2014-10-15 Thread Django

#19508: Implement URL decoding according to RFC 3987
-+-
 Reporter:  aaugustin|Owner:  loic
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  HTTP handling|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Loic Bistuer ):

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


Comment:

 In [changeset:"10b17a22bec2eaf44c3315614aea87c127caee46"]:
 {{{
 #!CommitTicketReference repository=""
 revision="10b17a22bec2eaf44c3315614aea87c127caee46"
 Fixed #19508 -- Implemented uri_to_iri as per RFC.

 Thanks Loic Bistuer for helping in shaping the patch and Claude Paroz
 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/067.2141e681074b1ae917c4c7f2269603a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23659: Lost annotation ordering with values_list() and annotate()

2014-10-15 Thread Django

#23659: Lost annotation ordering with values_list() and annotate()
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 Issue addressed, test suite OK.

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

Re: [Django] #19508: Implement URL decoding according to RFC 3987

2014-10-15 Thread Django

#19508: Implement URL decoding according to RFC 3987
-+-
 Reporter:  aaugustin|Owner:  loic
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  HTTP handling|   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * stage:  Accepted => Ready for checkin


Comment:

 Looks good, thanks!

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

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

Re: [Django] #23583: makemessages for javascript no longer works

2014-10-15 Thread Django

#23583: makemessages for javascript no longer works
--+--
 Reporter:  nijel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Translations  |  Version:  1.7
 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 blodone):

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


Old description:

> When using manage.py makemessages -d djangojs, it no longer works (for
> me) as makemessages now completely ignores media and static dirs, what's
> place where javscript is usually stored. This has been introduced as fix
> for issue #23010.

New description:

 makemessages ignores any in-app paths that begin with static because of
 this line:
 
https://github.com/django/django/blob/master/django/core/management/commands/makemessages.py#L233

 it should ignore something like "/*" but not "*"

 reproducible:
 https://github.com/blodone/django_static_broken

--

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

Re: [Django] #18558: Supply `url` property to `HttpResponseRedirect` and `HttpResponsePermanentRedirect`

2014-10-15 Thread Django

#18558: Supply `url` property to `HttpResponseRedirect` and
`HttpResponsePermanentRedirect`
-+-
 Reporter:  coolRR   |Owner:  claudep
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 `HttpResponseRedirect(content='Foo')` is not valid, the `redirect_to`
 parameter being mandatory. I think that the proper answer would be not to
 use a plain `HttpResponse` for an HTTP redirection. If you have a valid
 use case for using an `HttpResponse(status=302)` instead of an
 `HttpResponseRedirect`, please open a new ticket (where you can reference
 this one).

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

Re: [Django] #23647: Auto-generated PK field name is not easily configurable

2014-10-15 Thread Django

#23647: Auto-generated PK field name is not easily configurable
-+-
 Reporter:  systemsoverload  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by systemsoverload):

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


Comment:

 I think that this is enough of a reason to close this ticket as erroneous.
 I'm not as up to snuff on meta magicks as I should be apparently, thanks
 charettes!

 Replying to [comment:4 charettes]:
 > I also agree that this doesn't warrant an additional setting.
 >
 > You can already achieve what you're after with a `ModelBase` subclass
 with no refactoring.
 >
 > {{{#!python
 > from django.db import models
 >
 > class AutoPKModelBase(models.ModelBase):
 > def __new__(cls, name, bases, attrs):
 > pk_name = "%s_id" % name.lower()
 > attrs[pk_name] = models.AutoField(primary=True)
 > return super(AutoPKModelBase, cls).__new__(cls, name, bases,
 attrs)
 >
 > class MyModel(metaclass=AutoPKModelBase, models.Model):
 > pass
 > }}}

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

Re: [Django] #23659: Lost annotation ordering with values_list() and annotate()

2014-10-15 Thread Django

#23659: Lost annotation ordering with values_list() and annotate()
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by charettes):

 * stage:  Ready for checkin => Accepted


Comment:

 Loïc raised an issue on the PR that must be addressed before merging.

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

Re: [Django] #23422: Cannot add Permission to Group in data migration

2014-10-15 Thread Django

#23422: Cannot add Permission to Group in data migration
+--
 Reporter:  tjwalch |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:  wontfix
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by carljm):

 If using `ContentType.objects.get_for_model` is not possible, perhaps
 calling `django.contrib.auth.management.create_permissions(...)` in the
 migration would 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/065.fde7ca17ddd0057ee1e41b4c3755198d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23661: Site cache doesn't cache in a per-database basis

2014-10-15 Thread Django

#23661: Site cache doesn't cache in a per-database basis
---+
 Reporter:  Kronuz |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The cache for `Site`  (`SITE_CACHE`) should cache site objects for the
 database the object comes from. If there is a router in place and the
 current site is retrieved from one database, a second call for getting the
 current site from a different database will return the wrong object for
 that database.

 Instead of using `SITE_CACHE` the way it's currently done, I propose using
 the same caching scheme as the one used in `ContentType`'s `_cache`.

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

Re: [Django] #23660: pull sort_dependencies helper into core

2014-10-15 Thread Django

#23660: pull sort_dependencies helper into core
--+
 Reporter:  collinanderson|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Serialization)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by charettes):

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

Re: [Django] #23660: pull sort_dependencies helper into core

2014-10-15 Thread Django

#23660: pull sort_dependencies helper into core
-+-
 Reporter:  collinanderson   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Core |   Resolution:
  (Serialization)| Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by collinanderson):

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


Comment:

 https://github.com/django/django/pull/3372

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

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

[Django] #23660: pull sort_dependencies helper into core

2014-10-15 Thread Django

#23660: pull sort_dependencies helper into core
--+
 Reporter:  collinanderson|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Core (Serialization)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The migration code is importing a `sort_dependencies` helper function from
 `core.management.commands.dumpdata`.

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

Re: [Django] #18558: Supply `url` property to `HttpResponseRedirect` and `HttpResponsePermanentRedirect`

2014-10-15 Thread Django

#18558: Supply `url` property to `HttpResponseRedirect` and
`HttpResponsePermanentRedirect`
-+-
 Reporter:  coolRR   |Owner:  claudep
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by tevans):

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


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

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

Re: [Django] #18558: Supply `url` property to `HttpResponseRedirect` and `HttpResponsePermanentRedirect`

2014-10-15 Thread Django

#18558: Supply `url` property to `HttpResponseRedirect` and
`HttpResponsePermanentRedirect`
-+-
 Reporter:  coolRR   |Owner:  claudep
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by tevans):

 Hi, I think this change is incorrect.

 It makes HttpResponse(status=302, content='Foo') behave differently to
 HttpResponseRedirect(content='Foo').

 This can be seen by using the test client, and asking it to follow
 redirects. It will attempt to access the url property on the response, but
 because the response is a redirect that is not derived from
 HttpResponseRedirectBase, this will fail.

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

Re: [Django] #9893: Filename + path length greater than 100 truncated on database insertion in Core.Storage

2014-10-15 Thread Django

#9893: Filename + path length greater than 100 truncated on database insertion 
in
Core.Storage
-+-
 Reporter:  Refefer  |Owner:
 Type:  Bug  |  pavel_shpilev
Component:  File |   Status:  assigned
  uploads/storage|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  storage, filename| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * cc: charettes (added)
 * needs_better_patch:  0 => 1
 * needs_docs:  0 => 1


Comment:

 pavel_shpilev put together [https://github.com/django/django/pull/3369 a
 PR] based on ticket:9893#comment:1 that still requires some adjustments.

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

Re: [Django] #23658: Provide the password to PostgreSQL from "dbshell" command

2014-10-15 Thread Django

Comment (by etanol):

The `mysql` command clobbers the password given in the command line, so
I'm not sure if the MySQL backend needs to change it. Clobbering the
process environment is also possible, just as hacky as doing it in `argv`,
however the password length is still ''leaked''. PostgreSQL would need a
patch for that, though.

On a side note, I just realized that there's no need to copy the
`os.environment` dictionary because the page table is going to be wiped
out by `os.execvp` anyway.

And finally, in the MySQL backend, the use of `os.system` on Windows can
also be removed. But that probably needs a separate patch.

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

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

Re: [Django] #23659: Lost annotation ordering with values_list() and annotate()

2014-10-15 Thread Django

#23659: Lost annotation ordering with values_list() and annotate()
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * version:  1.7 => master
 * stage:  Unreviewed => Ready for checkin


Comment:

 It's also what I would expect from `values_list()` and `annotate()`
 chaining.

 Patch LGTM, CI failures look unrelated.

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

Re: [Django] #23659: Lost annotation ordering with values_list() and annotate()

2014-10-15 Thread Django

#23659: Lost annotation ordering with values_list() and annotate()
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/3371

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

[Django] #23659: Lost annotation ordering with values_list() and annotate()

2014-10-15 Thread Django

#23659: Lost annotation ordering with values_list() and annotate()
-+-
   Reporter:  claudep|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.7
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 When I'm aggregating with `values_list()` and then annotate with a list of
 clauses, I'd expect the annotate *args ordering to be respected in the
 resulting lists. Unfortunately, `annotate()` args ordering is currently
 discarded because all annotations parameters are consolidated in a plain
 `dict`.

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

Re: [Django] #23637: Remove TUX from static-files and modwsgi docs

2014-10-15 Thread Django

#23637: Remove TUX from static-files and modwsgi docs
--+
 Reporter:  collinanderson|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Collin Anderson ):

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


Comment:

 In [changeset:"1b2debe89684724f0617bb89aa49cb70273ab0f1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1b2debe89684724f0617bb89aa49cb70273ab0f1"
 Fixed #23637 -- Removed TUX, lighttpd, and Cherokee as common.
 }}}

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

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

Re: [Django] #23637: Remove TUX from static-files and modwsgi docs

2014-10-15 Thread Django

#23637: Remove TUX from static-files and modwsgi docs
--+
 Reporter:  collinanderson|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Loic Bistuer ):

 In [changeset:"4443c6f6d8e481db8142e79391ad0b65ebcf46e3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="4443c6f6d8e481db8142e79391ad0b65ebcf46e3"
 Merge pull request #3370 from collinanderson/ticket_23637

 Fixed #23637 -- Removed TUX, lighttpd, and Cherokee as common.
 }}}

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

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

Re: [Django] #23637: Remove TUX from static-files and modwsgi docs

2014-10-15 Thread Django

#23637: Remove TUX from static-files and modwsgi docs
--+
 Reporter:  collinanderson|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by collinanderson):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/3370

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

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

Re: [Django] #23658: Provide the password to PostgreSQL from "dbshell" command

2014-10-15 Thread Django

#23658: Provide the password to PostgreSQL from "dbshell" command
-+-
 Reporter:  etanol   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  postgresql dbshell   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by loic):

 * cc: loic (added)
 * needs_better_patch:  0 => 1
 * version:  1.7 => master
 * easy:  1 => 0
 * needs_docs:  0 => 1
 * ui_ux:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 +1 for this approach, marking as accepted.

 From my understanding MySQL support the `MYSQL_PWD` env var, wouldn't that
 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/064.4df221159fc22d7a34a41b52235ab3ac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23615: Naming a model Check causes Django's check framework to fail with an exception

2014-10-15 Thread Django

#23615: Naming a model Check causes Django's check framework to fail with an
exception
--+
 Reporter:  bramd |Owner:  zedr
 Type:  Bug   |   Status:  new
Component:  Core (System checks)  |  Version:  1.7
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by collinanderson):

 * severity:  Normal => Release blocker


Comment:

 It seems like we're treating this like release blocker.

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

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

Re: [Django] #23658: Provide the password to PostgreSQL from "dbshell" command

2014-10-15 Thread Django

#23658: Provide the password to PostgreSQL from "dbshell" command
-+-
 Reporter:  etanol   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  postgresql dbshell   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by aaugustin):

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


Comment:

 Duplicate of #19893 and #7554, which was closed as wontfix, but I'm not
 opposed to reconsidering since the question comes up regularly.

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

[Django] #23658: Provide the password to PostgreSQL from "dbshell" command

2014-10-15 Thread Django

#23658: Provide the password to PostgreSQL from "dbshell" command
--+
 Reporter:  etanol|  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:  postgresql
 Triage Stage:  Unreviewed|  dbshell
Easy pickings:  1 |  Has patch:  1
  |  UI/UX:  1
--+
 With the PostgreSQL Django backend, if the database configuration defines
 a password, it is not used by the "dbshell" command.  Unlike the "mysql"
 command, the "psql" command accepts the password through the process
 environment.  It would be a more uniform experience if the PostgreSQL
 driver behaved the same.

 Also note from the attached patch that "os.execvpe()" also works on
 Windows, so there's no need to distinguish between the two systems.

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

Re: [Django] #23449: Saving models with unsaved ForeignKey

2014-10-15 Thread Django

#23449: Saving models with unsaved ForeignKey
-+-
 Reporter:  pjrobertson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by coder9042):

 @pjrobertson

 I think you have got the answer to your question, thanks to @tchaumeny and
 @aaugustin.

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

Re: [Django] #23449: Saving models with unsaved ForeignKey

2014-10-15 Thread Django

Comment (by aaugustin):

Previously, running `b.a = a` where `a` is an unsaved model instance was
silently ignored. Not raising an error was a data loss bug.

The reporter asks to delay that error until one tries saving the model,
which I considered at the time and rejected, because:

- It's more common to save the model instances you create than throw them
away; if you don't intend saving something to the database, there's no
point in using Django models;
- It's better to raise an error at the point where there's (likely) a
mistake in the code than at an unrelated point later on;
- The proposal would be awfully complicated to implement properly.

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

Re: [Django] #23449: Saving models with unsaved ForeignKey

2014-10-15 Thread Django

#23449: Saving models with unsaved ForeignKey
-+-
 Reporter:  pjrobertson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by tchaumeny):

 I'd rather use something like this which makes the code more explicit :

 {{{
 mods = []
 for xml_element in xml.findall('item'):
  a = ModelA(name=xml_element.findtext('name')) # and other things
  b = ModelB(name='me')
  mods.append((a, b))

 # save the values_to_save, discard the rest
 for a, b in mods:
 if ...some condition...:
 a.save()
 b.a = a
 b.save()
 }}}

 However, I agree that if assigning an unsaved instance of `ModelA` to
 `b.a` was allowed before and no longer is (do I understand correctly ?),
 that might break some code...

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

Re: [Django] #23546: callproc **kwargs or *args parameter

2014-10-15 Thread Django

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

Comment:

Replying to [comment:7 shaib]:
> Hi,
>
> I made some notes on the PR. Additionally, documentation needed. I
suggested making the feature more general, less Oracle-specific, but even
if this path is not taken, the new behavior needs to be documented.
Currently, callproc is not documented at all, which is a shame, but
forgivable considering that the function is as defined in PEP 249;
deviating from the PEP justifies adding explicit documentation, probably
in `docs/topics/db/sql.txt`; whether or not that is done, the addition
should be mentioned in the release notes (`docs/releases/1.8.txt`).

Thanks for your detailed comments. New commit pushed. I also replied your
comments on github.

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

Re: [Django] #23651: fixtures.tests.FixtureLoadingTests.test_loading_and_dumping fails with Python 3

2014-10-15 Thread Django

#23651: fixtures.tests.FixtureLoadingTests.test_loading_and_dumping fails with
Python 3
-+-
 Reporter:  rhertzog |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.7
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Claude Paroz ):

 In [changeset:"da0ebe39f6ed1edc4043c97f6fd7e6872ba86508"]:
 {{{
 #!CommitTicketReference repository=""
 revision="da0ebe39f6ed1edc4043c97f6fd7e6872ba86508"
 [1.7.x] Fixed #23651 -- Isolated non-existent fixture tests

 Previous versions of the tests were buggy, as initial_data.json
 did exist and the test wasn't failing. It was finally failing on
 Python 3.4.2.
 Thanks Raphaël Hertzog for the report (and Debian bug #765117
 contributors).
 Backport of 7a893ee771 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/066.99738f84f195285cb255c80d4c1cb848%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23651: fixtures.tests.FixtureLoadingTests.test_loading_and_dumping fails with Python 3

2014-10-15 Thread Django

#23651: fixtures.tests.FixtureLoadingTests.test_loading_and_dumping fails with
Python 3
-+-
 Reporter:  rhertzog |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.7
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"7a893ee77171d6cc37ffd40d67af6161633235e0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7a893ee77171d6cc37ffd40d67af6161633235e0"
 Fixed #23651 -- Isolated non-existent fixture tests

 Previous versions of the tests were buggy, as initial_data.json
 did exist and the test wasn't failing. It was finally failing on
 Python 3.4.2.
 Thanks Raphaël Hertzog for the report (and Debian bug #765117
 contributors).
 }}}

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

Re: [Django] #23640: StaticLiveServerTestCase does not properly respect data migrations

2014-10-15 Thread Django

#23640: StaticLiveServerTestCase does not properly respect data migrations
-+-
 Reporter:  eldamir  |Owner:  gchp
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.7
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  data migration,  | Triage Stage:  Accepted
  functional tests   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by eldamir):

 Thank you kindly for the last two comments. My tests now run as expected
 after setting


 {{{
 serialized_rollback = True
 }}}


 and

 {{{
 available_apps = ['']
 }}}

 Is there a note of these settings in the documentation? Maybe there should
 be. It is not something I would have found myself. Thanks for your assist!

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

38 matches

Mail list logo