date:20150423

Re: [Django] #24257: The trans template tag fails to get a message when there is a % character in the string

2015-04-23 Thread Django

#24257: The trans template tag fails to get a message when there is a % 
character
in the string
-+-
 Reporter:  aboudreault  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.7
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  trans templatetag| Triage Stage:  Accepted
  i18n   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by beck):

 This was the ticket I decided to tackle at the pycon sprints (claudep wish
 you were there so I could thank you in person for your patience on my
 previous pull... and this one too).

 This issue turned out to be quite difficult.  I've tried multiple
 approaches.

 == Long story short ==

 The simplest solution is to ensure that all translation messages that have
 a percent signs get python formatting.

  == Long story long  ==

 In an ideal world we would be able to use the template string (with it's
 curly brace variables) as our msgid.  Since that is not possible, template
 copy is coerced into a python formatted / sprintf string.

 This is a source of much pain and confusion, especially with percent
 signs.  Why?

 '''xgettext is awkward.'''

 xgettext will identify all python-format strings, example:

 {{{
 echo 'gettext("%s");' | xgettext --language=python --output=- -

 #, python-format
 msgid "%s"
 msgstr ""
 }}}

 This is all good.  It gets awkward when you pass it an invalid python fmt
 string, say:

 {{{
 echo 'gettext("%s costs 10%");' | xgettext --language=python --output=- -

 msgid "%s costs 10%"
 msgstr ""
 }}}

 This is awkward because the single `%` is seen as invalid python format
 and so the message id is not marked as we would expect.

 '''sprintf is awkward.'''

 Since humans are bad parsers, when I look at the format, `% %s` I see a
 percent followed by a string specifier. What this actually means a percent
 sign specifier, with a whitespace conversion flag, followed by an `s`
 character.

 Example:

 {{{
 >>> "% %s" % ()
 '%s'
 >>> "% 10%s" % ()
 ' %s'
 >>>
 }}}

 These two bits awkwardness in gettext and sprinf has caused some confusion
 as past developers have tried to shoehorn the template language into these
 technologies.

 Example:
 {{{
 {% blocktrans with a=1 %}Blocktrans extraction shouldn't double escape
 this: %%, a={{ a }}{% endblocktrans %}
 }}}

 The correct msgid is:
 {{{
 Blocktrans extraction shouldn't double escape this: , a=%(a)s
 }}}

 Not:
 {{{
 Blocktrans extraction shouldn't double escape this: %%, a={{ a }}
 }}}


  == The solution  ==

 First get some robust tests that capture all corner cases of awkwardness.
 I've added a sample app to the i18n tests to make it easier to write tests
 that evaluate extraction and translation using the same gettext catalogs.
 I then refactored tests addressing extraction and translation when a `%`
 is involved.

 Second, knock out any special handling of percents and ensure valid
 python-formatting on strings.

 Technically not all template strings with a percent should be python-
 formatted.  If the template was only `{% trans "10%" %}` this could go
 into the gettext catalog with msgid `10%` but such things is not possible
 with how `blocktrans` is rendered.

 When using `trans` and `blocktrans` with the same copy, the two should
 always extract the same msgid and render identically.

 The pull: https://github.com/django/django/pull/4549

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

[Django] #24695: URL regex has unnecessary _

2015-04-23 Thread Django

#24695: URL regex has unnecessary _
---+
 Reporter:  datakid|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 On this page:

 https://docs.djangoproject.com/en/1.8/ref/class-based-views/generic-
 display/

 Under myapps/urls.py in the DetailView

 ...

 {{{

 urlpatterns = [
 url(r'^(?P[-_\w]+)/$', ArticleDetailView.as_view(), name
 ='article-detail'),
 ]
 }}}



 The _ is unnecessary, as it's already in \w

 The regex should read

 {{{

 ?P[-\w]+
 }}}

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

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

Comment (by jarshwah):

I agree with your analysis shaib. I've just tried a few things to see if I
can work around the problem, but no I can't. Adding the extra clause at
the end of the .values().annotate() also drops the extra, which is
somewhat concerning, but it wouldn't work anyway.

> Well, there will always be edge cases where any ORM will not work, I
guess.

Yes, and that is why users can now build their own expressions with full
support of the ORM.

At a maximum we could maybe document that extra does not play well with
aggregation, but I can't see us implementing a fix here without turning
"extra" into the new expressions api anyway.

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

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
-+-
 Reporter:  jdelic   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (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 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/064.38233a3c3ec1b60b42437c9da4afffec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24649: Allow using the Avg aggregate on non-numeric field types

2015-04-23 Thread Django

#24649: Allow using the Avg aggregate on non-numeric field types
-+-
 Reporter:  Batou81  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/4548 PR]

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

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

Re: [Django] #24694: Add support for OPTIONS['context_processors'] to Jinja2 template backend

2015-04-23 Thread Django

#24694: Add support for OPTIONS['context_processors'] to Jinja2 template backend
-+
 Reporter:  carljm   |Owner:  nobody
 Type:  New feature  |   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):

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

Re: [Django] #24694: Add support for OPTIONS['context_processors'] to Jinja2 template backend

2015-04-23 Thread Django

#24694: Add support for OPTIONS['context_processors'] to Jinja2 template backend
-+--
 Reporter:  carljm   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  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
-+--
Description changed by carljm:

Old description:

> Conclusion from IRC discussion: There are advantages to being explicit
> about request-dependence in the template (which context processors are
> not), but there's currently no convenient alternative to context
> processors for computing a non-trivial request-dependent value that you
> want computed only once per template render (and not at all if no
> template is rendered). And even if we don't like context processors as an
> API, they have strong precedent in Django, so people will probably find a
> way to use them regardless (e.g. using django-jinja instead of the built-
> in Jinja2 backend).
>
> They could be added as a top-level cross-backend feature, but since in
> 1.8 they already exist as a DTL-specific feature in `OPTIONS`, they
> should be added to the Jinja2 backend the same way.
>
> Full IRC discussion transcript below. It's long, but seems useful to more
> fully document the thinking here for posterity:
>
> ```
> 18:35 <+carljm> mYk: I'm upgrading a project to Django 1.8, and I am
> wondering if we were wrong to not provide context processors for Jinja.
> 18:35 <+carljm> IIRC the rationale was something like "you don't need
> them in Jinja because you can just put stuff into the env globals
> directly", but this isn't really true - the point of
> context processors is that they provide request-specific values, and
> there's no obvious way to do that.
> 18:37 <+carljm> You can emulate by putting a function into the context
> that returns some value, but then you have inefficiency if that function
> does something non-trivial and its value is used in
> multiple places.
> 18:37 <+carljm> For a concrete example, this project wants a serialized
> (i.e. to primitive values), JSON-serializable representation of
> request.user to be available in all templates.
> 18:38 <+carljm> In 1.7 this was done with a context processor that
> provided that representation in a `me` variable.
> 18:39 <+carljm> In 1.8, without some context-processor equivalent, that
> would have to become `me(request)` or `request|me` or something, and to
> avoid serializing multiple times needlessly, it would
> often turn into `{% set me = me(request) %}`
> 18:40 <+carljm> In looking into this, I also noticed that Flask does
> provide context processors (just like Django's) atop Jinja2.
> 18:41 <+carljm> At the moment, I'm implementing context processors for
> the Django Jinja2 backend. It's not hard, but unfortunately requires
> copying most of the implementation of the Jinja2 backend
> and its Template wrapper (they aren't really factored for subclass
> customization)
> 18:41 <+carljm> I'd be very interested to hear if you think that I'm
> Doing it Wrong and there's a better option available for this type of use
> case.
> 18:43 <+carljm> Or if I'm not wrong, perhaps we should consider adding
> support for OPTIONS['context_processors'] to the Jinja2 backend for 1.9.
> 18:46 <+carljm> Or at least make it easier to subclass the backend and
> add that support. Specifically, this would mean factoring out an
> "instantiate_template" (name to-be-bikeshedded) internal
> method on the backend class, which would be called by both from_string
> and get_template, and which would allow a subclass to
> easily swap out both the Template wrapper class used and the arguments
> passed to it.
> 18:50 <+carljm> (Actually with @jinja2.contextfunction you could remove
> the explicit naming of the request in the above examples, but the other
> issues still apply.)
> 18:51 <+jezdez> carljm: doesn’t django-jinja support ctx processors
> natively?
> 18:52 <+jezdez> not that it answers your questions above, just something
> that may buy you quicker results
> 18:54 <+carljm> jezdez: So does jingo (which is what we were using on
> 1.7)
> 18:55 <+carljm> Unfortunately jingo isn't 1.8-compatible (due to its use
> of template internals that changed in 1.8); do you know if
> django-jinja is?
> 18:55 <+carljm> In any case, part of the goal of this upgrade was to
>

[Django] #24694: Add support for OPTIONS['context_processors'] to Jinja2 template backend

2015-04-23 Thread Django

#24694: Add support for OPTIONS['context_processors'] to Jinja2 template backend
---+
   Reporter:  carljm   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  Template system  |Version:  master
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Conclusion from IRC discussion: There are advantages to being explicit
 about request-dependence in the template (which context processors are
 not), but there's currently no convenient alternative to context
 processors for computing a non-trivial request-dependent value that you
 want computed only once per template render (and not at all if no template
 is rendered). And even if we don't like context processors as an API, they
 have strong precedent in Django, so people will probably find a way to use
 them regardless (e.g. using django-jinja instead of the built-in Jinja2
 backend).

 They could be added as a top-level cross-backend feature, but since in 1.8
 they already exist as a DTL-specific feature in `OPTIONS`, they should be
 added to the Jinja2 backend the same way.

 Full IRC discussion transcript below. It's long, but seems useful to more
 fully document the thinking here for posterity:

 ```
 18:35 <+carljm> mYk: I'm upgrading a project to Django 1.8, and I am
 wondering if we were wrong to not provide context processors for Jinja.
 18:35 <+carljm> IIRC the rationale was something like "you don't need them
 in Jinja because you can just put stuff into the env globals
 directly", but this isn't really true - the point of
 context processors is that they provide request-specific values, and
 there's no obvious way to do that.
 18:37 <+carljm> You can emulate by putting a function into the context
 that returns some value, but then you have inefficiency if that function
 does something non-trivial and its value is used in
 multiple places.
 18:37 <+carljm> For a concrete example, this project wants a serialized
 (i.e. to primitive values), JSON-serializable representation of
 request.user to be available in all templates.
 18:38 <+carljm> In 1.7 this was done with a context processor that
 provided that representation in a `me` variable.
 18:39 <+carljm> In 1.8, without some context-processor equivalent, that
 would have to become `me(request)` or `request|me` or something, and to
 avoid serializing multiple times needlessly, it would
 often turn into `{% set me = me(request) %}`
 18:40 <+carljm> In looking into this, I also noticed that Flask does
 provide context processors (just like Django's) atop Jinja2.
 18:41 <+carljm> At the moment, I'm implementing context processors for the
 Django Jinja2 backend. It's not hard, but unfortunately requires
 copying most of the implementation of the Jinja2 backend
 and its Template wrapper (they aren't really factored for subclass
 customization)
 18:41 <+carljm> I'd be very interested to hear if you think that I'm Doing
 it Wrong and there's a better option available for this type of use
 case.
 18:43 <+carljm> Or if I'm not wrong, perhaps we should consider adding
 support for OPTIONS['context_processors'] to the Jinja2 backend for 1.9.
 18:46 <+carljm> Or at least make it easier to subclass the backend and add
 that support. Specifically, this would mean factoring out an
 "instantiate_template" (name to-be-bikeshedded) internal
 method on the backend class, which would be called by both from_string
 and get_template, and which would allow a subclass to
 easily swap out both the Template wrapper class used and the arguments
 passed to it.
 18:50 <+carljm> (Actually with @jinja2.contextfunction you could remove
 the explicit naming of the request in the above examples, but the other
 issues still apply.)
 18:51 <+jezdez> carljm: doesn’t django-jinja support ctx processors
 natively?
 18:52 <+jezdez> not that it answers your questions above, just something
 that may buy you quicker results
 18:54 <+carljm> jezdez: So does jingo (which is what we were using on 1.7)
 18:55 <+carljm> Unfortunately jingo isn't 1.8-compatible (due to its use
 of template internals that changed in 1.8); do you know if
 django-jinja is?
 18:55 <+carljm> In any case, part of the goal of this upgrade was to
 switch from an external Jinja support package to the native support, so
 I'll probably continue on this path. Already done with
 adding context

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
-+-
 Reporter:  jdelic   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (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 shaib):

 So, I see two separate issues here.

 The first is that `period` was not selected in the original query. That, I
 think, is exactly expected behavior -- that's what `values()` does.

 The second is that, as demonstrated by adding `"period"` to the `values()`
 call, `extra()` does not support aggregates well (the error is caused by
 the ORM assuming that `period` is a non-aggregate field, and so must be
 pulled into the group-by clause for the aggregate to work). This, AFAICT,
 cannot be solved without adding to `extra()` an argument (or a sub-
 argument) to specify which of the `select` keys are aggregates; and that,
 combined with Tim's comments above, makes me think this should be
 wontfix'd.

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

Re: [Django] #16508: Provide real support for virtual fields

2015-04-23 Thread Django

Comment (by collinanderson):

I believe in the _meta refactor we simply defined it as "doesn't add or
alter columns in the database.", something like field.column = None. It
probably does correlates to one or multiple concrete fields, but it
doesn't have to.

Also, one thing to note is that we don't want to distinguish (too much)
between virtual and non virtual on the higher levels of the API (like
Model Forms). Model Forms shouldn't care whether a field has a column in
the database or not. So in that case, it doesn't make sense to have a
_meta.virtual_fields like we used to do. But of course the ORM and
migrations are going to want to know that they should ignore these fields.

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

Re: [Django] #24526: Default logging config filters out anything below ERROR for django.request/django.security loggers

2015-04-23 Thread Django

#24526: Default logging config filters out anything below ERROR for
django.request/django.security loggers
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  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 timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/4389 PR] is now ready for review.

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

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

Re: [Django] #16508: Provide real support for virtual fields

2015-04-23 Thread Django

#16508: Provide real support for virtual fields
-+-
 Reporter:  vzima|Owner:  pirosb3
 Type:  New feature  |   Status:  assigned
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 nemesisdesign):

 I am also interested in this ticket.

 See this other discussion on Django Developers:
 https://groups.google.com/forum/#!topic/django-developers/_FmJRK3sJGs].

 What's the proposed definition of `VirtualField`?

 I have a proposal:

 **"A virtual field is a model field which it correlates to one or multiple
 concrete fields, but doesn't add or alter columns in the database."**

 Best regards
 Federico

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

Re: [Django] #24693: Add model Options.label property

2015-04-23 Thread Django

#24693: Add model Options.label property
-+-
 Reporter:  timgraham|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:  1|UI/UX:  0
-+-

Comment (by aaugustin):

 Yes please!

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

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
-+-
 Reporter:  jdelic   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (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):

 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Right, but `values()` limits the select to only those fields so to me it's
 not surprising that this doesn't work. We can accept the ticket in case
 someone cares to write a patch (doc or code), but as I mentioned before, I
 don't think it's useful to spend more time on `extra()` at this point.

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

Re: [Django] #24689: DetailView get_template_name and get_context_object_name fail with deferred QuerySet (was: DetailView & ListView get_template_name and get_context_object_name fail with deferred Q

2015-04-23 Thread Django

#24689: DetailView get_template_name and get_context_object_name fail with 
deferred
QuerySet
-+
 Reporter:  BertrandBordage  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Old description:

> Suppose you define a view like this:
>
> {{{
> from django.views.generic import DetailView
> from django.contrib.auth.models import User
>
> class UserDetail(DetailView):
> model = User
> queryset = User.objects.defer('password')
> }}}
>
> If you try to use the view, the default template name is
> {{{auth/user_deferred_password_detail.html}}} instead of
> {{{auth/user_detail.html}}}.
>
> This is because Django creates a proxy model each time you use
> defer/only. And therefore
> {{{User.objects.defer('password')[0]._meta.model_name}}} is
> {{{'user_deferred_password'}}}.
>
> {{{(DetailView|ListView).get_template_name}}} should ckeck if
> {{{model._deferred}}} and use {{{model._meta.proxy_for_model}}} to get
> the original model.

New description:

 Suppose you define a view like this:

 {{{
 from django.views.generic import DetailView
 from django.contrib.auth.models import User

 class UserDetail(DetailView):
 model = User
 queryset = User.objects.defer('password')
 }}}

 If you try to use the view, the default template name is
 {{{auth/user_deferred_password_detail.html}}} instead of
 {{{auth/user_detail.html}}}.

 This is because Django creates a proxy model each time you use defer/only.
 And therefore {{{User.objects.defer('password')[0]._meta.model_name}}} is
 {{{'user_deferred_password'}}}.

 {{{DetailView.get_template_name}}} should ckeck if {{{model._deferred}}}
 and use {{{model._meta.proxy_for_model}}} to get the original model.

--

Comment (by BertrandBordage):

 Indeed, it’s not occurring using ListView. I assumed it would occur on it
 because I thought {{{User.objects.defer('password')}}} would be a queryset
 of the proxy model {{{User_Deferred_password}}}, but it’s not. It’s only
 once you get model instances that they use the proxy model.

 Sorry for not checking :(

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

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

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
-+-
 Reporter:  jdelic   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.8
  (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
-+-

Comment (by jdelic):

 > Looking at it a bit more, though, I noticed that period doesn't seem to
 be used in the values or in the annotate. Do you have a typo there?

 No, not a typo per se. Maybe a mistake, though. I'm basing this off the
 {{{is_recent}}} example in
 https://docs.djangoproject.com/en/1.8/ref/models/querysets/#extra, which
 also doesn't mention the field anywhere else. It might be worth mentioning
 that if you add {{{.values('service_id', 'period')}}} then the QuerySet
 will generate invalid SQL:

 {{{
 #!python
 >>> qs = ServiceAction.objects.extra(select={'period':
 
'(MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed"))'}).values('service_id',
 'period').annotate(first_action=Min('performed'),
 last_action=Max('performed'))
 >>> print(qs.query)
 SELECT
 
((MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed")))
 AS "period", "dbtest_serviceaction"."service_id",
 MAX("dbtest_serviceaction"."performed") AS "last_action",
 MIN("dbtest_serviceaction"."performed") AS "first_action" FROM
 "dbtest_serviceaction" GROUP BY "dbtest_serviceaction"."service_id",
 
((MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed")))
 >>> qs
 ...
 OperationalError: aggregate functions are not allowed in the GROUP BY
 clause
 }}}

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

Re: [Django] #24686: Support for Moving a model between two Django apps

2015-04-23 Thread Django

#24686: Support for Moving a model between two Django apps
-+
 Reporter:  cancan101|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by cancan101):

 @MarkusH Are you saying that the solution posted on SO won't work?
 I was suggesting the project level migrations to address the issues raised
 by @knbk so that the migrator could see both apps.

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

[Django] #24693: Add model Options.label property

2015-04-23 Thread Django

#24693: Add model Options.label property
-+-
   Reporter:  timgraham  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 There are many places in Django that construct a dotted path like this:
 `'%s.%s' % (model._meta.app_label, model._meta.object_name)`

 It would by DRYer to add a property to the Options class in
 django/db/models/options.py that returned the dotted path. I'm proposing
 the name "label".

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

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
-+-
 Reporter:  jdelic   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.8
  (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 timgraham):

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


Comment:

 We can accept the ticket and see if someone cares to fix it, but even if
 fixed it won't be backported to 1.6 or 1.7.

 Looking at it a bit more, though, I noticed that `period` doesn't seem to
 be used in the values or in the annotate. Do you have a typo there?

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

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
---+--
 Reporter:  jdelic |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by jdelic):

 Replying to [comment:4 timgraham]:
 > Not that this fixes the problem, but we are trying to obsolete
 `.extra()` by providing better APIs for all its use cases. Do you have a
 use case in mind where the new expressions API doesn't suffice? If so, I
 think there will be more interest in working on that instead of fixing
 bugs with `.extra()` which seems likely to be deprecated at some point.

 Well, there will always be edge cases where any ORM will not work, I
 guess. In my case the new expressions API *would suffice*, unfortunately
 we run a rather big project on Django 1.6.11, migrating to 1.7... so I
 won't be able to use it for a while.

 In any case, I ran into this while trying to generate some much more
 complex reports from our database. As {{{.extra()}}} hasn't been
 deprecated yet and I was able to boil it down to such a simple failure
 case, I think fixing it would still be a very good idea. I feel that if
 {{{.extra()}}} fails silently on such a simple case, there are bound to be
 other "more legitimate" use-cases that will fail as well. That said, I
 haven't investigated Django's code itself, so this might also just be a
 very narrow failure mode.

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

Re: [Django] #24267: Simplify Query.build_filter()

2015-04-23 Thread Django

#24267: Simplify Query.build_filter()
-+-
 Reporter:  akaariai |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
 * has_patch:  1 => 0


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

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

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
---+--
 Reporter:  jdelic |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by jdelic:

Old description:

> Here is a minimal example:
> {{{
> #!python
> from django.db import models
>
> class Service(models.Model):
> name = models.TextField()
>
> class ServiceAction(models.Model):
> performed = models.DateTimeField(auto_now_add=True)
> service = models.ForeignKey(Service)
> }}}
>
> Then add some models:
> {{{
> #!python
> >>> from dbtest.models import Service, ServiceAction
> >>> from django.db.models import Min, Max
> >>> s1 = Service.objects.create(name='test1')
> >>> s2 = Service.objects.create(name='test2')
> >>> ServiceAction.objects.create(service_id=s1.id)
> >>> ServiceAction.objects.create(service_id=s1.id)
> >>> ServiceAction.objects.create(service_id=s1.id)
> >>> ServiceAction.objects.create(service_id=s2.id)
> >>> ServiceAction.objects.create(service_id=s2.id)
> >>> ServiceAction.objects.create(service_id=s2.id)
> }}}
>
> ...and query them using aggregations:
> {{{
> #!python
> >>> qs = ServiceAction.objects.extra(select={'period':
> '(MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed"))'}).values('service_id').annotate(first_action=Min('performed'),
> last_action=Max('performed'))
> >>> print(qs.query)
> SELECT "dbtest_serviceaction"."service_id",
> MAX("dbtest_serviceaction"."performed") AS "last_action",
> MIN("dbtest_serviceaction"."performed") AS "first_action" FROM
> "dbtest_serviceaction" GROUP BY "dbtest_serviceaction"."service_id"
> }}}
>
> As you can see the {{{.extra(select=...)}}} has been dropped from the
> query. I assume this happens on Django 1.6.x, 1.7.x and 1.8.x, but I have
> only tested 1.6.11 and 1.8.
>
> The expected outcome would have been:
>
> {{{
> SELECT "dbtest_serviceaction"."service_id",
> MAX("dbtest_serviceaction"."performed") AS "last_action",
> MIN("dbtest_serviceaction"."performed") AS "first_action",
> MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed")
> as "period" FROM "dbtest_serviceaction" GROUP BY
> "dbtest_serviceaction"."service_id"
> }}}
>
> In Django 1.8 this exact query can be performed with the ORM itself
> through the use of chained aggregations:
>
> {{{
> #!python
> >>> qs =
> ServiceAction.objects.values('service_id').annotate(first_action=Min('performed'),
> last_action=Max('performed'), period=Max('performed')-Min('performed'))
> >>> print(qs.query)
> SELECT "dbtest_serviceaction"."service_id",
> (MAX("dbtest_serviceaction"."performed") -
> MIN("dbtest_serviceaction"."performed")) AS "period",
> MAX("dbtest_serviceaction"."performed") AS "last_action",
> MIN("dbtest_serviceaction"."performed") AS "first_action" FROM
> "dbtest_serviceaction" GROUP BY "dbtest_serviceaction"."service_id"
> }}}

New description:

 Here is a minimal example:
 {{{
 #!python
 from django.db import models

 class Service(models.Model):
 name = models.TextField()

 class ServiceAction(models.Model):
 performed = models.DateTimeField(auto_now_add=True)
 service = models.ForeignKey(Service)
 }}}

 Then add some models:
 {{{
 #!python
 >>> from dbtest.models import Service, ServiceAction
 >>> from django.db.models import Min, Max
 >>> s1 = Service.objects.create(name='test1')
 >>> s2 = Service.objects.create(name='test2')
 >>> ServiceAction.objects.create(service_id=s1.id)
 >>> ServiceAction.objects.create(service_id=s1.id)
 >>> ServiceAction.objects.create(service_id=s1.id)
 >>> ServiceAction.objects.create(service_id=s2.id)
 >>> ServiceAction.objects.create(service_id=s2.id)
 >>> ServiceAction.objects.create(service_id=s2.id)
 }}}

 ...and query them using aggregations:
 {{{
 #!python
 >>> qs = ServiceAction.objects.extra(select={'period':
 
'(MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed"))'}).values('service_id').annotate(first_action=Min('performed'),
 last_action=Max('performed'))
 >>> print(qs.query)
 SELECT "dbtest_serviceaction"."service_id",
 MAX("dbtest_serviceaction"."performed") AS "last_action",
 MIN("dbtest_serviceaction"."performed") AS "first_action" FROM
 "dbtest_serviceaction" GROUP BY "dbtest_serviceaction"."service_id"
 }}}

 As you can see the {{{.extra(select=...)}}} has been dropped from the
 query. I assume this happens on Django 1.6.x, 1.7.x and 1.8.x, but I have
 only tested

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
---+--
 Reporter:  jdelic |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by timgraham):

 Not that this fixes the problem, but we are trying to obsolete `.extra()`
 by providing better APIs for all its use cases. Do you have a use case in
 mind where the new expressions API doesn't suffice? If so, I think there
 will be more interest in working on that instead of fixing bugs with
 `.extra()` which seems likely to be deprecated at some point.

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

Re: [Django] #4960: Add "strip" keyword argument to CharField constructor

2015-04-23 Thread Django

#4960: Add "strip" keyword argument to CharField constructor
-+
 Reporter:  tzellman@…   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  CharField strip  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * status:  closed => new
 * 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/076.58d274e48e21d581dc77b00226388d2d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24691: Document model._state.adding (since UUIDField sets value before save) (was: UUIDField sets value before save)

2015-04-23 Thread Django

#24691: Document model._state.adding (since UUIDField sets value before save)
--+
 Reporter:  MattBlack85   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:  uuid UUIDField| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

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


Comment:

 We should likely document `model._state.adding`. See #24377 for a patch
 where we had to adapt the admin.

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

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
---+--
 Reporter:  jdelic |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by mbertheau):

 * cc: mbertheau@… (added)


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

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

Re: [Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
---+--
 Reporter:  jdelic |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by jdelic):

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


Old description:

> Here is a minimal example:
> {{{
> #!python
> from django.db import models
>
> class Service(models.Model):
> name = models.TextField()
>
> class ServiceAction(models.Model):
> performed = models.DateTimeField(auto_now_add=True)
> service = models.ForeignKey(Service)
> }}}
>
> Then add some models:
> {{{
> #!python
> >>> from dbtest.models import Service, ServiceAction
> >>> from django.db.models import Min, Max
> >>> s1 = Service.objects.create(name='test1')
> >>> s2 = Service.objects.create(name='test2')
> >>> ServiceAction.objects.create(service_id=1)
> >>> ServiceAction.objects.create(service_id=1)
> >>> ServiceAction.objects.create(service_id=1)
> >>> ServiceAction.objects.create(service_id=2)
> >>> ServiceAction.objects.create(service_id=2)
> >>> ServiceAction.objects.create(service_id=2)
> }}}
>
> ...and query them using aggregations:
> {{{
> #!python
> >>> qs = ServiceAction.objects.extra(select={'period':
> '(MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed"))'}).values('service_id').annotate(first_action=Min('performed'),
> last_action=Max('performed'))
> >>> print(qs.query)
> SELECT "dbtest_serviceaction"."service_id",
> MAX("dbtest_serviceaction"."performed") AS "last_action",
> MIN("dbtest_serviceaction"."performed") AS "first_action" FROM
> "dbtest_serviceaction" GROUP BY "dbtest_serviceaction"."service_id"
> }}}
>
> As you can see the {{{.extra(select=...)}}} has been dropped from the
> query. I assume this happens on Django 1.6.x, 1.7.x and 1.8.x, but I have
> only tested 1.6.11 and 1.8.
>
> The expected outcome would have been:
>
> {{{
> SELECT "dbtest_serviceaction"."service_id",
> MAX("dbtest_serviceaction"."performed") AS "last_action",
> MIN("dbtest_serviceaction"."performed") AS "first_action",
> MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed")
> as "period" FROM "dbtest_serviceaction" GROUP BY
> "dbtest_serviceaction"."service_id"
> }}}
>
> In Django 1.8 this exact query can be performed with the ORM itself
> through the use of chained aggregations:
>
> {{{
> #!python
> >>> qs =
> ServiceAction.objects.values('service_id').annotate(first_action=Min('performed'),
> last_action=Max('performed'), period=Max('performed')-Min('performed'))
> >>> print(qs.query)
> SELECT "dbtest_serviceaction"."service_id",
> (MAX("dbtest_serviceaction"."performed") -
> MIN("dbtest_serviceaction"."performed")) AS "period",
> MAX("dbtest_serviceaction"."performed") AS "last_action",
> MIN("dbtest_serviceaction"."performed") AS "first_action" FROM
> "dbtest_serviceaction" GROUP BY "dbtest_serviceaction"."service_id"
> }}}

New description:

 Here is a minimal example:
 {{{
 #!python
 from django.db import models

 class Service(models.Model):
 name = models.TextField()

 class ServiceAction(models.Model):
 performed = models.DateTimeField(auto_now_add=True)
 service = models.ForeignKey(Service)
 }}}

 Then add some models:
 {{{
 #!python
 >>> from dbtest.models import Service, ServiceAction
 >>> from django.db.models import Min, Max
 >>> s1 = Service.objects.create(name='test1')
 >>> s2 = Service.objects.create(name='test2')
 >>> ServiceAction.objects.create(service_id=s1.id)
 >>> ServiceAction.objects.create(service_id=s1.id)
 >>> ServiceAction.objects.create(service_id=s1.id)
 >>> ServiceAction.objects.create(service_id=s2.id)
 >>> ServiceAction.objects.create(service_id=s2.id)
 >>> ServiceAction.objects.create(service_id=s2.id)
 }}}

 ...and query them using aggregations:
 {{{
 #!python
 >>> qs = ServiceAction.objects.extra(select={'period':
 
'(MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed"))'}).values('service_id').annotate(first_action=Min('performed'),
 last_action=Max('performed'))
 >>> print(qs.query)
 SELECT "dbtest_serviceaction"."service_id",
 MAX("dbtest_serviceaction"."performed") AS "last_action",
 MIN("dbtest_serviceaction"."performed") AS "first_action" FROM
 "dbtest_serviceaction" GROUP BY "dbtest_serviceaction"."service_id"
 }}}

 As you can see the {{{.extra(select=...)}}} has been dropped from the
 query. I assume this happens on Django 1.6.x,

[Django] #24692: QuerySet.extra(select=...) is silently dropped with aggregations

2015-04-23 Thread Django

#24692: QuerySet.extra(select=...) is silently dropped with aggregations
---+
 Reporter:  jdelic |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Here is a minimal example:
 {{{
 #!python
 from django.db import models

 class Service(models.Model):
 name = models.TextField()

 class ServiceAction(models.Model):
 performed = models.DateTimeField(auto_now_add=True)
 service = models.ForeignKey(Service)
 }}}

 Then add some models:
 {{{
 #!python
 >>> from dbtest.models import Service, ServiceAction
 >>> from django.db.models import Min, Max
 >>> s1 = Service.objects.create(name='test1')
 >>> s2 = Service.objects.create(name='test2')
 >>> ServiceAction.objects.create(service_id=1)
 >>> ServiceAction.objects.create(service_id=1)
 >>> ServiceAction.objects.create(service_id=1)
 >>> ServiceAction.objects.create(service_id=2)
 >>> ServiceAction.objects.create(service_id=2)
 >>> ServiceAction.objects.create(service_id=2)
 }}}

 ...and query them using aggregations:
 {{{
 #!python
 >>> qs = ServiceAction.objects.extra(select={'period':
 
'(MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed"))'}).values('service_id').annotate(first_action=Min('performed'),
 last_action=Max('performed'))
 >>> print(qs.query)
 SELECT "dbtest_serviceaction"."service_id",
 MAX("dbtest_serviceaction"."performed") AS "last_action",
 MIN("dbtest_serviceaction"."performed") AS "first_action" FROM
 "dbtest_serviceaction" GROUP BY "dbtest_serviceaction"."service_id"
 }}}

 As you can see the {{{.extra(select=...)}}} has been dropped from the
 query. I assume this happens on Django 1.6.x, 1.7.x and 1.8.x, but I have
 only tested 1.6.11 and 1.8.

 The expected outcome would have been:

 {{{
 SELECT "dbtest_serviceaction"."service_id",
 MAX("dbtest_serviceaction"."performed") AS "last_action",
 MIN("dbtest_serviceaction"."performed") AS "first_action",
 MAX("dbtest_serviceaction"."performed")-MIN("dbtest_serviceaction"."performed")
 as "period" FROM "dbtest_serviceaction" GROUP BY
 "dbtest_serviceaction"."service_id"
 }}}

 In Django 1.8 this exact query can be performed with the ORM itself
 through the use of chained aggregations:

 {{{
 #!python
 >>> qs =
 
ServiceAction.objects.values('service_id').annotate(first_action=Min('performed'),
 last_action=Max('performed'), period=Max('performed')-Min('performed'))
 >>> print(qs.query)
 SELECT "dbtest_serviceaction"."service_id",
 (MAX("dbtest_serviceaction"."performed") -
 MIN("dbtest_serviceaction"."performed")) AS "period",
 MAX("dbtest_serviceaction"."performed") AS "last_action",
 MIN("dbtest_serviceaction"."performed") AS "first_action" FROM
 "dbtest_serviceaction" GROUP BY "dbtest_serviceaction"."service_id"
 }}}

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

Re: [Django] #24686: Support for Moving a model between two Django apps

2015-04-23 Thread Django

Comment (by MarkusH):

Referring back to the [http://stackoverflow.com/a/26472482 example
solution from SO]:

As soon as you remove the `old_app` from installed apps and apply the
migrations on an empty database the `SeparateDatabaseAndState` operation
in `new_app` will **only** create the model in memory but **no database
table**. Therefore it's not an option to migrate data between apps to get
rid of one app it this simple form.

Replying to [comment:4 cancan101]:
> Crazy question, but what about project level migrations?

What about them? You can define `settings.MIGRATION_MODULES` and put all
app migrations in your project. But I advice you to not do that unless
there is a 3rd party app that doesn't have Django migration support. Then
this is the way to go to add migrations for that particular app.

Replying to [comment:3 knbk]:
> I do have some concerns about dependencies. If the migration lives in
the old app, the autodetector won't be able to detect that the next
migration in the new app depends on the `RenameModel` migration in the old
app. Likewise, if the migration lives in the new app, the next migration
in the old app won't have a dependency on the migration that moves the
model. The last case ''might'' not be a problem, but I can't say that off
the top of my head.

Sounds about right to me. You will eventually run into a hellhole of
dependencies.

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

Re: [Django] #24665: Model field relational attributes are None by default, not False

2015-04-23 Thread Django

#24665: Model field relational attributes are None by default, not False
-+-
 Reporter:  MarkusH  |Owner:  honya121
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 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 timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/4540 PR]

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

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

Re: [Django] #24607: dumpdata (with natural keys) / loaddata failure for model inheriting from User

2015-04-23 Thread Django

#24607: dumpdata (with natural keys) / loaddata failure for model inheriting 
from
User
--+
 Reporter:  denys-duchier |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.8
 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 timgraham):

 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.071024ab39f167fcfe41d3b2ecbee1f7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24375: Add ability to mark migration as "part of initial" in Migration

2015-04-23 Thread Django

#24375: Add ability to mark migration as "part of initial" in Migration
-+
 Reporter:  haeric   |Owner:  akulakov
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  fake migrations  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/4420 PR]

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

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

Re: [Django] #24063: Locale code validation too strict

2015-04-23 Thread Django

#24063: Locale code validation too strict
--+
 Reporter:  nijel |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  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 timgraham):

 * needs_better_patch:  1 => 0


Comment:

 Claude, could you check the pull request now?

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

Re: [Django] #22938: clearsessions not remore session files from tmp

2015-04-23 Thread Django

#22938: clearsessions not remore session files from tmp
--+
 Reporter:  atarkowska@…  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.6
 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 timgraham):

 * needs_tests:  1 => 0


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

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

Re: [Django] #22981: Fields with auto_now=True are not updated if the field name is not present in update_fields list passed into Model.save

2015-04-23 Thread Django

#22981: Fields with auto_now=True are not updated if the field name is not 
present
in update_fields list passed into Model.save
-+-
 Reporter:  jscn |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Is there a problem with the suggestion of using a database default for
 your use case? I don't think more "auto" options are desired considering
 there has been some though to deprecate them (#22995).

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

Re: [Django] #24689: DetailView & ListView get_template_name and get_context_object_name fail with deferred QuerySet

2015-04-23 Thread Django

#24689: DetailView & ListView get_template_name and get_context_object_name fail
with deferred QuerySet
-+
 Reporter:  BertrandBordage  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

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

Re: [Django] #24676: Regression on ManytoMany representation in the admin interface

2015-04-23 Thread Django

#24676: Regression on ManytoMany representation in the admin interface
--+
 Reporter:  Etienne-Carriere  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.8
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by timgraham):

 Hm, the widget works fine for me and the selenium tests for it are
 passing. Any chance you are using a third-party app that might be causing
 the breakage? Can you clarify exactly what functionality isn't working or
 submit a patch with what change you think needs to be made?

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

[Django] #24691: UUIDField sets value before save

2015-04-23 Thread Django

#24691: UUIDField sets value before save
---+
 Reporter:  MattBlack85|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:  uuid UUIDField
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When using a pk I expect the behaviour we had in the past meaning that
 inside .save() method checking for self.pk gives me a clue of creation vs
 update (documentation confirms that
 https://docs.djangoproject.com/en/1.8/ref/models/instances/#how-django-
 knows-to-update-vs-insert). This is not working when using UUIDField since
 when we enter the save method the pk is already set to the default value.

 to reproduce
 {{{
 import uuid

 from django.db import models

 class AwesomeModel(models.Model):
 id = models.UUIDField(default=uuid.uuid4, primary_key=True)
 x = models.CharField(max_length=10)

 def save(self, *args, **kwargs):
 if self.pk:
 print("we have already a pk set")
 return super(AwesomeModel, self).save(*args, **kwargs)


 a = AwesomeModel(x='some')
 a.save()
 we have already a pk set
 }}}

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

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

Re: [Django] #24676: Regression on ManytoMany representation in the admin interface

2015-04-23 Thread Django

#24676: Regression on ManytoMany representation in the admin interface
--+
 Reporter:  Etienne-Carriere  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.8
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Etienne-Carriere):

 Yes, the bug is that the JS code in SelectFilter2 file is no more
 operationnal . I haven't see more side effects on the ManytoMany managment
 by the admin interface when migrating from 1.7 to 1.8 .

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

Re: [Django] #24676: Regression on ManytoMany representation in the admin interface

2015-04-23 Thread Django

#24676: Regression on ManytoMany representation in the admin interface
--+
 Reporter:  Etienne-Carriere  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.8
 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 Etienne-Carriere):

 * cc: Etienne-Carriere (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/074.67f08c9a2991a645271eee4da2cbe593%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it

2015-04-23 Thread Django

#24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it
-+-
 Reporter:  ssjunior |Owner:  ssjunior
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Looks good, please make it a pull request. It will need some tests,
 though.

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

Re: [Django] #24689: DetailView & ListView get_template_name and get_context_object_name fail with deferred QuerySet

2015-04-23 Thread Django

#24689: DetailView & ListView get_template_name and get_context_object_name fail
with deferred QuerySet
-+
 Reporter:  BertrandBordage  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  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 ArtisAvotins):

 Submitted a pull request on GitHub fixing this issue. Didn't occur when
 using ListView though. https://github.com/django/django/pull/4546

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

42 matches

Mail list logo