Re: [Django] #10702: .extra() should accept "having" parameter

[Django]

#10702: .extra() should accept "having" parameter
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alex):

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


Comment:

 We've generally been in the direction of restricting (and hopefully)
 removing `extra()`, rather than expanding it.  Therefore wontfixing this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10702: .extra() should accept "having" parameter

[Django]

#10702: .extra() should accept "having" parameter
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 3 years and this still isn't fixed?

 So people on mysql can use extra to specify extra params, but the only way
 to do filtering on those is via the HAVING clause, as the WHERE clause
 isn't aware of those params.

 So if comment #1 is correct, and this was rejected for some ridiculous
 reason, then it almost looks like explicitly targeting mysql users, as
 other db users can use the standard extra(where=...) to handle filtering,
 but mysql users are denied access to HAVING because of one asshole with a
 head full of bad decisions, who probably didn't even understand the
 ramifications of his actions.

 So for mysql users, there is NO WAY TO FILTER USING THE PARAMS DEFINED IN
 EXTRA. Is this more or less correct? And no one has any intention of
 fixing it?

 Isn't that precious!

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18515: Problematic validation code in FileField

[Django]

#18515: Problematic validation code in FileField
-+-
 Reporter:  yoyoma   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  max_length,  | Triage Stage:
  FileField, fields  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yoyoma):

 * type:  Bug => Uncategorized


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18515: Problematic validation code in FileField

[Django]

#18515: Problematic validation code in FileField
-+-
 Reporter:  yoyoma   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  max_length,  | Triage Stage:
  FileField, fields  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yoyoma):

 * cc: yoyoma (added)
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_better_patch:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18515: Problematic validation code in FileField

[Django]

#18515: Problematic validation code in FileField
---+---
 Reporter:  yoyoma |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:  max_length, FileField, fields
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 The following code in {{{django.db.models.fields.files}}} (line # 235 in
 master @ HEAD) is problematic.

 {{{
 def validate(self, value, model_instance):
 """
 Validates that the generated file name still fits within
 max_length.
 """
 # The generated file name stored in the database is generally
 longer
 # than the uploaded file name. Using the length of generated name
 in
 # the error message would be confusing. However, in the common
 case
 # (ie. upload_to='path/to/upload/dir'), the length of the
 generated
 # name equals the length of the uploaded name plus a constant.
 Thus
 # we can tell the user how much shorter the name should be
 (roughly).
 length = len(self.generate_filename(model_instance, value.name))
 if self.max_length and length > self.max_length:
 error_values = {'extra': length - self.max_length}
 raise ValidationError(self.error_messages['max_length'] %
 error_values)
 }}}

 Given the following:

 {{{
 def oops_asset_path(instance, filename):
 """
 Returns the upload path for a ``Oops.asset``.
 """
 return 'oops/user_{upk}/{dt}/{fn}'.format(
 upk=instance.user_id,
 dt=timezone.now().strftime('%Y_%j_%H_%M_%S_%f'),
 fn=re.sub(r'[^\w\.]', '_', filename).lower())


 class Oops(models.Model):
 asset = models.FileField(_(u'asset'), upload_to=oops_asset_path)

 }}}

 When an {{{Oops}}} instance is saved with the {{{asset}}} file name
 {{{the-best-file-name-ever.jpg}}}, it's converted to something like:

 {{{
 oops/user_3145/2012_178_00_16_02_738638/the_best_file_name_ever.jpg
 }}}

 which is expected. Then, when the {{{Oops}}} is saved again in a form
 (e.g., an inline model formset I use for multiple uploads) the above
 validation code runs the existing name through my {{{oops_asset_path}}},
 which returns:

 {{{
 
oops/user_3145/2012_178_00_16_03_457362/oops_user_3145_2012_178_00_16_02_738638_the_best_file_name_ever.jpg
 }}}

 This causes the {{{max_length}}} validation error, since the new name is
 clearly too long:

 {{{
 Filename is 7 characters too long.
 }}}

 The file name isn't changed permanently, but these erroneous validation
 errors are only avoided by increasing the field's {{{max_length}}}.

 I can't think of any solution to this that doesn't include either a
 database query or else some sort of annotation on the {{{FileField}}} by
 forms... both of which scare me.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15084: Unnecessary imports lead to ImportError

[Django]

#15084: Unnecessary imports lead to ImportError
--+
 Reporter:  vanschelven   |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Internationalization  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by vanschelven):

 Well yes, there are a number of things to be said against the example I
 came up with. Besides the use of uggettext as opposed to ugettext_lazy you
 could point at the fact that so much happens in __init__.py or the fact
 that one could 'work around' the problem by reversing the order of the
 INSTALLED_APPS.

 However, I think we should strive for Django to be forgiving to its users'
 preferences and to fail in predictable and understandable ways. And I dare
 to say an !ImportError should not be the perfectionists' answer to using
 ugettext in a class definition.

 Remember the only reason Django is currently doing the import is to figure
 out where the apps are so it can tuck 'locale' at the end and look for .mo
 files there.

 Doing frivolous imports in a framework is a Bad Idea (tm)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18467: Login in from admin logout page should not logout again

[Django]

#18467: Login in from admin logout page should not logout again
---+
 Reporter:  etienned   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 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 etienned):

 Just a smal note: no need to import reverse() in the real code.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15084: Unnecessary imports lead to ImportError

[Django]

#15084: Unnecessary imports lead to ImportError
--+
 Reporter:  vanschelven   |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Internationalization  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 IMO you shouldn't do translations at compile time; you should use
 `ugettext_lazy` instead of `ugettext`.

 It's a bit like running SQL at compile time: you can get away with it if
 you're lucky, but it's a bad idea.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15084: Unnecessary imports lead to ImportError

[Django]

#15084: Unnecessary imports lead to ImportError
--+
 Reporter:  vanschelven   |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Internationalization  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by vanschelven):

 * status:  closed => reopened
 * version:  1.2 => 1.4
 * resolution:  needsinfo =>


Comment:

 Ok, I'm reopening this as I finally acquired the understanding of what's
 really going wrong and managed to create an "easily" reproducible scenario
 (not so much test; but that's hard in the case of the current global app-
 loading anyway).

 Create 2 apps.

 {{{
 # defining_app/__init__.py
 from django.utils.translation import ugettext

 class TranslatedClass(object):
 value = ugettext("Field")
 }}}

 {{{
 # using_app/__init__.py
 from defining_app import TranslatedClass
 }}}

 Add them to INSTALLED_APPS as such (the order is important):

 {{{
 # settings.py

 INSTALLED_APPS = (
 # ...
 'using_app',
 'defining_app',
 )
 }}}

 This will fail in Django up to 1.4; but succeed with the patch provided by
 Jeff.

 Why?
 * Pretty much any Django command calls activate() somewhere. This will
 trigger the reverse loop over the INSTALLED_APPS. and will start importing
 apps
 
(https://github.com/django/django/blob/1.4/django/utils/translation/trans_real.py#L159)
 * defining_app is at the bottom of the list; it will be imported
 * When evaluating 'value = uggettext("Field")' we go into another reverse
 loop over INSTALLED_APPS as dictated by trans_real.py
 * By now 'defining_app' is in sys.modules, so that import statement
 doesn't trigger further evaluations
 * Next up in the loop: using_app.
 * using_app has an "from defining_app import !TranslatedClass" statement;
 however, since we're still somewhere on the stack of getting 'value',
 !TranslatedClass is not available yet.
 * !ImportError.

 In other words, the current implementation of uggettext sneaks in a
 dependency/call to all installed apps' __init__.py files. Additionally,
 because the import happens half-way in a class definition (a rather usual
 pattern in Django) the class definition cannot be finished in time for the
 using_module's code to access it.

 Why the solution works is simple: not importing modules at (for the user
 of Django) seemingly random moments will remove the dependency, and allow
 for !TranslatedClass to be added to the module's dictionary of available
 variables.

 I hope this reopens the issue for renewed attention. I _do_ consider this
 a serious issue, even though apparently not many people have found their
 way to this page or found a way to isolate the problem. I'd consider doing
 unasked-for imports something we need to do as little as possible (a.k.a.
 bad engineering). Especially the fact that uggettext() & friends may
 trigger this makes this a hairy bug: uggettext is often used in the middle
 of a module or class definition.

 As to the solution: I'm not sure about the corner cases but willing to
 help out. I'll start by providing a patch that deals with the known return
 values for get_loader.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13559: Need a contextprocessor for current site

[Django]

#13559: Need a contextprocessor for current site
---+--
 Reporter:  tonnzor|Owner:  krzysiumed
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by krzysiumed):

 * owner:  nobody => krzysiumed
 * cc: krzysiumed@… (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18514: Syncdb + Oracle + custom table name with quotes = Oracle 01741 error

[Django]

#18514: Syncdb + Oracle + custom table name with quotes = Oracle 01741 error
--+
 Reporter:  obmuc |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.2
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Using a custom table name with Oracle, and entering the full-qualified
 oracle schema + table name with quotes, is resulting in an Oracle 17141
 error when running syncdb: "illegal zero-length identifier". The all-
 knowing Google indicates this is due to an empty string ("") being passed
 to Oracle.

 Example Model:

 {{{
 class MyModel(models.Model):
 a_field = models.CharField(max_length=1000, blank=True, null=True)

 class Meta:
 db_table = u'"ORACLE_SCHEMA"."DESIRED_TABLE_NAME"'
 }}}

 Executing the syncdb management command to create that table results in
 the following:

 {{{
 $ ./manage.py syncdb
 Creating table "ORACLE_SCHEMA"."DESIRED_TABLE_NAME"
 Traceback (most recent call last):
   File "./manage.py", line 11, in 
 execute_manager(settings)
   File "[ intentionally obscured ]/lib/python2.6/site-
 packages/django/core/management/__init__.py", line 438, in execute_manager
 utility.execute()
   File "[ intentionally obscured ]/lib/python2.6/site-
 packages/django/core/management/__init__.py", line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "[ intentionally obscured ]/lib/python2.6/site-
 packages/django/core/management/base.py", line 191, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "[ intentionally obscured ]/lib/python2.6/site-
 packages/django/core/management/base.py", line 220, in execute
 output = self.handle(*args, **options)
   File "[ intentionally obscured ]/lib/python2.6/site-
 packages/django/core/management/base.py", line 351, in handle
 return self.handle_noargs(**options)
   File "[ intentionally obscured ]/lib/python2.6/site-
 packages/django/core/management/commands/syncdb.py", line 99, in
 handle_noargs
 cursor.execute(statement)
   File "[ intentionally obscured ]/lib/python2.6/site-
 packages/django/db/backends/util.py", line 15, in execute
 return self.cursor.execute(sql, params)
   File "[ intentionally obscured ]/lib/python2.6/site-
 packages/django/db/backends/oracle/base.py", line 595, in execute
 return self.cursor.execute(query, self._param_generator(params))
 django.db.utils.DatabaseError: ORA-01741: illegal zero-length identifier
 ORA-06512: at line 8
 }}}

 The table is otherwise usable with the Django ORM once created - just
 errors on attempt to create via syncdb.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15084: Unnecessary imports lead to ImportError

[Django]

#15084: Unnecessary imports lead to ImportError
-+-
 Reporter:  vanschelven  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.2
  Internationalization   |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by vanschelven):

 Just noting that no Django 1.4 jezdez' objection that pkgutil.get_loader
 isn't available in Python 2.4 is no longer relevant since that version of
 Python is not supported for 1.4 and up.


 If I'll ever get to reproducing the bug in a clean environment I'll post
 that here as well.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE

[Django]

#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.4
 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 Claude Paroz ):

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


Comment:

 In [531878302735e6a2b36d82b584947bbf8eae8111]:
 {{{
 #!CommitTicketReference repository=""
 revision="531878302735e6a2b36d82b584947bbf8eae8111"
 Fixed #17966 -- Isolated ProfileTestCase from custom AUTH_PROFILE_MODULE

 Thanks Rob Golding for helping on the patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 531878: Fixed #17966 -- Isolated ProfileTestCase from cust...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 531878302735e6a2b36d82b584947bbf8eae8111
  
https://github.com/django/django/commit/531878302735e6a2b36d82b584947bbf8eae8111
  Author: Claude Paroz 
  Date:   2012-06-25 (Mon, 25 Jun 2012)

  Changed paths:
M django/contrib/auth/tests/models.py

  Log Message:
  ---
  Fixed #17966 -- Isolated ProfileTestCase from custom AUTH_PROFILE_MODULE

Thanks Rob Golding for helping on the patch.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15197: yaml serialization to HttpResponse fails

[Django]

#15197: yaml serialization to HttpResponse fails
--+
 Reporter:  fourga38  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:  yaml  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * needs_tests:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16735: Queryset values should be aliasable

[Django]

#16735: Queryset values should be aliasable
-+-
 Reporter:  alex.latchford@… |Owner:  nate_b
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  queryset, alias, |  decision needed
  values |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by UloPe):

 * cc: django@… (added)


Comment:

 I would disagree with the observation that .values() is just an
 optimization. In combination with .annotate() it is vital if you need to
 annotate / group by multiple fields. This is also one of the use cases
 where the missing aliases are most painful.

 Example:
 {{{
 >>> Region.objects.values(
 "name",
 "orders__items__product__category__parent__name"
 ).annotate(quantity = Sum("orders__items__quantity"))
 [
 {'quantity': 10, 'name': u'...',
 'orders__items__product__category__parent__name': u'Something'},
 {'quantity': 20, 'name': u'...',
 'orders__items__product__category__parent__name': u'Something else'},
 ]
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15197: yaml serialization to HttpResponse fails

[Django]

#15197: yaml serialization to HttpResponse fails
--+
 Reporter:  fourga38  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:  yaml  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by hirokiky):

 * cc: hirokiky@… (added)
 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15716: The has_perm() method of authorization backends should be able to explicitly deny permission

[Django]

#15716: The has_perm() method of authorization backends should be able to
explicitly deny permission
--+
 Reporter:  Kronuz|Owner:  nobody
 Type:  New feature   |   Status:  reopened
Component:  contrib.auth  |  Version:
 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 aalbrecht):

 * cc: albrecht.andi@… (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17914: reverse() does not support namespaced view references

[Django]

#17914: reverse() does not support namespaced view references
-+-
 Reporter:  Bradley Ayers|Owner:  nobody
|   Status:  new
 Type:  Bug  |  Version:  master
Component:  Core (URLs)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Bradley Ayers ):

 I've updated the patch to maintain support for recursive urlconfs.
 https://github.com/django/django/pull/174

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18510: Options._fill_related_objects_cache should assert for app_cache_ready() or deal with app_cache_ready() == False

[Django]

#18510: Options._fill_related_objects_cache should assert for app_cache_ready() 
or
deal with app_cache_ready() == False
-+-
 Reporter:  vanschelven  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by vanschelven):

 * cc: vanschelven (added)
 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE

[Django]

#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 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 robgolding63):

 I've opened a pull request with a fix for this one:
 https://github.com/django/django/pull/36.

 I know the use of GitHub is new to the Django workflow and some things
 still need to be worked out, but I figured having it there waiting is the
 easiest way to show the changes. It's just a single commit, which I think
 fits with Django's current procedures.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18513: Python 3 support

[Django]

#18513: Python 3 support
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hi all,

 are there any plans for ObsPy Python 3 support.

 [http://www.michaelkorsweb.com/ Michael Kors Bags]

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.