date:20150127

Re: [Django] #13666: Updates with F objects on decimal fields raise MySQL warnings

2015-01-27 Thread Django

* cc: josh@… (added)
* version: 1.2 => 1.7

Comment:

The Django ORM definitely needs to use CAST with MySQL. Otherwise, this
bug may manifest randomly on various architectures.

Read this on MySQL Type Conversion:
''"""Furthermore, the conversion from string to floating-point and from
integer to floating-point do not necessarily occur the same way. The
integer may be converted to floating-point by the CPU, whereas the string
is converted digit by digit in an operation that involves floating-point
multiplications.

''The results shown will vary on different systems, and can be affected by
factors such as computer architecture or the compiler version or
optimization level. One way to avoid such problems is to use CAST() so
that a value is not converted implicitly to a float-point number:"""

[http://dev.mysql.com/doc/refman/5.6/en/type-conversion.html]

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

Re: [Django] #24235: Deprecate is_usable attribute on template loaders?

2015-01-27 Thread Django

#24235: Deprecate is_usable attribute on template loaders?
--+
 Reporter:  prestontimmons|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  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 aaugustin):

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


Comment:

 Yes.

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

Re: [Django] #24225: KeyError when migrating in 1.8a1/master@728b6fd (does not occur in 1.7.3)

2015-01-27 Thread Django

Comment (by hheimbuerger):

Unfortunately, I don't. I extracted the suspected issue I described above
into a new project, but that works fine. So there must be one more factor
I'm missing to trigger the issue. Really reducing my actual big project
down to the cause would take me days, which I unfortunately don't have.
Besides, I wouldn't even know where to start.

I still can attach the debugger, so if you can tell me where to start
inspecting the state at the point in time the exception was raised, I can
do that.

Other than that, I now just removed those two aforementioned `AddField`
and `RemoveField` instructions from my old migrations (they are really
old, the two very first migrations—so while I'm sure editing old
migrations by hand is not a best practice, it shouldn't break anything in
this case) and that fixed it for my app.

So feel free to close as 'cannot reproduce'.

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

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

Re: [Django] #6785: QuerySet.get() should only attempt to fetch a limited number of rows

2015-01-27 Thread Django

#6785: QuerySet.get() should only attempt to fetch a limited number of rows
-+-
 Reporter:  deadwisdom   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 I'm beginning to think committing this was a mistake. Correctly working
 code shouldn't face this issue, so why optimize it. Removing this from 1.8
 is ok for me.

 One possibility is to use the iterator() method, so we don't turn all the
 rows to model instances.

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

Re: [Django] #24218: Use sub-query in ORM when distinct and order_by columns do not match

2015-01-27 Thread Django

#24218: Use sub-query in ORM when distinct and order_by columns do not match
-+-
 Reporter:  miki725  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  subquery distinct| Triage Stage:  Accepted
  order_by   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 We need to go wirh option 2, specifically the solution where the inner and
 outer query have differen order by clauses. This way you can order the
 results the way you want, yet pick the distinct element as you wish.

 I'vw thought of a solution something like this
 {{{
 qs.distict('foo').order_by('foo').barrier().order_by('bar')
 }}}
 The idea is that the barrier call effectively forces everything left of
 the call to go into subquery, then things after the barrier go into outer
 query. This construct would be hugely useful in other use cases, 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/065.29bab7d17ea7c26170d6a10a7575ed33%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24218: Use sub-query in ORM when distinct and order_by columns do not match

2015-01-27 Thread Django

#24218: Use sub-query in ORM when distinct and order_by columns do not match
-+-
 Reporter:  miki725  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  subquery distinct| Triage Stage:  Accepted
  order_by   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by miki725):

 Thank you for such quick responses!

   This business of unpredictable results is what makes me most
 uncomfortable with the patch.

 I completely agree with that statement. Let me explain my-use case and
 then maybe possible solutions.

 {{{#!python
 class ModelFoo(models.Model):
 bars = models.ManyToManyField(ModelBar, related_name='foos')

 class ModelBar(models.Model):
 latlon = models.PointField(spatial_index=True)

 # query foos where they have related bars within certain distance
 # and sort by increasing distance
 (ModelFoo.objects
 # filter by distance
 .filter(bars__latlon__distance_lte=(point, Distance(mi=1)))
 # add distance annotation
 .distance(point, field_name='bars__latlon')
 # sort by distance
 .extra(order_by=['distance'])
 # distinct foos
 .distinct('id'))
 }}}

 The reason I needed distinct here is because otherwise whenever foo had
 multiple bars, I would get duplicate foo models due to the join. Since in
 my case I simply used bars for filtering foos, I didnt care about
 "unpredictable" order at all since I only cared about foos. As for
 sorting, initially I also thought that {{{ORDER BY}}} should be inside the
 inner query and {{{DISTINCT}}} on the outer query however for some reason
 when I did that, foos were not sorted by distance anymore.

 This however is just my use-case and I do see how this can cause issues in
 other scenarios since you cannot be sure what comes first in the
 {{{DISTINCT}}}.

 Here are some possible solutions:

 1. It seems that whenever a pattern of many-guys is used to filter single
 guys on one/many-to-many and sorting is required, this pattern might be
 useful. So maybe this functionality should only be enabled in those cases.

 2. What about if this behavior will be configurable? More specifically
 what about if the user will be able to control:

 * explicitly enable this functionary since otherwise Django cannot
 guarantee data integrity for all use-cases. This will force the user to
 explicitly acknowledge they want to do this hence eliminating the burden
 from Django to always provide data-integrity (and explain all the cases
 when it is not provided).
 * what goes to inner and outer subquery ({{{ORDER BY}}} or
 {{{DISTINCT}}}). Maybe even allow {{{ORDER BY}}} in both queries. So the
 user will pick some sort columns for both inner and outer query hence
 solving "predictability" of {{{DISTINCT}}} and allowing to sort overall
 results.

 I do like the idea of making these things customizable however not sure
 what would be an API to do those customizations. Is there precedent like
 that in Django ORM for query customizations?

 3. Perhaps the right solution is try not to solve my particular use-case
 but provide a more generic solution to use nested queries. Maybe use API
 something like:

 {{{#!python
 Model.objects.nested(
 Model.objects.filter(...).distinct(...).order_by(...)  # inner
 ).order_by(...)  # outer
 }}}

 Let me know your thoughts.

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

Re: [Django] #24233: group-by column construction is broken

2015-01-27 Thread Django

#24233: group-by column construction is broken
-+-
 Reporter:  megatrump|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 jarshwah):

 * status:  new => closed
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => wontfix
 * stage:  Unreviewed => Accepted


Comment:

 Yes, I believe this change was introduced with this PR
 https://github.com/django/django/pull/3669, but it may have been another.
 Grouping was pretty broken when using complicated expressions, because the
 backing columns were being added to the GROUP BY rather than the entire
 expression. It was lucky you were getting the right results.

 Now, the reason this is failing for you now, is because you're effectively
 writing RawSQL (there's a private expression type for this), without any
 of the benefits of new expressions. You may as well be writing `.extra()`
 calls. To fully leverage the power of expressions, you should use the
 smaller types to build up bigger ones. Expressions know that if they
 reference an aggregate, then they shouldn't be added to the group by
 clause. But you've just stuck a raw SUM expression into the roi
 calculation, and Django can't know that it's now referencing an aggregate.

 I've replicated (mostly..) your query only using full expressions. I
 cheated with a couple (using Func(function='..')) rather than building out
 the types fully, but they'll serve for now. I've broken each part down
 into logical chunks, and have printed the underlying query at each stage
 to make this easier to follow.

 First, annotate with the day of week. Annotate can do everything extra can
 do with regards to adding columns to the select list:

 {{{
 In [30]: qs = Costing.objects.annotate(dow=Func(F('ts'), Value('D'),
 function='TO_CHAR')).values('dow')

 In [31]: print(qs.query)
 SELECT TO_CHAR("scratch_costing"."ts", D) AS "dow" FROM "scratch_costing"
 }}}

 Next, add the aggregates we're interested in:

 {{{
 In [32]: qs = qs.annotate(sum_cost=Sum('cost'), sum_rev=Sum('rev'))

 In [33]: print(qs.query)
 SELECT TO_CHAR("scratch_costing"."ts", D) AS "dow",
 SUM("scratch_costing"."cost") AS "sum_cost", SUM("scratch_costing"."rev")
 AS "sum_rev" FROM "scratch_costing" GROUP BY
 TO_CHAR("scratch_costing"."ts", D)
 }}}

 Now, the ROI calculation. Note, this could be improved by using
 [https://docs.djangoproject.com/en/dev/ref/models/conditional-expressions/
 Case/When expressions]

 {{{
 In [34]: qsroi = qs.annotate(roi=Func( Coalesce(F('sum_rev') /
 Coalesce('sum_cost', Value(0)), Value(0)) , Value(2), function='ROUND',
 output_field=FloatField()))

 In [35]: print(qsroi.query)
 SELECT TO_CHAR("scratch_costing"."ts", D) AS "dow",
 SUM("scratch_costing"."cost") AS "sum_cost", SUM("scratch_costing"."rev")
 AS "sum_rev", ROUND(COALESCE((SUM("scratch_costing"."rev") /
 COALESCE(SUM("scratch_costing"."cost"), 0)), 0), 2) AS "roi" FROM
 "scratch_costing" GROUP BY TO_CHAR("scratch_costing"."ts", D)

 In [36]: roi = qsroi[0]
 In [37]: print(roi)
 {'roi': 0.54, 'sum_cost': Decimal('30.30'), 'sum_rev': Decimal('16.50'),
 'dow': u'4'}

 }}}

 And a quick Case/When example, to show how you could avoid doing division
 by NULL or 0:

 {{{
 In [39]: class Round(Func):
: function = 'ROUND'
:

 In [40]: qsroi =
 qs.annotate(roi=Round(Case(When(Q(sum_cost__isnull=True)|Q(sum_cost=0),
 then='sum_rev'), default=F('sum_rev')/F('sum_cost')), Value(2),
 output_field=FloatField()))

 In [41]: print(qsroi[0])
 {'roi': 0.54, 'sum_cost': Decimal('30.30'), 'sum_rev': Decimal('16.50'),
 'dow': u'4'}

 In [42]: print(qsroi.query)
 SELECT TO_CHAR("scratch_costing"."ts", D) AS "dow",
 SUM("scratch_costing"."cost") AS "sum_cost", SUM("scratch_costing"."rev")
 AS "sum_rev", ROUND(CASE WHEN (SUM("scratch_costing"."cost") IS NULL OR
 SUM("scratch_costing"."cost") = 0) THEN SUM("scratch_costing"."rev") ELSE
 (SUM("scratch_costing"."rev") / SUM("scratch_costing"."cost")) END, 2) AS
 "roi" FROM "scratch_costing" GROUP BY TO_CHAR("scratch_costing"."ts", D)

 }}}

 I've probably put a little too much detail above, but hopefully it'll help
 you solve your problem in a supported way. I'm going to close this as
 wontfix, because the types aren't being used in the right way. If the
 documentation for the expressions or function

[Django] #24235: Deprecate is_usable attribute on template loaders?

2015-01-27 Thread Django

#24235: Deprecate is_usable attribute on template loaders?
-+
Reporter: prestontimmons | Owner: nobody
Type: Uncategorized| Status: new
Component: Template system |Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0| UI/UX: 0
-+
Each Django loaders has a boolean attribute of "is_usable". It seems the
only use for this comes from the egg loader when setuptools isn't
installed. If "is_usable" is false, a warning is raised in
engine.find_template_loader, but otherwise the loader is silently ignored
for template loading.

It seems like that is the wrong behavior. I think the loaders should fail
loudly if they're missing configuration. Otherwise, it's unclear why
they're not used to find templates. I ran into this when writing a sample
loader and forgetting to specify "is_usable" as True on it.

Unless there's a use case for silently ignoring template loaders, I think
we should deprecate 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/057.1d3799751eacd074b4ce1cbe3cf4ecf1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24234: Create Context object in a separate method

2015-01-27 Thread Django

#24234: Create Context object in a separate method
-+---
 Reporter:  AlexHill |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Template system  |Version:  1.8alpha1
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  1|  UI/UX:  0
-+---
 In 1.8, `django.templates.backends.django.Template.render` accepts a
 context dict, and uses that to instantiate a Context (or RequestContext)
 object before passing it to the actual DTL template's `render()`.

 I'd like to break the Context-creation code into its own method so that I
 can call it from my library [https://github.com/alexhill/djpj DjPj], as I
 do with `TemplateResponse.resolve_context` in 1.7 and below.

 It's a very small patch:
 https://github.com/AlexHill/django/compare/stable/1.8.x?diff=split#diff-
 6492e208d64b891c181c85a794d0b303R58

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

Re: [Django] #24215: Refactor of lazy model operations

2015-01-27 Thread Django

Comment (by AlexHill):

Hey Collin, thanks for having a look at this. I'll try to explain myself a
bit better.

`add_lazy_relation` is essentially "do something with this related field
and its two related models when both models are ready". That's just a
special case of the more general "do something when all of these n models
are ready", so I've reimplemented it as such.

The important part is waiting until models are loaded, and running some
code at that time. So I've pulled that part out and made it as generic as
possible: you provide a callback and any number of models or model names,
and when they're all loaded, your code runs with access to the actual
model classes.

I reckon that's a generally useful piece of functionality for Apps to
provide. So that's the first part.

The second part is to introduce a new two-model wrapper function,
`lazy_related_operation`, to replace `add_lazy_relation` itself. A wrapper
function like this remains useful as a place to resolve "self" references
and model names without app_labels, and for identifying the relevant apps
object. There are a few reasons I'd like to deprecate `add_lazy_relation`:
* it doesn't do what it says - it doesn't add lazy relations at all, the
callback you supply does that (or doesn't).
* the argument order is inconsistent. it takes `class, field,
related_class, callback` but the callback's signature has to be `field,
related_class, class`. The API introduced in this patch is consistent with
most other partial/lazy functional APIs: `function, *args, **kwargs`.
* it still requires the field argument, which can be handled by a more
general kwargs implementation (or simply by closing over it)
* it's inconsistent with the new underlying API

`add_lazy_relation` is still there with its existing signature in case
anybody's using it outside of Django, just reimplemented using the new API
and a deprecation warning.

The test suite passes with this patch in place, but I'd gladly write some
more tests that demonstrate the new API in a narrower way.

Alex

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

[Django] #24233: group-by column construction is broken

2015-01-27 Thread Django

#24233: group-by column construction is broken
--+---
 Reporter:  megatrump |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8alpha1
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 I recently moved to 1.8alpha version from an older version django-e9d1f11
 and I started seeing this error. Looks like the way group by is
 constructed has changed. I am using postgres database.

 I could reproduce the behavior with a simple model.
 Here is the model that I have.

 {{{
 class everydaycost(models.Model):
 cost = models.DecimalField(max_digits=20, decimal_places=2)
 rev = models.DecimalField(max_digits=20, decimal_places=2)
 ts = models.DateField(db_index=True)
 }}}

 I am trying to get roi (rev/cost) for each day of week.

 {{{
 $ python manage.py shell
 Python 2.7.5 (default, Mar  9 2014, 22:15:05)
 [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>>
 >>> from testgroupby.models import *
 >>> from django.db.models import Q, Count, Min, Sum, Func, FloatField
 >>> qs = everydaycost.objects.all()
 >>> qs = qs.extra(select={'dow': "TO_CHAR(ts, 'D')"})
 >>> qs = qs.values('dow')
 >>> qs = qs.annotate(sum_cost=Sum('cost'))
 >>> qs = qs.annotate(sum_rev=Sum('rev'))
 >>> qs = qs.annotate(roi=Func(A='CAST(Sum("rev") as numeric)',
 B='CAST(Sum("cost") as numeric)',
 ... template='ROUND(COALESCE(%(A)s / NULLIF(%(B)s,0), 0),
 2)', output_field=FloatField()))
 >>> print qs
 DEBUG(0.002) SELECT (TO_CHAR(ts, 'D')) AS "dow",
 SUM("testgroupby_everydaycost"."cost") AS "sum_cost",
 SUM("testgroupby_everydaycost"."rev") AS "sum_rev",
 ROUND(COALESCE(CAST(Sum("rev") as numeric) / NULLIF(CAST(Sum("cost") as
 numeric),0), 0), 2) AS "roi" FROM "testgroupby_everydaycost" GROUP BY
 (TO_CHAR(ts, 'D')), ROUND(COALESCE(CAST(Sum("rev") as numeric) /
 NULLIF(CAST(Sum("cost") as numeric),0), 0), 2) LIMIT 21; args=()
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Downloads/Django-1.8a1/django/db/models/query.py", line 139, in
 __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File "/Downloads/Django-1.8a1/django/db/models/query.py", line 163, in
 __iter__
 self._fetch_all()
   File "/Downloads/Django-1.8a1/django/db/models/query.py", line 955, in
 _fetch_all
 self._result_cache = list(self.iterator())
   File "/Downloads/Django-1.8a1/django/db/models/query.py", line 1075, in
 iterator
 for row in self.query.get_compiler(self.db).results_iter():
   File "/Downloads/Django-1.8a1/django/db/models/sql/compiler.py", line
 780, in results_iter
 results = self.execute_sql(MULTI)
   File "/Downloads/Django-1.8a1/django/db/models/sql/compiler.py", line
 826, in execute_sql
 cursor.execute(sql, params)
   File "/Downloads/Django-1.8a1/django/db/backends/utils.py", line 80, in
 execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/Downloads/Django-1.8a1/django/db/backends/utils.py", line 65, in
 execute
 return self.cursor.execute(sql, params)
   File "/Downloads/Django-1.8a1/django/db/utils.py", line 95, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/Downloads/Django-1.8a1/django/db/backends/utils.py", line 65, in
 execute
 return self.cursor.execute(sql, params)
 ProgrammingError: aggregate functions are not allowed in GROUP BY
 LINE 1: ... GROUP BY (TO_CHAR(ts, 'D')), ROUND(COALESCE(CAST(Sum("rev")...
  ^

 >>> print qs.query
 SELECT (TO_CHAR(ts, 'D')) AS "dow", SUM("testgroupby_everydaycost"."cost")
 AS "sum_cost", SUM("testgroupby_everydaycost"."rev") AS "sum_rev",
 ROUND(COALESCE(CAST(Sum("rev") as numeric) / NULLIF(CAST(Sum("cost") as
 numeric),0), 0), 2) AS "roi" FROM "testgroupby_everydaycost" GROUP BY
 (TO_CHAR(ts, 'D')), ROUND(COALESCE(CAST(Sum("rev") as numeric) /
 NULLIF(CAST(Sum("cost") as numeric),0), 0), 2)
 >>>
 }}}

 With earlier version, this worked fine for me.

 {{{
 $ python manage.py shell
 Python 2.7.5 (default, Mar  9 2014, 22:15:05)
 [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>>
 >>> from testgroupby.models import *
 >>> from django.db.models import Q, Count, Min, Sum, Func, FloatField
 >>> qs = everydaycost.objects.all()
 >>> qs = qs.extra(select={'dow': "TO_CHAR(ts, 'D')"})
 >>> qs = qs.values('dow')
 >>> qs = qs.annotate(sum_cost=Sum('
 cost'))
 >>> qs = qs.annotate(sum_rev=Sum('rev'))
 >>> qs = qs.anno

Re: [Django] #17617: Middleware Loader swallows useful stacktraces

2015-01-27 Thread Django

#17617: Middleware Loader swallows useful stacktraces
--+
 Reporter:  davedash  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 berkerpeksag):

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


Comment:

 The try/except block described in the ticket description is at
 
https://github.com/django/django/blob/stable/1.4.x/django/core/handlers/base.py#L42-45

 As of Django 1.6+, ImportErrors are not wrapped by ImproperlyConfigured
 anymore:

 *
 
https://github.com/django/django/blob/stable/1.6.x/django/core/handlers/base.py#L45
 *
 https://github.com/django/django/blob/master/django/core/handlers/base.py#L49

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

Re: [Django] #24231: Regression in availability of `_meta.get_field()` before app registry is fully populated

2015-01-27 Thread Django

* cc: pirosb3 (added)

Comment:

Hi carljm

Thanks for flagging the issue.

- Related to docs: You are right! there is nothing stating when this API
is ready to use. I think a note should be added.
- Related to adding another public API: I think that 99% of the developers
will have the Apps registry warmed by the time they touch the interpreter,
or by the time the server is running. Also, getting a field by name can be
done with a simple list comprehension making it close to a one-liner. Do
you think this is worth the trouble?

We could maybe do the following:
- Document better this potential error message, and provide a simple
alternative snippet
- Modify the AppRegistryError to point to the docs, saying there is an
alternative.
But happy to discuss otherwise!

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

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

2015-01-27 Thread Django

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"6c68e40e6e7f3ba36fa0e629d5724c7f4b279bb8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6c68e40e6e7f3ba36fa0e629d5724c7f4b279bb8"
 [1.8.x] Refs #14030 -- Added repr methods to all expressions

 Backport of 7171bf755b0c4be85ddbcc164eaf87164c131021 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.30147062fd1a6f2756530bd5b0e5284a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

2015-01-27 Thread Django

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"f858b51ee31314225e82812f58f353721f06101a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f858b51ee31314225e82812f58f353721f06101a"
 [1.8.x] Refs #14030 -- Renamed CombinableMixin to Combinable

 Removed unused method and updated docstrings.

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

Re: [Django] #24060: Allow expressions to be used in order_by queryset method

2015-01-27 Thread Django

#24060: Allow expressions to be used in order_by queryset method
-+-
 Reporter:  jarshwah |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  expressions  | Triage Stage:  Ready for
  order_by 1.8-alpha |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"405351ba2f639a1a0c092ecb6d93f9f7a646686a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="405351ba2f639a1a0c092ecb6d93f9f7a646686a"
 [1.8.x] Refs #24060 -- Added a test demonstrating reverse order isn't
 mutable

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

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

2015-01-27 Thread Django

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"7171bf755b0c4be85ddbcc164eaf87164c131021"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7171bf755b0c4be85ddbcc164eaf87164c131021"
 Refs #14030 -- Added repr methods to all expressions
 }}}

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

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

2015-01-27 Thread Django

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"14d0bd67d4bcf55f8a0a2b01433571a8b714121f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="14d0bd67d4bcf55f8a0a2b01433571a8b714121f"
 Refs #14030 -- Renamed CombinableMixin to Combinable

 Removed unused method and updated docstrings.
 }}}

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

Re: [Django] #24060: Allow expressions to be used in order_by queryset method

2015-01-27 Thread Django

#24060: Allow expressions to be used in order_by queryset method
-+-
 Reporter:  jarshwah |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  expressions  | Triage Stage:  Ready for
  order_by 1.8-alpha |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"f218a2ff455b5f7391dd38038994f2c5f8b0eca1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f218a2ff455b5f7391dd38038994f2c5f8b0eca1"
 Refs #24060 -- Added a test demonstrating reverse order isn't mutable
 }}}

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

[Django] #24232: Add conditional expressions to block tag

2015-01-27 Thread Django

#24232: Add conditional expressions to block tag
-+
 Reporter:  giuliettamasina  |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Template system  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 It would be nice if I could add a conditional expression after a block
 name, mimicking the shortcut conditional expression form in Python, to
 only render a block if a certain condition is true. So instead of writing
 e.g. this:

 {{{
 {% block title %}
   {% if post.title %}
 {{ post.title }}
   {% else %}
 {{ block.super }}
   {% endif %}
 {% endblock %}
 }}}

 I could write this:

 {{{
 {% block title if post.title %}My title{% endif%}
 }}}

 See also #9173 ([https://code.djangoproject.com/ticket/9173#comment:9
 comment 9]) where I first thought of this.

 I have some working proof of concept code and could open a pull request to
 start working on this, if 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/058.8157872f3ea3778193de2bc4726f8c68%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24231: Regression in availability of `_meta.get_field()` before app registry is fully populated

2015-01-27 Thread Django

#24231: Regression in availability of `_meta.get_field()` before app registry is
fully populated
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by carljm:

Old description:

> In Django versions prior to 1.8, it was possible to call
> `_meta.get_field(...)` on a model class before the app registry was fully
> populated -- for instance, in a `class_prepared` signal handler that
> adjusts a model's fields or adds new field(s). (Real-world example:
> https://github.com/carljm/django-model-
> utils/blob/master/model_utils/models.py#L54-L94)
>
> In 1.8, with the meta refactor, this now raises an `AppRegistryError`.
>
> This change makes sense, because `get_field` also gets reverse related
> fields, and those can't be populated until all models are done loading.
> But it's still a regression in a reasonable use case (even though the
> meta API was technically private before, it was de facto public).
>
> I think the issue of "when are these methods safe to call?" should be
> discussed in the _meta refactor porting guide, because it has changed
> from 1.7, even for methods like `get_field()` that otherwise remain
> similar.
>
> I also think there should be some public supported, documented API that
> is safe to use before the app registry is populated, that accesses only
> fields declared on the local model. Perhaps an API equivalent to what you
> can currently do with `_meta._get_fields(reverse=True)`. (I note that
> this last is already used several places in Django internally where local
> fields need to be accessed before the app registry is ready.)

New description:

 In Django versions prior to 1.8, it was possible to call
 `_meta.get_field(...)` on a model class before the app registry was fully
 populated -- for instance, in a `class_prepared` signal handler that
 adjusts a model's fields or adds new field(s). (Real-world example:
 https://github.com/carljm/django-model-
 utils/blob/master/model_utils/models.py#L54-L94)

 In 1.8, with the meta refactor, this now raises an `AppRegistryError`.

 This change makes sense, because `get_field` also gets reverse related
 fields, and those can't be populated until all models are done loading.
 But it's still a regression in a reasonable use case (even though the meta
 API was technically private before, it was de facto public).

 I think the issue of "when are these methods safe to call?" should be
 discussed in the _meta refactor porting guide, because it has changed from
 1.7, even for methods like `get_field()` that otherwise remain similar.

 I also think there should be some public supported, documented API that is
 safe to use before the app registry is populated, that accesses only
 fields declared on the local model. Perhaps an API equivalent to what you
 can currently do with `_meta._get_fields(reverse=False)`. (I note that
 this last is already used several places in Django internally where local
 fields need to be accessed before the app registry is ready.)

--

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

Re: [Django] #24223: SessionMiddleware tests leaving Session objects in database

2015-01-27 Thread Django

#24223: SessionMiddleware tests leaving Session objects in database
--+
 Reporter:  matt-leach|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.sessions  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by matt-leach):

 Will do

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

Re: [Django] #24223: SessionMiddleware tests leaving Session objects in database

2015-01-27 Thread Django

#24223: SessionMiddleware tests leaving Session objects in database
-+-
 Reporter:  matt-leach   |Owner:  matt-
 Type:   |  leach
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.sessions |  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 matt-leach):

 * owner:  nobody => matt-leach
 * status:  new => assigned


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

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

[Django] #24231: Regression in availability of `_meta.get_field()` before app registry is fully populated

2015-01-27 Thread Django

#24231: Regression in availability of `_meta.get_field()` before app registry is
fully populated
-+-
   Reporter:  carljm |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.7
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In Django versions prior to 1.8, it was possible to call
 `_meta.get_field(...)` on a model class before the app registry was fully
 populated -- for instance, in a `class_prepared` signal handler that
 adjusts a model's fields or adds new field(s). (Real-world example:
 https://github.com/carljm/django-model-
 utils/blob/master/model_utils/models.py#L54-L94)

 In 1.8, with the meta refactor, this now raises an `AppRegistryError`.

 This change makes sense, because `get_field` also gets reverse related
 fields, and those can't be populated until all models are done loading.
 But it's still a regression in a reasonable use case (even though the meta
 API was technically private before, it was de facto public).

 I think the issue of "when are these methods safe to call?" should be
 discussed in the _meta refactor porting guide, because it has changed from
 1.7, even for methods like `get_field()` that otherwise remain similar.

 I also think there should be some public supported, documented API that is
 safe to use before the app registry is populated, that accesses only
 fields declared on the local model. Perhaps an API equivalent to what you
 can currently do with `_meta._get_fields(reverse=True)`. (I note that this
 last is already used several places in Django internally where local
 fields need to be accessed before the app registry is ready.)

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

Re: [Django] #24226: Need to be able to change "(None)" display for null fields in Django admin

2015-01-27 Thread Django

#24226: Need to be able to change "(None)" display for null fields in Django 
admin
--+
 Reporter:  meesterguyperson  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Generic views |  Version:  1.7
 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 wimfeijen):

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


Comment:

 "-" seems a much better default than "(None)" which is confusing and
 language-specific.

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

Re: [Django] #24230: Filter: language_translated returns translated name of language

2015-01-27 Thread Django

#24230: Filter: language_translated returns translated name of language
-+-
 Reporter:  tricoder42   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  filter tag   | Triage Stage:  Accepted
  translated language lang_code  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by wimfeijen):

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


Comment:

 Accepted because not all people are English.

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

Re: [Django] #24229: forms.IntegerField.clean() fails to clean float objects that are integers

2015-01-27 Thread Django

#24229: forms.IntegerField.clean() fails to clean float objects that are 
integers
-+
 Reporter:  jdufresne|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  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 wimfeijen):

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

Re: [Django] #24137: Reason phrases use all upper case by default; standard suggests title case

2015-01-27 Thread Django

#24137: Reason phrases use all upper case by default; standard suggests title 
case
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  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 collinanderson):

 * cc: cmawebsite@… (added)
 * 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/067.13418fff5eb975112ae40540fb0c31b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24229: forms.IntegerField.clean() fails to clean float objects that are integers

2015-01-27 Thread Django

#24229: forms.IntegerField.clean() fails to clean float objects that are 
integers
-+--
 Reporter:  jdufresne|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by jdufresne):

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


Comment:

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

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

Re: [Django] #24181: THOUSAND_SEPARATOR strings are reversed

2015-01-27 Thread Django

#24181: THOUSAND_SEPARATOR strings are reversed
---+
 Reporter:  hannal |Owner:  varun
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  l10n   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by varun):

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


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

Re: [Django] #24228: Signals have unclear & inconsistent transaction handling

2015-01-27 Thread Django

#24228: Signals have unclear & inconsistent transaction handling
-+-
 Reporter:  Gaffney  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  transaction, | Triage Stage:  Accepted
  signals, documentation |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * version:  1.7 => master
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I think the `pre_save` should really be inside the same transaction as the
 `save` part. I'm a bit less convinced about the `post_save` (that is
 should a `post_save` error be able to "cancel" a `save`?), but it might be
 the case also.

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

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

2015-01-27 Thread Django

#23273: MigrationRecorder does not obey db_router allow_migrate rules
+
 Reporter:  froomzy |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by timgraham):

 It's not clear to me what fixing this issue involves exactly. Anyway, it
 doesn't appear anyone is working on it so there's no timetable for its
 resolution.

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

[Django] #24230: Filter: language_translated returns translated name of language

2015-01-27 Thread Django

#24230: Filter: language_translated returns translated name of language
-+-
 Reporter:  tricoder42   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:   |Version:  master
  Internationalization   |   Keywords:  filter tag translated
 Severity:  Normal   |  language lang_code
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 `get_language_info` tag returns english name and local name of language:

 {{{
 language.local_name == česky
 language.name == Czech
 }}}

 Neither depends on active language, but sometimes there's need for
 translated language name, ex.  tchèque (in French). The only way how to do
 it right now is to take the english name and run it through `gettext`
 since Django already has all languages translated.

 This would be very handy filter tag:

 {{{
 @register.filter
 def language_translated(code):
 """
 Return language name translated into active language
 """

 name = translation.get_language_info(code)['name'].capitalize()
 return translation.gettext(name)
 }}}

 

 Maybe we could also extend dictionary returned by the `get_language_info`
 tag with `name_translated` to keep API consistent. All keys from
 `get_language_info` have matching filter variants (`language_name`,
 `language_name_local` and `language_bidi`).

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

Re: [Django] #6785: QuerySet.get() should only attempt to fetch a limited number of rows

2015-01-27 Thread Django

#6785: QuerySet.get() should only attempt to fetch a limited number of rows
-+-
 Reporter:  deadwisdom   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


Comment:

 Of course, if someone writes a patch we'll look at it.

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

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

Re: [Django] #6785: QuerySet.get() should only attempt to fetch a limited number of rows

2015-01-27 Thread Django

#6785: QuerySet.get() should only attempt to fetch a limited number of rows
-+-
 Reporter:  deadwisdom   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jafula):

 Any chance of revisiting this for 1.8? In Oracle, the get query SQL is
 wrapped in an additional select and is just noise when debugging (no known
 performance complaints in Production so far).

 We have our own Oracle backend that inherits from the one that ships with
 Django that we have added Oracle DRCP (connection pooling) support to it.

 So some sort of hook, parameter or over-ridable function that would let us
 turn this feature off in our own backend would be wonderful.

 Michael

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

Re: [Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

2015-01-27 Thread Django

#24227: isinstance checks on ManyToManyField should be replaced with
field.many_to_many
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Yea, as Loic said in IRC, "The thing is in practice we probably aren't
 ready. If isinstance is followed by reaching private attributes of
 ManyToManyField, checking for many_to_many isn't going to work, but in any
 case it'd be good to identify where we have this kind of issues."

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

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

2015-01-27 Thread Django

#23273: MigrationRecorder does not obey db_router allow_migrate rules
+
 Reporter:  froomzy |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by froomzy):

 Hi guys,

 Just wondering if there is any chance this will make it into 1.8? Or soon
 there after?

 Thanks,
 Dylan

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

Re: [Django] #12500: Support for MySQL Connector/Python

2015-01-27 Thread Django

#12500: Support for MySQL Connector/Python
-+-
 Reporter:  geertjanvdk  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  backend mysql| Triage Stage:
  myconnpy   |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #5745: MySQL Collations/Charsets and Engines

2015-01-27 Thread Django

* cc: shaib (added)

Comment:

For the record:

All core backends (except Oracle, it seems) can set collation per column;
collation names are not standard (and SQLite has only 3 built-in
collations, none of them reasonable for any native language). Except (I
think) for Oracle, they can also set collation for a specific query (the
collation can be used in ordering comparisons or in `ORDER BY`). This
means that any reasonable collation support in core would beget backend-
specific usages, which I wouldn't like.

However, I think core should make it possible to add collation support via
external libraries. I would like to see the API for such extension.

Of all core backends, the only one which can set the character encoding at
a level lower than the whole database is MySQL. Since Django does not
usually create databases (except for test databases), I think this feature
should not be added (except, with the API mentioned above, in a MySQL-
specific library outside 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.3c048d6c76bf6833f721a408fff2df37%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24225: KeyError when migrating in 1.8a1/master@728b6fd (does not occur in 1.7.3)

2015-01-27 Thread Django

#24225: KeyError when migrating in 1.8a1/master@728b6fd (does not occur in 
1.7.3)
-+-
 Reporter:  hheimbuerger |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8alpha1
 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
-+-
Changes (by claudep):

 * version:  master => 1.8alpha1
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Would you be able to reduce your set of models to reproduce this issue on
 a minimal structure you would then be able to share?

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

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

Re: [Django] #16859: CSRF Improvements

2015-01-27 Thread Django

#16859: CSRF Improvements
--+
 Reporter:  PaulM |Owner:  PaulM
 Type:  Cleanup/optimization  |   Status:  new
Component:  CSRF  |  Version:  1.3
 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 collinanderson):

 * cc: cmawebsite@… (added)


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

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

Re: [Django] #24224: sqlmigrate is slow

2015-01-27 Thread Django

#24224: sqlmigrate is slow
-+-
 Reporter:  TorstenRottmann  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migration slow   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Are you able to test on 1.8alpha? Most probably a duplicate of #23745.

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

Re: [Django] #24209: Incorrectly formatted Content-Disposition headers may cause error.

2015-01-27 Thread Django

#24209: Incorrectly formatted Content-Disposition headers may cause error.
---+-
 Reporter:  tomchristie|Owner:  raulcd
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.8alpha1
 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 Claude Paroz ):

 In [changeset:"7cc1b4710ea3fbe3a076d14f9265f115a615964a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7cc1b4710ea3fbe3a076d14f9265f115a615964a"
 [1.8.x] Fixed #24209 -- Prevented crash when parsing malformed RFC 2231
 headers

 Thanks Tom Christie for the report and review.
 Backport of ac650d02cb 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/069.d74614686f9e632df52ccf8c19655429%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24209: Incorrectly formatted Content-Disposition headers may cause error.

2015-01-27 Thread Django

#24209: Incorrectly formatted Content-Disposition headers may cause error.
---+-
 Reporter:  tomchristie|Owner:  raulcd
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.8alpha1
 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 Claude Paroz ):

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


Comment:

 In [changeset:"ac650d02cbb66ab652ae529b8f03b486ef974dfb"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ac650d02cbb66ab652ae529b8f03b486ef974dfb"
 Fixed #24209 -- Prevented crash when parsing malformed RFC 2231 headers

 Thanks Tom Christie for the report and 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/069.3e3a387f1d61ee05920d5582d07a7c99%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24229: forms.IntegerField.clean() fails to clean float objects that are integers

2015-01-27 Thread Django

#24229: forms.IntegerField.clean() fails to clean float objects that are 
integers
-+
 Reporter:  jdufresne|  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Forms|Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Django forms are useful for validating user input beyond just HTML forms.
 They can be used to validate and clean user input from multiple sources.

 One source could potentially be an spreadsheets. Imagine a spreadsheet
 where each row is data keyed by its header. Each row is validated by a
 Django `Form` object, if the form is valid,  some action occurs.

 One issue, MS Excel represents all numbers in cells as floats, even
 integers. So for this to work, a float with value `1.0` should be cleaned
 by `forms.IntegerField` as `1`. Currently this fails as
 `forms.IntegerField.to_python()` is implemeted as:

 {{{
 try:
 value = int(str(value))
 except (ValueError, TypeError):
 raise ValidationError(self.error_messages['invalid'], code='invalid')
 }}}

 But this fails for floats:

 {{{
 $ python -c 'int(str(1.0))'
 Traceback (most recent call last):
   File "", line 1, in 
 ValueError: invalid literal for int() with base 10: '1.0'
 }}}

 The following test demonstrates that this does not work in Django:

 {{{
 $ git diff
 diff --git a/tests/forms_tests/tests/test_fields.py
 b/tests/forms_tests/tests/test_fields.py
 index fda4512..3069520 100644
 --- a/tests/forms_tests/tests/test_fields.py
 +++ b/tests/forms_tests/tests/test_fields.py
 @@ -184,6 +184,7 @@ class FieldsTests(SimpleTestCase):
  self.assertRaisesMessage(ValidationError, "'Enter a whole
 number.'", f.clean, '1a')
  self.assertEqual(f.max_value, None)
  self.assertEqual(f.min_value, None)
 +self.assertEqual(1, f.clean(1.0))

  def test_integerfield_2(self):
  f = IntegerField(required=False)
 }}}

 I propose that the `fields.IntegerField` be able to clean float objects
 that represent an integer. This will help make Django forms useful for
 user input beyond simple HTML forms.

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

Re: [Django] #12500: Support for MySQL Connector/Python

2015-01-27 Thread Django

#12500: Support for MySQL Connector/Python
-+-
 Reporter:  geertjanvdk  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  backend mysql| Triage Stage:
  myconnpy   |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by collinanderson):

 I think we should close this now that we officially recommend mysqlclient.
 (mysqlclient works on Python 3.)

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

Re: [Django] #24223: SessionMiddleware tests leaving Session objects in database

2015-01-27 Thread Django

#24223: SessionMiddleware tests leaving Session objects in database
--+
 Reporter:  matt-leach|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.sessions  |  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 charettes):

 * cc: charettes (added)
 * needs_better_patch:   => 0
 * component:  Uncategorized => contrib.sessions
 * needs_tests:   => 0
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 This change makes sense to me, can you open a PR with the required change?

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

Re: [Django] #20542: pymysql breaks last_executed_query()

2015-01-27 Thread Django

#20542: pymysql breaks last_executed_query()
-+-
 Reporter:  christian.oudard@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 collinanderson):

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


Comment:

 Closing now that mysqlclient is our official recommended connector.

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

[Django] #24228: Signals have unclear & inconsistent transaction handling

2015-01-27 Thread Django

The [https://docs.djangoproject.com/en/1.7/ref/signals/ signals
documentation] says nothing about transactions.

Looking in deletion.py,

[https://github.com/django/django/blob/fb48eb05816b1ac87d58696cdfe48be18c901f16/django/db/models/deletion.py#L282-L288
pre_delete and post_delete are within a transaction].

In base.py, however,

[https://github.com/django/django/blob/378a0d27d630386c1b0a53d4a2d48be767453198/django/db/models/base.py#L717-L719
pre_save] and

[https://github.com/django/django/blob/378a0d27d630386c1b0a53d4a2d48be767453198/django/db/models/base.py#L730-L732
post_save] are ''not'' within a transaction.

Whether this inconsistency is a bug is beyond my Django knowledge to
determine, but regardless, '''it should be clear in the documentation what
signals are within transactions'''.

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

Re: [Django] #24215: Refactor of lazy model operations

2015-01-27 Thread Django

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by collinanderson):

 * cc: cmawebsite@… (added)
 * version:  1.8alpha1 => master


Comment:

 Hi, Thanks for the patch. It's super clear to me what problem you're
 trying to solve.

 A test or simpler pull request could make it more clear.

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

Re: [Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

2015-01-27 Thread Django

#24227: isinstance checks on ManyToManyField should be replaced with
field.many_to_many
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by pirosb3):

 Hi

 I agree. Now that we have field flags {{{isinstance()}}} checks can be
 replaced, possibly also removing an import statement. As far as I remember
 (@freakyboy and @timgraham let me know if this is not the case) we wanted
 to do this in stages.

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

Re: [Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

2015-01-27 Thread Django

* cc: MarkusH (added)
* stage: Unreviewed => Accepted

Comment:

This change should eventually happen at some point. But I don't think we
are there yet. If we are going to replace a bunch of `isinstance()` calls
in the migration / schema / ORM layers, we should also think about
`ForeignKey` and foreignkey-like fields, where `field.one_to_many` and
`field.one_to_one` join the game.

This ticket will require some deeper digging than the one referenced
(#24104).

As soon as composite fields and composite foreign keys are a thing, this
ticket will certainly be 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/066.c11052275548232c230d4565c4723c95%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

2015-01-27 Thread Django

#24227: isinstance checks on ManyToManyField should be replaced with
field.many_to_many
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  master
 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 coldmind):

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


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

Re: [Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

2015-01-27 Thread Django

#24227: isinstance checks on ManyToManyField should be replaced with
field.many_to_many
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by collinanderson):

 * component:  Uncategorized => Database layer (models, ORM)


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

Re: [Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

2015-01-27 Thread Django

#24227: isinstance checks on ManyToManyField should be replaced with
field.many_to_many
-+-
 Reporter:  coldmind |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  master
 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 collinanderson):

 * cc: cmawebsite@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

2015-01-27 Thread Django

#24227: isinstance checks on ManyToManyField should be replaced with
field.many_to_many
--+
 Reporter:  coldmind  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 `\bisinstance\b\([a-zA-Z._-]*.\s[a-zA-Z.]*?\bManyToManyField\b` gives me
 15 occurrences (I will check manually too).

 As a followup to https://code.djangoproject.com/ticket/24104, it might be
 good to check and replace (where we can do this) to look more cleaner and
 allow custom m2m-fields to behave in the same way like original
 `ManyToManyField` do.

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

[Django] #24226: Need to be able to change "(None)" display for null fields in Django admin

2015-01-27 Thread Django

#24226: Need to be able to change "(None)" display for null fields in Django
admin
--+
Reporter: meesterguyperson | Owner: nobody
Type: New feature | Status: new
Component: Generic views |Version: 1.7
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+
We have a particular changelist view that is very busy, lots of columns,
and because the items there house lots of different kinds of items, there
are lots of null fields depending on the items in question. Wherever
there is a null field, "(None)" is displayed. I would like to be able to
change this to "-" or even nothing, so as to make the changelist view more
presentable. There are a couple things on stackoverflow about this, but
nothing that looks really official. Would be really nice if this could be
done on a per modeladmin basis, but I'd settle for an admin wide solution
too. Any chances of this coming along anytime soon?

http://stackoverflow.com/questions/18324030/how-to-change-empty-
changelist-value-in-django-admin

http://stackoverflow.com/questions/28174881/in-the-django-admin-
changelist-how-do-i-display-a-blank-space-instead-of-the-
de?noredirect=1#comment44719629_28174881

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

Re: [Django] #24225: KeyError when migrating in 1.8a1/master@728b6fd (does not occur in 1.7.3)

2015-01-27 Thread Django

#24225: KeyError when migrating in 1.8a1/master@728b6fd (does not occur in 
1.7.3)
--+--
 Reporter:  hheimbuerger  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  master
 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 hheimbuerger):

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


Old description:

> When running the `migrate` management command (even if there is nothing
> to migrate) on 1.8a1 or the current GitHub master, I'm getting the
> following uncaught `KeyError`:
>
> {{{
> Running migrations:
>   Rendering model states... DONE
> Traceback (most recent call last):
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "d:\develop\myproj\django-
> trunk\django\core\management\__init__.py", line 330, in
> execute_from_command_line
> utility.execute()
>   File "d:\develop\myproj\django-
> trunk\django\core\management\__init__.py", line 322, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "d:\develop\myproj\django-trunk\django\core\management\base.py",
> line 350, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "d:\develop\myproj\django-trunk\django\core\management\base.py",
> line 401, in execute
> output = self.handle(*args, **options)
>   File "d:\develop\myproj\django-
> trunk\django\core\management\commands\migrate.py", line 187, in handle
> executor.migrate(targets, plan, fake=options.get("fake", False))
>   File "d:\develop\myproj\django-trunk\django\db\migrations\executor.py",
> line 89, in migrate
> state = migration.mutate_state(state)  # state is cloned inside
>   File "d:\develop\myproj\django-
> trunk\django\db\migrations\migration.py", line 78, in mutate_state
> operation.state_forwards(self.app_label, new_state)
>   File "d:\develop\myproj\django-
> trunk\django\db\migrations\operations\fields.py", line 50, in
> state_forwards
> state.reload_model(app_label, self.model_name_lower)
>   File "d:\develop\myproj\django-trunk\django\db\migrations\state.py",
> line 61, in reload_model
> self._reload_one_model(rel_model._meta.app_label,
> rel_model._meta.model_name)
>   File "d:\develop\myproj\django-trunk\django\db\migrations\state.py",
> line 68, in _reload_one_model
> self.models[app_label, model_name].render(self.apps)
> KeyError: ('myapp', 'anoldmodel')
> }}}
>
> The reported model is created and then only appears twice in my
> migrations:
>
> In `myapp/migrations/0001_initial.py`:
> {{{
> migrations.AddField(
> model_name='somemodel',
> name='somefieldname',
> field=models.ForeignKey(to='myapp.AValidModel'),
> preserve_default=True,
> ),
> }}}
>
> and in `myapp/migrations/0002_a.py`:
> {{{
> migrations.RemoveField(
> model_name='somemodel',
> name='somefieldname',
> ),
> }}}
>
> Other than that, the model hasn't been changed in the migrations.
>
> The application is closed source and I can't share real code with you
> unfortunately.
>
> I do have a debugger connected to the issue, but I have no idea where to
> even start debugging this. By checking the stack frame for
> `mutation.py:78` (`mutate_state()`), I can see that the "current
> migration" when this occurs is a `0002_b.py`, i.e. another migration
> dependent on `0001_initial.py` which therefore shouldn't be aware of the
> field removal yet.
>
> These migrations do work on 1.7.3. (But I can't really work on 1.7.3
> because unit test startup takes minutes without `--keepdb`…)
>
> Whatever the cause of this is, I highly recommend catching `KeyError` in
> `_reload_one_model()` and rethrowing a proper exception with a
> descriptive error message, including the stage and specific migration at
> which this occurs. Because a `KeyError` being raised somewhere in the
> depths of the migration system tells me nothing about what or where the
> issue is.

New description:

 When running the `migrate` management command (even if there is nothing to
 migrate) on 1.8a1 or the current GitHub master, I'm getting the following
 uncaught `KeyError`:

 {{{
 Running migrations:
   Rendering model states... DONE
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "d:\develop\myproj\django-
 trunk\django\core\management\__init__.py", line 330, in
 execute_from_command_line
 utility.execute()
   File "d:\develop\myproj\django-
 tr

[Django] #24225: KeyError when migrating in 1.8a1/master@728b6fd (does not occur in 1.7.3)

2015-01-27 Thread Django

#24225: KeyError when migrating in 1.8a1/master@728b6fd (does not occur in 
1.7.3)
--+
 Reporter:  hheimbuerger  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Migrations|Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When running the `migrate` management command (even if there is nothing to
 migrate) on 1.8a1 or the current GitHub master, I'm getting the following
 uncaught `KeyError`:

 {{{
 Running migrations:
   Rendering model states... DONE
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "d:\develop\myproj\django-
 trunk\django\core\management\__init__.py", line 330, in
 execute_from_command_line
 utility.execute()
   File "d:\develop\myproj\django-
 trunk\django\core\management\__init__.py", line 322, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "d:\develop\myproj\django-trunk\django\core\management\base.py",
 line 350, in run_from_argv
 self.execute(*args, **cmd_options)
   File "d:\develop\myproj\django-trunk\django\core\management\base.py",
 line 401, in execute
 output = self.handle(*args, **options)
   File "d:\develop\myproj\django-
 trunk\django\core\management\commands\migrate.py", line 187, in handle
 executor.migrate(targets, plan, fake=options.get("fake", False))
   File "d:\develop\myproj\django-trunk\django\db\migrations\executor.py",
 line 89, in migrate
 state = migration.mutate_state(state)  # state is cloned inside
   File "d:\develop\myproj\django-trunk\django\db\migrations\migration.py",
 line 78, in mutate_state
 operation.state_forwards(self.app_label, new_state)
   File "d:\develop\myproj\django-
 trunk\django\db\migrations\operations\fields.py", line 50, in
 state_forwards
 state.reload_model(app_label, self.model_name_lower)
   File "d:\develop\myproj\django-trunk\django\db\migrations\state.py",
 line 61, in reload_model
 self._reload_one_model(rel_model._meta.app_label,
 rel_model._meta.model_name)
   File "d:\develop\myproj\django-trunk\django\db\migrations\state.py",
 line 68, in _reload_one_model
 self.models[app_label, model_name].render(self.apps)
 KeyError: ('myapp', 'anoldmodel')
 }}}

 The reported model is created and then only appears twice in my
 migrations:

 In `myapp/migrations/0001_initial.py`:
 {{{
 migrations.AddField(
 model_name='somemodel',
 name='somefieldname',
 field=models.ForeignKey(to='myapp.AValidModel'),
 preserve_default=True,
 ),
 }}}

 and in `myapp/migrations/0002_a.py`:
 {{{
 migrations.RemoveField(
 model_name='somemodel',
 name='somefieldname',
 ),
 }}}

 Other than that, the model hasn't been changed in the migrations.

 The application is closed source and I can't share real code with you
 unfortunately.

 I do have a debugger connected to the issue, but I have no idea where to
 even start debugging this. By checking the stack frame for
 `mutation.py:78` (`mutate_state()`), I can see that the "current
 migration" when this occurs is a `0002_b.py`, i.e. another migration
 dependent on `0001_initial.py` which therefore shouldn't be aware of the
 field removal yet.

 These migrations do work on 1.7.3. (But I can't really work on 1.7.3
 because unit test startup takes minutes without `--keepdb`…)

 Whatever the cause of this is, I highly recommend catching `KeyError` in
 `_reload_one_model()` and rethrowing a proper exception with a descriptive
 error message, including the stage and specific migration at which this
 occurs. Because a `KeyError` being raised somewhere in the depths of the
 migration system tells me nothing about what or where the issue is.

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

Re: [Django] #24219: Deprecate django.forms.extras and move SelectDateWidget with the other widget.

2015-01-27 Thread Django

#24219: Deprecate django.forms.extras and move SelectDateWidget with the other
widget.
-+-
 Reporter:  loic |Owner:  loic
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Loic Bistuer ):

 In [changeset:"3a4c9e1b43ff67b6cf4c59da757666d6ac5ce4a0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3a4c9e1b43ff67b6cf4c59da757666d6ac5ce4a0"
 Cleaned up some forms tests.

 Thanks Berker Peksag and Tim Graham for the reviews. Refs #24219.
 }}}

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

Re: [Django] #24219: Deprecate django.forms.extras and move SelectDateWidget with the other widget.

2015-01-27 Thread Django

#24219: Deprecate django.forms.extras and move SelectDateWidget with the other
widget.
-+-
 Reporter:  loic |Owner:  loic
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  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 Loic Bistuer ):

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


Comment:

 In [changeset:"728b6fd9ca8624271f072d5f4618dc3fd38e87f1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="728b6fd9ca8624271f072d5f4618dc3fd38e87f1"
 Fixed #24219 -- Moved SelectDateWidget together with the other widgets
 and deprecated django.forms.extras.

 Thanks Berker Peksag and Tim Graham for the reviews.
 }}}

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

Re: [Django] #24210: Clean up relational fields init args/kwargs.

2015-01-27 Thread Django

#24210: Clean up relational fields __init__ args/kwargs.
-+-
 Reporter:  loic |Owner:  loic
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Loic Bistuer ):

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


Comment:

 In [changeset:"84b6c768301096849f5589d7612b129c5445abd3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="84b6c768301096849f5589d7612b129c5445abd3"
 Fixed #24210 -- Cleaned up relational fields __init__().

 Thanks Collin Anderson and Tim Graham for the reviews.
 }}}

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

Re: [Django] #24104: SQLite schema should to look for internal type of field instead of class instance when choosing a default for created fields

2015-01-27 Thread Django

#24104: SQLite schema should to look for internal type of field instead of class
instance when choosing a default for created fields
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Markus Holtermann ):

 In [changeset:"da224d6be0d55811d448ed6d57ac828c18cd1a80"]:
 {{{
 #!CommitTicketReference repository=""
 revision="da224d6be0d55811d448ed6d57ac828c18cd1a80"
 Refs #24104 -- Added missing release notes

 Forwardport of 3d4a826174b7a411a03be39725e60c940944a7fe from stable/1.7.x
 }}}

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

Re: [Django] #24104: SQLite schema should to look for internal type of field instead of class instance when choosing a default for created fields

2015-01-27 Thread Django

#24104: SQLite schema should to look for internal type of field instead of class
instance when choosing a default for created fields
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Markus Holtermann ):

 In [changeset:"645fe136c4354ce313be5a150864ad046c227a22"]:
 {{{
 #!CommitTicketReference repository=""
 revision="645fe136c4354ce313be5a150864ad046c227a22"
 [1.8.x] Refs #24104 -- Added missing release notes

 Forwardport of 3d4a826174b7a411a03be39725e60c940944a7fe from stable/1.7.x
 }}}

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

[Django] #24224: sqlmigrate is slow

2015-01-27 Thread Django

#24224: sqlmigrate is slow
--+
 Reporter:  TorstenRottmann   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Migrations|Version:  1.7
 Severity:  Normal|   Keywords:  migration slow
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When requesting an '''sqlmigrate''' (or when do a '''test''' or
 '''migrate''' also), it takes a very long time to compute the sql for a
 particular app migration. This app has some 78 models and is highly
 interconnected with ForeignKeys (100+).[[BR]]

 I ran the '''sqlmigrate''' through the profiler an got these
 results:[[BR]]

 {{{
  74628418 function calls (74229555 primitive calls) in 3653.843
 seconds

Ordered by: internal time

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 4 3519.805  879.951 3519.805  879.951 {method 'write' of 'file'
 objects}
552977   18.6090.000   29.8930.000 __init__.py:292(deconstruct)
 40096   14.2440.000   20.0510.001
 related.py:276(swappable_setting)
318698   11.9240.000   21.1140.000 __init__.py:1011(__init__)
5751829.5690.000   12.6340.000 __init__.py:123(__init__)
5717297.3360.000   97.0270.000
 state.py:277(construct_fields)
 16773896/167220106.7500.0006.7900.000 {getattr}
 851382.8490.0004.8830.000 __init__.py:1092(__init__)
 553122/5531062.5460.0006.5030.000 {__import__}
 637429/3187191.9160.0002.1460.000
 deconstruct.py:15(__new__)
   32367901.9120.0001.9120.000 {method 'startswith' of
 'unicode' objects}
 3881367/38813651.8910.0004.4620.000 {isinstance}
   59156011.5660.0001.8410.000 options.py:283(_swapped)
 438681.5250.0001.5250.000
 base.py:33(subclass_exception)
9017151.5080.0002.5710.000
 abc.py:128(__instancecheck__)
 21946/198201.4860.000   24.6460.001 base.py:61(__new__)
 ...
 }}}

 Waiting more than a minute for a test to start is very annoying ...

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

[Django] #24223: SessionMiddleware tests leaving Session objects in database

2015-01-27 Thread Django

#24223: SessionMiddleware tests leaving Session objects in database
--+
 Reporter:  matt-leach|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Currently with default settings several tests in
 contrib.sessions.SessionMiddlewareTests leave Session objects remaining in
 the database.

 This can be seen by adding a tearDown method:


 {{{
 class SessionMiddlewareTests(unittest.TestCase):

 def tearDown(self):
 print "Session count:", len(Session.objects.all())
 }}}

 This results in the following output:

 {{{
 $ ./manage.py test django.contrib.sessions.tests.SessionMiddlewareTests -v
 3

 ...

 test_httponly_session_cookie
 (django.contrib.sessions.tests.SessionMiddlewareTests) ... Session count:
 1
 ok
 test_no_httponly_session_cookie
 (django.contrib.sessions.tests.SessionMiddlewareTests) ... Session count:
 2
 ok
 test_secure_session_cookie
 (django.contrib.sessions.tests.SessionMiddlewareTests) ... Session count:
 3
 ok
 test_session_delete_on_end
 (django.contrib.sessions.tests.SessionMiddlewareTests) ... Session count:
 3
 ok
 test_session_save_on_500
 (django.contrib.sessions.tests.SessionMiddlewareTests) ... Session count:
 4
 ok

 --
 Ran 5 tests in 0.011s

 OK
 }}}


 Currently this does not result in failing tests when the test suite is run
 but it could lead to issues with tests such as
 contrib.sessions.DatabaseSessionTests.test_clearsessions_command:

 {{{
 class DatabaseSessionTests(SessionTestsMixin, TestCase):

 backend = DatabaseSession

 ...

 @override_settings(SESSION_ENGINE="django.contrib.sessions.backends.db")
 def test_clearsessions_command(self):
 """
 Test clearsessions command for clearing expired sessions.
 """
 self.assertEqual(0, Session.objects.count())
 }}}

 which would fail if run immediately after the SessionMiddleware tests.

 I would suggest changing the SessionMiddlewareTests class to inherit from
 django.test.TestCase rather than unittest.TestCase which will ensure the
 database is flushed after the tests run.

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

Re: [Django] #24210: Clean up relational fields init args/kwargs.

2015-01-27 Thread Django

#24210: Clean up relational fields __init__ args/kwargs.
-+-
 Reporter:  loic |Owner:  loic
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Unreviewed => 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/062.fa57eb7b024beaad03663ff954d715dd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24104: SQLite schema should to look for internal type of field instead of class instance when choosing a default for created fields

2015-01-27 Thread Django

#24104: SQLite schema should to look for internal type of field instead of class
instance when choosing a default for created fields
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Markus Holtermann ):

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


Comment:

 In [changeset:"3d4a826174b7a411a03be39725e60c940944a7fe"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3d4a826174b7a411a03be39725e60c940944a7fe"
 [1.7.x] Fixed #24104 -- Fixed check to look on field.get_internal_type()
 instead of class instance
 }}}

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

Re: [Django] #24053: Drop IE6/7 admin CSS/icons

2015-01-27 Thread Django

#24053: Drop IE6/7 admin CSS/icons
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"7a90b53d60f6a66340811417547e33e0bfadf09e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7a90b53d60f6a66340811417547e33e0bfadf09e"
 Fixed #24053 -- Removed admin CSS & images for IE6 & 7.
 }}}

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

Re: [Django] #24209: Incorrectly formatted Content-Disposition headers may cause error.

2015-01-27 Thread Django

#24209: Incorrectly formatted Content-Disposition headers may cause error.
---+-
 Reporter:  tomchristie|Owner:  raulcd
 Type:  Bug|   Status:  assigned
Component:  HTTP handling  |  Version:  1.8alpha1
 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
---+-

Comment (by tomchristie):

 Yup that looks correct.

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

70 matches

Mail list logo