date:20150926

Re: [Django] #25469: Autoescape is not possible with Django 1.8 template refactor

2015-09-26 Thread Django

#25469: Autoescape is not possible with Django 1.8 template refactor
-+--
 Reporter:  aidanlister  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  templates| Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by aaugustin):

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


Comment:

 Can't you just keep using the same code? I don't think you should yet any
 deprecation warnings, do you?

 Also it may be reasonable to add and `autoescape` option to the Django
 template library, similar to Jinja2.

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

Re: [Django] #25475: Database function strftime with argument %W fails in 1.9a1

2015-09-26 Thread Django

#25475: Database function strftime with argument %W fails in 1.9a1
-+-
 Reporter:  vtbassmatt   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9a1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  func strftime| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 I think we need to re-escape % after executing `template % self.extra` in
 `Func.as_sql`.

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

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

Re: [Django] #25475: Database function strftime with argument %W fails in 1.9a1 (was: Database function srtftime with argument %W fails in 1.9a1)

2015-09-26 Thread Django

#25475: Database function strftime with argument %W fails in 1.9a1
-+-
 Reporter:  vtbassmatt   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9a1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  func strftime| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by vtbassmatt):

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


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

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

[Django] #25475: Database function srtftime with argument %W fails in 1.9a1

2015-09-26 Thread Django

#25475: Database function srtftime with argument %W fails in 1.9a1
--+---
 Reporter:  vtbassmatt|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9a1
 Severity:  Normal|   Keywords:  func strftime
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 I have a database function to annotate the week of a date. It worked in
 1.8 but breaks in 1.9a1, failing with a "ValueError: unsupported format
 character 'W'" exception.

 {{{
 class Week(Func):
 function = 'strftime'
 template = "%(function)s('%%W',%(expressions)s)"

 def data_last_n_weeks(user, week_count):
 assert week_count > 0, "week_count must be greater than 0"
 assert week_count < 52, "week_count must be less than 52"

 today = date.today()
 most_recent_monday = today - timedelta(days=(today.isoweekday()-1))
 start_date = most_recent_monday - timedelta(days=7*(week_count-1))

 data = user.serving_set.filter(date__range=(start_date, today)
 ).annotate(week=Week('date',
 output_field=IntegerField())).values(
 'week').annotate(amt=Sum('amount'), cost=Sum('cost'))

 return data
 }}}

 yields

 {{{
   File "/Users/[me]/Projects/[proj]/ENV/lib/python3.4/site-
 packages/django/db/backends/sqlite3/operations.py", line 133, in
 last_executed_query
 return sql % params
 ValueError: unsupported format character 'W' (0x57) at index 18
 }}}

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

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

Re: [Django] #25389: SimpleLazyObject doesn't pickle correctly when wrapping a Model

2015-09-26 Thread Django

#25389: SimpleLazyObject doesn't pickle correctly when wrapping a Model
-+-
 Reporter:  benjaminjkraft   |Owner:
 |  benjaminjkraft
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Left some small comments for improvement.

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

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

Re: [Django] #25469: Autoescape is not possible with Django 1.8 template refactor

2015-09-26 Thread Django

#25469: Autoescape is not possible with Django 1.8 template refactor
-+--
 Reporter:  aidanlister  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  templates| Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by aidanlister):

 So the background here is that I've got editable templates via a GUI for
 emails. The emails are plain text ... so forcing end-users to put {%
 autocomplete on %} at the top of every template seems pretty gross. Can we
 reevaluate this?

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

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

Re: [Django] #24323: Document that you cannot use @admin.register() with an init() super call that references the class name

2015-09-26 Thread Django

#24323: Document that you cannot use @admin.register() with an __init__() super
call that references the class name
--+
 Reporter:  eskhool   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 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 timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/5368 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.724731f77307549ddc49b9e2c121bf11%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25421: Twice run tests with --keepdb option in Oracle fails

2015-09-26 Thread Django

#25421: Twice run tests with --keepdb option in Oracle fails
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle test keepdb   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"6a0b4faf43db70a35163dde0a5ea626ed4129fa7" 6a0b4faf]:
 {{{
 #!CommitTicketReference repository=""
 revision="6a0b4faf43db70a35163dde0a5ea626ed4129fa7"
 [1.9.x] Fixed #25421 -- Fixed test --keepdb option on Oracle.

 Backport of a3a6def867c61d24dfded6cbfef7f820409dc739 from master
 }}}

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

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

Re: [Django] #25421: Twice run tests with --keepdb option in Oracle fails

2015-09-26 Thread Django

#25421: Twice run tests with --keepdb option in Oracle fails
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle test keepdb   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"cb2de5e2e983adb7b16a9978222d20e94286827e" cb2de5e2]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb2de5e2e983adb7b16a9978222d20e94286827e"
 [1.8.x] Fixed #25421 -- Fixed test --keepdb option on Oracle.

 Backport of a3a6def867c61d24dfded6cbfef7f820409dc739 from master
 }}}

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

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

Re: [Django] #25421: Twice run tests with --keepdb option in Oracle fails

2015-09-26 Thread Django

#25421: Twice run tests with --keepdb option in Oracle fails
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle test keepdb   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"a3a6def867c61d24dfded6cbfef7f820409dc739" a3a6def]:
 {{{
 #!CommitTicketReference repository=""
 revision="a3a6def867c61d24dfded6cbfef7f820409dc739"
 Fixed #25421 -- Fixed test --keepdb option on Oracle.
 }}}

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

Re: [Django] #25474: RelatedObjectDoesNotExist caused by Model.clean()

2015-09-26 Thread Django

#25474: RelatedObjectDoesNotExist caused by Model.clean()
---+--
 Reporter:  avorio |Owner:  nobody
 Type:  Bug|   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 claudep):

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


Comment:

 Might be a duplicate of #25431. Could you test with latest 1.8.x branch,
 or just apply 158b0a28374054b1c3f94a9602b69f93fc980448 in your django
 install?

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

[Django] #25474: RelatedObjectDoesNotExist caused by Model.clean()

2015-09-26 Thread Django

#25474: RelatedObjectDoesNotExist caused by Model.clean()
---+
 Reporter:  avorio |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hello,

 I'm not sure what's going on here.

 I have a model:

 {{{
 class Quote(models.Model):
 curation = models.ForeignKey(Curation)
 rental_period = models.PositiveSmallIntegerField('rental period
 (weeks)', null=True, blank=True,
 validators=[MinValueValidator(0),MaxValueValidator(260)])
 [...]

 @property
 def type(self):
 return self.curation.opportunity.type
 }}}

 And I decided to implement a validation using:

 {{{
 def clean(self):
 if self.type == 'rental':
 if self.rental_period is None:
 raise ValidationError({'rental_period': 'The rental period
 must be defined for rental quotes.'})
 }}}

 When I try to create a new Quote object in the admin, I now get a
 `RelatedObjectDoesNotExist` error saying `Quote has no curation` when I
 don't select any `curation` from the dropdown menu displayed. When I
 remove my `clean()` function and still do not select any `curation`, I get
 the normal error message in the admin UI.

 Here's the full traceback:

 {{{
 Traceback:
 File "/.venv/lib/python3.4/site-packages/django/core/handlers/base.py" in
 get_response
   132. response = wrapped_callback(request,
 *callback_args, **callback_kwargs)
 File "/.venv/lib/python3.4/site-packages/django/contrib/admin/options.py"
 in wrapper
   616. return self.admin_site.admin_view(view)(*args,
 **kwargs)
 File "/.venv/lib/python3.4/site-packages/django/utils/decorators.py" in
 _wrapped_view
   110. response = view_func(request, *args, **kwargs)
 File "/.venv/lib/python3.4/site-packages/django/views/decorators/cache.py"
 in _wrapped_view_func
   57. response = view_func(request, *args, **kwargs)
 File "/.venv/lib/python3.4/site-packages/django/contrib/admin/sites.py" in
 inner
   233. return view(request, *args, **kwargs)
 File "/maestro/quotes/admin.py" in add_view
   44. return super(QuoteAdmin, self).add_view(request, form_url,
 extra_context)
 File "/.venv/lib/python3.4/site-packages/django/contrib/admin/options.py"
 in add_view
   1516. return self.changeform_view(request, None, form_url,
 extra_context)
 File "/.venv/lib/python3.4/site-packages/django/utils/decorators.py" in
 _wrapper
   34. return bound_func(*args, **kwargs)
 File "/.venv/lib/python3.4/site-packages/django/utils/decorators.py" in
 _wrapped_view
   110. response = view_func(request, *args, **kwargs)
 File "/.venv/lib/python3.4/site-packages/django/utils/decorators.py" in
 bound_func
   30. return func.__get__(self, type(self))(*args2,
 **kwargs2)
 File
 "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/contextlib.py"
 in inner
   30. return func(*args, **kwds)
 File "/.venv/lib/python3.4/site-packages/django/contrib/admin/options.py"
 in changeform_view
   1459. if form.is_valid():
 File "/.venv/lib/python3.4/site-packages/django/forms/forms.py" in
 is_valid
   184. return self.is_bound and not self.errors
 File "/.venv/lib/python3.4/site-packages/django/forms/forms.py" in errors
   176. self.full_clean()
 File "/.venv/lib/python3.4/site-packages/django/forms/forms.py" in
 full_clean
   394. self._post_clean()
 File "/.venv/lib/python3.4/site-packages/django/forms/models.py" in
 _post_clean
   430. self.instance.full_clean(exclude=exclude,
 validate_unique=False)
 File "/.venv/lib/python3.4/site-packages/django/db/models/base.py" in
 full_clean
   1156. self.clean()
 File "/maestro/quotes/models.py" in clean
   131. if self.curation != '':
 File "/.venv/lib/python3.4/site-
 packages/django/db/models/fields/related.py" in __get__
   616. "%s has no %s." % (self.field.model.__name__,
 self.field.name)

 Exception Type: RelatedObjectDoesNotExist at /admin/quotes/quote/add/
 Exception Value: Quote has no curation.
 }}}

 Any clue on what's going on?

 Many thanks.

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

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

Re: [Django] #25468: DjangoJSONEncoder should call unicode() on proxy strings.

2015-09-26 Thread Django

#25468: DjangoJSONEncoder should call unicode() on proxy strings.
-+-
 Reporter:  skorokithakis|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core |  Version:  master
  (Serialization)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #25468: DjangoJSONEncoder should call unicode() on proxy strings.

2015-09-26 Thread Django

#25468: DjangoJSONEncoder should call unicode() on proxy strings.
--+
 Reporter:  skorokithakis |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Serialization)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

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

Re: [Django] #25466: django.template.loader.LoaderOrigin was removed without proper deprecation

2015-09-26 Thread Django

#25466: django.template.loader.LoaderOrigin was removed without proper 
deprecation
-+
 Reporter:  tarkatronic  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.9a1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/5366 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/069.1ce018074f0e1dc0a4b0d0f792b05948%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25472: docs of login_required() should show the usage in class-based-views.

2015-09-26 Thread Django

#25472: docs of login_required() should show the usage in class-based-views.
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Thanks for the suggestion. On Django 1.9, you can use the
 `LoginRequiredMixin` instead and this is documented after the
 `login_required()` decorator in that documentation. I don't think the
 issue is critical enough that we need to patch the docs for 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/065.05e0e2037d77c0ca2fae19d0a75ce6e2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25473: Docs: 'author-detail' vs 'author_update'

2015-09-26 Thread Django

#25473: Docs: 'author-detail' vs 'author_update'
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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):

 It looks to me like the complaint is that sometimes dashes are used in
 `url()` names, sometimes underscores. If I had to cast a vote, I guess I'd
 choose dashes based on Google's advice "We recommend that you use hyphens
 (-) instead of underscores (_) in your URLs." and the fact that you might
 want your URL names to roughly match the URLs themselves.

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

Re: [Django] #25473: Docs: 'author-detail' vs 'author_update'

2015-09-26 Thread Django

#25473: Docs: 'author-detail' vs 'author_update'
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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 claudep):

 Can you please clarify what is the precise object of this ticket? Is this
 the hyphen vs underscore in the view name? Because detail and update views
 are different views...

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

Re: [Django] #25473: Docs: 'author-detail' vs 'author_update'

2015-09-26 Thread Django

#25473: Docs: 'author-detail' vs 'author_update'
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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 guettli):

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


Old description:

> Please use **one** form to refer to the update-view of
> a model.
>
> Here are two:  'author-detail' vs 'author_update'
>
> {{{
> def get_absolute_url(self):
> return reverse('author-detail', kwargs={'pk': self.pk})
> }}}
>
> from https://docs.djangoproject.com/en/1.8/topics/class-based-views
> /generic-editing/#model-forms
>
> some lines below the above link:
> {{{
> url(r'author/(?P[0-9]+)/$', AuthorUpdate.as_view(),
> name='author_update'),
> }}}

New description:

 Please use **one** form to refer to the update-view of
 a model.

 Here are two:  'author-detail' vs 'author_update'

 {{{
 def get_absolute_url(self):
 return reverse('author-detail', kwargs={'pk': self.pk})
 }}}

 from https://docs.djangoproject.com/en/1.8/topics/class-based-views
 /generic-editing/#model-forms

 some lines below the above link:
 {{{
 url(r'author/(?P[0-9]+)/$', AuthorUpdate.as_view(),
 name='author_update'),
 }}}


 But first: The django core developers should decide which pattern should
 be used in the docs:

 foo-detail or foo_update.

 When the decision was made, then all examples in the docs should use this
 pattern.

--

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

[Django] #25473: Docs: 'author-detail' vs 'author_update'

2015-09-26 Thread Django

#25473: Docs: 'author-detail' vs 'author_update'
--+
 Reporter:  guettli   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Please use **one** form to refer to the update-view of
 a model.

 Here are two:  'author-detail' vs 'author_update'

 {{{
 def get_absolute_url(self):
 return reverse('author-detail', kwargs={'pk': self.pk})
 }}}

 from https://docs.djangoproject.com/en/1.8/topics/class-based-views
 /generic-editing/#model-forms

 some lines below the above link:
 {{{
 url(r'author/(?P[0-9]+)/$', AuthorUpdate.as_view(),
 name='author_update'),
 }}}

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

Re: [Django] #25472: docs of login_required() should show the usage in class-based-views.

2015-09-26 Thread Django

#25472: docs of login_required() should show the usage in class-based-views.
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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 guettli:

Old description:

> The docs of login_required() should show the usage in class-based-views.
>
> This pattern seems common:
>
> ```
> urlpatterns = [
> url(r'^about/',
> login_required(TemplateView.as_view(template_name="secret.html"))),
> ```
> from: https://docs.djangoproject.com/en/1.8/topics/class-based-
> views/intro/#decorating-in-urlconf
>
> Please update the docs:
> https://docs.djangoproject.com/en/1.8/topics/auth/default/#django.contrib.auth.decorators.login_required
>
> Since class-based views are the default today, I think it would be
> appropriate to list the class-based-view way first, and then list the
> decorating of view-methods.

New description:

 The docs of login_required() should show the usage in class-based-views.

 This pattern seems common:

 {{{
 urlpatterns = [
 url(r'^about/',
 login_required(TemplateView.as_view(template_name="secret.html"))),
 }}}

 from: https://docs.djangoproject.com/en/1.8/topics/class-based-views/intro
 /#decorating-in-urlconf

 Please update the docs:
 
https://docs.djangoproject.com/en/1.8/topics/auth/default/#django.contrib.auth.decorators.login_required

 Since class-based views are the default today, I think it would be
 appropriate to list the class-based-view way first, and then list the
 decorating of view-methods.

--

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

Re: [Django] #25472: docs of login_required() should show the usage in class-based-views. (was: docs for)

2015-09-26 Thread Django

#25472: docs of login_required() should show the usage in class-based-views.
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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 guettli):

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


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

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

[Django] #25472: docs for

2015-09-26 Thread Django

#25472: docs for
--+
 Reporter:  guettli   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The docs of login_required() should show the usage in class-based-views.

 This pattern seems common:

 ```
 urlpatterns = [
 url(r'^about/',
 login_required(TemplateView.as_view(template_name="secret.html"))),
 ```
 from: https://docs.djangoproject.com/en/1.8/topics/class-based-views/intro
 /#decorating-in-urlconf

 Please update the docs:
 
https://docs.djangoproject.com/en/1.8/topics/auth/default/#django.contrib.auth.decorators.login_required

 Since class-based views are the default today, I think it would be
 appropriate to list the class-based-view way first, and then list the
 decorating of view-methods.

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

Re: [Django] #25470: Django cast DATE field to DATETIME unexpectedly

2015-09-26 Thread Django

#25470: Django cast DATE field to DATETIME unexpectedly
-+-
 Reporter:  stanleyxu2005|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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
-+-
Description changed by stanleyxu2005:

Old description:

> I posted a question at http://stackoverflow.com/questions/32795047/have-a
> -perforamance-issue-of-query-date-object-using-django-queryset
>
> I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
> (MyISAM). Recently the number of table records reaches 1 million, it will
> take 1-1.5 seconds to query all distinct record dates. But using MySQL
> client, it takes less than 0.001 second.
>
> '''Django Code'''
>
> {{{
> class Model1(models.Model):
> date = models.DateField(db_index=True)
>
> # benchmark code
> db_dates = Model1.objects.dates("date", kind="day")
> }}}
>
> I dumped the django queries.
>
> {{{
> {u'time': u'1.989', u'sql': u"SELECT DISTINCT
> CAST(DATE_FORMAT(`app1_model1`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
> AS `datefield` FROM `app1_model1` WHERE `app1_model1`.`date` IS NOT NULL
> ORDER BY `datefield` ASC"}
> }}}
>
> I noticed that the second query did a type cast. The cast is not a
> necessary step. It slows down when the amount of records is huge. I
> pretty sure this is the root cause of the slow.
>
> The table is created by django. The field is exactly `DATE` field. I'd
> like to know, why django cast DATE to DATETIME. Is it a bug?
>
> Currently, I use a workaround:
> {{{
> db_dates = [dt['date'] for dt in
> Model1.objects.order_by('date').values('date').distinct()]
> }}}

New description:

 I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
 (MyISAM). Recently the number of table records reaches 1 million, it will
 take 1-1.5 seconds to query all distinct record dates. But using MySQL
 client, it takes less than 0.001 second.

 '''Django Code'''

 {{{
 class Model1(models.Model):
 date = models.DateField(db_index=True)

 # benchmark code
 db_dates = Model1.objects.dates("date", kind="day")
 }}}

 I dumped the django queries.

 {{{
 {u'time': u'1.989', u'sql': u"SELECT DISTINCT
 CAST(DATE_FORMAT(`app1_model1`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
 AS `datefield` FROM `app1_model1` WHERE `app1_model1`.`date` IS NOT NULL
 ORDER BY `datefield` ASC"}
 }}}

 As you can see, the query did possibly an unnecessary type cast. The
 performance impact is scaled to the amount of records. The table field is
 exactly `DATE` type. I don't know, if there is some reason for the type
 casting.

 Currently, I use a workaround:
 {{{
 db_dates = Model1.objects.values_list('date', flat=True).distinct()
 }}}

 I posted a question at [http://stackoverflow.com/questions/32795047/have-a
 -perforamance-issue-of-query-date-object-using-django-queryset
 StackOverflow].

--

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

Re: [Django] #25470: Django cast DATE field to DATETIME unexpectedly

2015-09-26 Thread Django

#25470: Django cast DATE field to DATETIME unexpectedly
-+-
 Reporter:  stanleyxu2005|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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
-+-
Description changed by stanleyxu2005:

Old description:

> I posted a question at http://stackoverflow.com/questions/32795047/have-a
> -perforamance-issue-of-query-date-object-using-django-queryset
>
> I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
> (MyISAM). Recently the number of table records reaches 1 million, it will
> take 1-1.5 seconds to query all distinct record dates. But using MySQL
> client, it takes less than 0.001 second.
>
> '''Django Code'''
>
> {{{
> class Model1(models.Model):
> date = models.DateField(db_index=True)
>
> # benchmark code
> db_dates = Model1.objects.dates("date", kind="day")
> }}}
>
> I dumped the django queries.
>
> {{{
> [{u'time': u'0.000', u'sql': u'SET SQL_AUTO_IS_NULL = 0'},
>  {u'time': u'1.989', u'sql': u"SELECT DISTINCT
> CAST(DATE_FORMAT(`app1_model1`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
> AS `datefield` FROM `app1_model1` WHERE `app1_model1`.`date` IS NOT NULL
> ORDER BY `datefield` ASC"}
> ]
> }}}
>
> I noticed that the second query did a type cast. The cast is not a
> necessary step. It slows down when the amount of records is huge. I
> pretty sure this is the root cause of the slow.
>
> The table is created by django. The field is exactly `DATE` field. I'd
> like to know, why django cast DATE to DATETIME. Is it a bug?
>
> Currently, I use a workaround:
> {{{
> db_dates = [dt['date'] for dt in
> Model1.objects.order_by('date').values('date').distinct()]
> }}}

New description:

 I posted a question at http://stackoverflow.com/questions/32795047/have-a
 -perforamance-issue-of-query-date-object-using-django-queryset

 I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
 (MyISAM). Recently the number of table records reaches 1 million, it will
 take 1-1.5 seconds to query all distinct record dates. But using MySQL
 client, it takes less than 0.001 second.

 '''Django Code'''

 {{{
 class Model1(models.Model):
 date = models.DateField(db_index=True)

 # benchmark code
 db_dates = Model1.objects.dates("date", kind="day")
 }}}

 I dumped the django queries.

 {{{
 {u'time': u'1.989', u'sql': u"SELECT DISTINCT
 CAST(DATE_FORMAT(`app1_model1`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
 AS `datefield` FROM `app1_model1` WHERE `app1_model1`.`date` IS NOT NULL
 ORDER BY `datefield` ASC"}
 }}}

 I noticed that the second query did a type cast. The cast is not a
 necessary step. It slows down when the amount of records is huge. I pretty
 sure this is the root cause of the slow.

 The table is created by django. The field is exactly `DATE` field. I'd
 like to know, why django cast DATE to DATETIME. Is it a bug?

 Currently, I use a workaround:
 {{{
 db_dates = [dt['date'] for dt in
 Model1.objects.order_by('date').values('date').distinct()]
 }}}

--

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

Re: [Django] #25470: Django cast DATE field to DATETIME unexpectedly

2015-09-26 Thread Django

#25470: Django cast DATE field to DATETIME unexpectedly
-+-
 Reporter:  stanleyxu2005|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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
-+-
Description changed by stanleyxu2005:

Old description:

> I posted a question at http://stackoverflow.com/questions/32795047/have-a
> -perforamance-issue-of-query-date-object-using-django-queryset
>
> I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
> (MyISAM). Recently the number of table records reaches 1 million, it will
> take 1-1.5 seconds to query all distinct record dates. But using MySQL
> client, it takes less than 0.001 second.
>
> '''Django Code'''
>
> {{{
> class Model1(models.Model):
> date = models.DateField(db_index=True)
>
> # benchmark code
> db_dates = Model1.objects.dates("date", kind="day")
> }}}
>
> I dumped the django queries.
>
> {{{
> [{u'time': u'0.000', u'sql': u'SET SQL_AUTO_IS_NULL = 0'},
>  {u'time': u'1.989', u'sql': u"SELECT DISTINCT
> CAST(DATE_FORMAT(`app1_model1`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
> AS `datefield` FROM `app1_model1` WHERE `app1_model1`.`date` IS NOT NULL
> ORDER BY `datefield` ASC"}
> ]
> }}}
>
> I noticed that the second query did a type cast. The cast is not a
> necessary step. It slows down when the amount of records is huge. I
> pretty sure this is the root cause of the slow.
>
> The table is created by django. The field is exactly `DATE` field. I'd
> like to know, why django cast DATE to DATETIME. Is it a bug?
>
> Currently, I use a workaround:
> {{{
> db_dates  = [dt['date'] for dt in
> Model1.objects.order_by('date').values('date').distinct()]
> }}}

New description:

 I posted a question at http://stackoverflow.com/questions/32795047/have-a
 -perforamance-issue-of-query-date-object-using-django-queryset

 I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
 (MyISAM). Recently the number of table records reaches 1 million, it will
 take 1-1.5 seconds to query all distinct record dates. But using MySQL
 client, it takes less than 0.001 second.

 '''Django Code'''

 {{{
 class Model1(models.Model):
 date = models.DateField(db_index=True)

 # benchmark code
 db_dates = Model1.objects.dates("date", kind="day")
 }}}

 I dumped the django queries.

 {{{
 [{u'time': u'0.000', u'sql': u'SET SQL_AUTO_IS_NULL = 0'},
  {u'time': u'1.989', u'sql': u"SELECT DISTINCT
 CAST(DATE_FORMAT(`app1_model1`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
 AS `datefield` FROM `app1_model1` WHERE `app1_model1`.`date` IS NOT NULL
 ORDER BY `datefield` ASC"}
 ]
 }}}

 I noticed that the second query did a type cast. The cast is not a
 necessary step. It slows down when the amount of records is huge. I pretty
 sure this is the root cause of the slow.

 The table is created by django. The field is exactly `DATE` field. I'd
 like to know, why django cast DATE to DATETIME. Is it a bug?

 Currently, I use a workaround:
 {{{
 db_dates = [dt['date'] for dt in
 Model1.objects.order_by('date').values('date').distinct()]
 }}}

--

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

Re: [Django] #25470: Django cast DATE field to DATETIME unexpectedly

2015-09-26 Thread Django

#25470: Django cast DATE field to DATETIME unexpectedly
-+-
 Reporter:  stanleyxu2005|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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
-+-
Description changed by stanleyxu2005:

Old description:

> I posted a question at http://stackoverflow.com/questions/32795047/have-a
> -perforamance-issue-of-query-date-object-using-django-queryset
>
> I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
> (MyISAM). Recently the number of table records reaches 1 million, it will
> take 1-1.5 seconds to query all distinct record dates. But using MySQL
> client, it takes less than 0.001 second.
>
> '''Django Code'''
>
> {{{
> class Model1(models.Model):
> date = models.DateField(db_index=True)
>
> # benchmark code
> db_dates = set(Model1.objects.dates("date", kind="day"))
> }}}
>
> I dumped the django queries.
>
> {{{
> [{u'time': u'0.000', u'sql': u'SET SQL_AUTO_IS_NULL = 0'},
>  {u'time': u'1.989', u'sql': u"SELECT DISTINCT
> CAST(DATE_FORMAT(`app1_model1`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
> AS `datefield` FROM `app1_model1` WHERE `app1_model1`.`date` IS NOT NULL
> ORDER BY `datefield` ASC"}
> ]
> }}}
>
> I noticed that the second query did a type cast. The cast is not a
> necessary step. It slows down when the amount of records is huge. I
> pretty sure this is the root cause of the slow.
>
> The table is created by django. The field is exactly `DATE` field. I'd
> like to know, why django cast DATE to DATETIME. Is it a bug?

New description:

 I posted a question at http://stackoverflow.com/questions/32795047/have-a
 -perforamance-issue-of-query-date-object-using-django-queryset

 I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
 (MyISAM). Recently the number of table records reaches 1 million, it will
 take 1-1.5 seconds to query all distinct record dates. But using MySQL
 client, it takes less than 0.001 second.

 '''Django Code'''

 {{{
 class Model1(models.Model):
 date = models.DateField(db_index=True)

 # benchmark code
 db_dates = Model1.objects.dates("date", kind="day")
 }}}

 I dumped the django queries.

 {{{
 [{u'time': u'0.000', u'sql': u'SET SQL_AUTO_IS_NULL = 0'},
  {u'time': u'1.989', u'sql': u"SELECT DISTINCT
 CAST(DATE_FORMAT(`app1_model1`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
 AS `datefield` FROM `app1_model1` WHERE `app1_model1`.`date` IS NOT NULL
 ORDER BY `datefield` ASC"}
 ]
 }}}

 I noticed that the second query did a type cast. The cast is not a
 necessary step. It slows down when the amount of records is huge. I pretty
 sure this is the root cause of the slow.

 The table is created by django. The field is exactly `DATE` field. I'd
 like to know, why django cast DATE to DATETIME. Is it a bug?

 Currently, I use a workaround:
 {{{
 db_dates  = [dt['date'] for dt in
 Model1.objects.order_by('date').values('date').distinct()]
 }}}

--

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

Re: [Django] #21286: Fix commented out tests in serializers_regress

2015-09-26 Thread Django

#21286: Fix commented out tests in serializers_regress
--+
 Reporter:  timo  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  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 claudep):

 FileField and NULL value issue is tracked in #10244.

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

Re: [Django] #25468: DjangoJSONEncoder should call unicode() on proxy strings.

2015-09-26 Thread Django

#25468: DjangoJSONEncoder should call unicode() on proxy strings.
--+
 Reporter:  skorokithakis |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Serialization)  |  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 claudep):

 * Attachment "25468.diff" added.


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

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

Re: [Django] #25468: DjangoJSONEncoder should call unicode() on proxy strings.

2015-09-26 Thread Django

#25468: DjangoJSONEncoder should call unicode() on proxy strings.
--+
 Reporter:  skorokithakis |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Serialization)  |  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 claudep):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Core (Serialization)
 * needs_tests:   => 0
 * version:  1.8 => master
 * needs_docs:   => 0
 * type:  Bug => New feature
 * stage:  Unreviewed => Accepted


Comment:

 I have a local patch ready to fix that, waiting on
 https://github.com/django/django/pull/5365 to be merged first.

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

Re: [Django] #25470: Django cast DATE field to DATETIME unexpectedly

2015-09-26 Thread Django

#25470: Django cast DATE field to DATETIME unexpectedly
-+-
 Reporter:  stanleyxu2005|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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
-+-
Description changed by stanleyxu2005:

Old description:

> I posted a question at http://stackoverflow.com/questions/32795047/have-a
> -perforamance-issue-of-query-date-object-using-django-queryset
>
> I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
> (MyISAM). Recently the number of table records reaches 1 million, it will
> take 1-1.5 seconds to query all distinct record dates. But using MySQL
> client, it takes less than 0.001 second.
>
> '''Django Code'''
>
> {{{
> class Model1(models.Model):
> date = models.DateField(db_index=True)
>
> # benchmark code
> db_dates = set(Model1.objects.dates("date", kind="day"))
> }}}
>
> I dumped the django queries.
>
> {{{
> [{u'time': u'0.000', u'sql': u'SET SQL_AUTO_IS_NULL = 0'},
>  {u'time': u'1.989', u'sql': u"SELECT DISTINCT
> CAST(DATE_FORMAT(`model1_table`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
> AS `datefield` FROM `model1_table` WHERE `model1_table`.`date` IS NOT
> NULL ORDER BY `datefield` ASC"}
> ]
> }}}
>
> I noticed that the second query did a type cast. The cast is not a
> necessary step. It slows down when the amount of records is huge. I
> pretty sure this is the root cause of the slow.
>
> The table is created by django. The field is exactly `DATE` field. I'd
> like to know, why django cast DATE to DATETIME. Is it a bug?

New description:

 I posted a question at http://stackoverflow.com/questions/32795047/have-a
 -perforamance-issue-of-query-date-object-using-django-queryset

 I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
 (MyISAM). Recently the number of table records reaches 1 million, it will
 take 1-1.5 seconds to query all distinct record dates. But using MySQL
 client, it takes less than 0.001 second.

 '''Django Code'''

 {{{
 class Model1(models.Model):
 date = models.DateField(db_index=True)

 # benchmark code
 db_dates = set(Model1.objects.dates("date", kind="day"))
 }}}

 I dumped the django queries.

 {{{
 [{u'time': u'0.000', u'sql': u'SET SQL_AUTO_IS_NULL = 0'},
  {u'time': u'1.989', u'sql': u"SELECT DISTINCT
 CAST(DATE_FORMAT(`app1_model1`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
 AS `datefield` FROM `app1_model1` WHERE `app1_model1`.`date` IS NOT NULL
 ORDER BY `datefield` ASC"}
 ]
 }}}

 I noticed that the second query did a type cast. The cast is not a
 necessary step. It slows down when the amount of records is huge. I pretty
 sure this is the root cause of the slow.

 The table is created by django. The field is exactly `DATE` field. I'd
 like to know, why django cast DATE to DATETIME. Is it a bug?

--

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

Re: [Django] #25470: Django cast DATE field to DATETIME unexpectedly

2015-09-26 Thread Django

#25470: Django cast DATE field to DATETIME unexpectedly
-+-
 Reporter:  stanleyxu2005|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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 stanleyxu2005):

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


Old description:

> I posted a question at http://stackoverflow.com/questions/32795047/have-a
> -perforamance-issue-of-query-date-object-using-django-queryset
>
> I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
> (MyISAM). Recently the number of table records reaches 1 million, it will
> take 1-1.5 seconds to query all distinct record dates. But using MySQL
> client, it takes less than 0.001 second.
>
> '''Django Code'''
>
> {{{
> class Model1(models.Model):
> date = models.DateField(db_index=True)
>
> # benchmark code
> db_dates = set(Model1.objects.dates("date", kind="day"))
> }}}
>
> I dumped the django queries.
>
> {{{
> [{u'time': u'0.000', u'sql': u'SET SQL_AUTO_IS_NULL = 0'},
>  {u'time': u'1.989', u'sql': u"SELECT DISTINCT
> CAST(DATE_FORMAT(`model1_table`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
> AS `datefield` FROM `model1_table` WHERE `model1_table`.`date` IS NOT
> NULL ORDER BY `datefield` ASC"}
> ]
> }}}
>
> Actually the second query did a type cast. This is the root cause of the
> slow.
>
> I'd like to know, why django cast DATE to DATETIME. Is it a bug?

New description:

 I posted a question at http://stackoverflow.com/questions/32795047/have-a
 -perforamance-issue-of-query-date-object-using-django-queryset

 I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
 (MyISAM). Recently the number of table records reaches 1 million, it will
 take 1-1.5 seconds to query all distinct record dates. But using MySQL
 client, it takes less than 0.001 second.

 '''Django Code'''

 {{{
 class Model1(models.Model):
 date = models.DateField(db_index=True)

 # benchmark code
 db_dates = set(Model1.objects.dates("date", kind="day"))
 }}}

 I dumped the django queries.

 {{{
 [{u'time': u'0.000', u'sql': u'SET SQL_AUTO_IS_NULL = 0'},
  {u'time': u'1.989', u'sql': u"SELECT DISTINCT
 CAST(DATE_FORMAT(`model1_table`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
 AS `datefield` FROM `model1_table` WHERE `model1_table`.`date` IS NOT NULL
 ORDER BY `datefield` ASC"}
 ]
 }}}

 I noticed that the second query did a type cast. The cast is not a
 necessary step. It slows down when the amount of records is huge. I pretty
 sure this is the root cause of the slow.

 The table is created by django. The field is exactly `DATE` field. I'd
 like to know, why django cast DATE to DATETIME. Is it a bug?

--

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

Re: [Django] #25471: Random test failures with parallel selenium tests

2015-09-26 Thread Django

#25471: Random test failures with parallel selenium tests
---+
 Reporter:  MoritzS|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

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


Comment:

 I don't know if Selenium is supposed to handle parallel execution of
 multiple processes.

 The easiest solution is probably to serialize execution of these tests
 with SerializeMixin.

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

Re: [Django] #25469: Autoescape is not possible with Django 1.8 template refactor

2015-09-26 Thread Django

#25469: Autoescape is not possible with Django 1.8 template refactor
-+--
 Reporter:  aidanlister  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  templates| Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by aaugustin):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Unless I missed something, this was a private API. You can use the public
 API which hasn't changed in Django 1.8:
 https://docs.djangoproject.com/en/1.7/ref/templates/builtins/#std
 :templatetag-autoescape

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

Re: [Django] #19361: Link to object in message after creating/updating object in django admin

2015-09-26 Thread Django

#19361: Link to object in message after creating/updating object in django admin
-+-
 Reporter:  anonymous|Owner:  bak1an
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, messages, | Triage Stage:  Accepted
  update_object, create_object   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bak1an):

 * needs_better_patch:  0 => 1


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

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

[Django] #25471: Random test failures with parallel selenium tests

2015-09-26 Thread Django

#25471: Random test failures with parallel selenium tests
---+
 Reporter:  MoritzS|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When running selenium tests in parallel I often get test failures that
 seem to be some kind of race condition. However with `--parallel 1` these
 errors don't occur and sometimes even when running in parallel all tests
 pass.

 I usually run the tests with `xvfb-runner`, however I also tested it
 without xvfb and the errors still occur.

 {{{
 $ chromium --version
 Chromium 45.0.2454.101
 $ chromedriver --version
 ChromeDriver 2.16
 $ firefox --version
 Mozilla Firefox 41.0
 }}}

 Here are some of the results of running the test suite multiple times with
 `./runtests --selenium` (running on 8 cores):


 {{{
 ==
 ERROR: test_ForeignKey
 (admin_widgets.tests.AdminRawIdWidgetSeleniumFirefoxTests)
 --
 selenium.common.exceptions.NoSuchElementException: Message: Unable to
 locate element: {"method":"link text","selector":"Bogey Blues"}
 Stacktrace:
 at FirefoxDriver.prototype.findElementInternal_
 
(file:///tmp/django_m_oympys/tmpqtuo3nbn/extensions/fxdri...@googlecode.com/components
 /driver-component.js:10647)
 at FirefoxDriver.prototype.findElement
 
(file:///tmp/django_m_oympys/tmpqtuo3nbn/extensions/fxdri...@googlecode.com/components
 /driver-component.js:10656)
 at DelayedCommand.prototype.executeInternal_/h
 
(file:///tmp/django_m_oympys/tmpqtuo3nbn/extensions/fxdri...@googlecode.com/components
 /command-processor.js:12617)
 at DelayedCommand.prototype.executeInternal_
 
(file:///tmp/django_m_oympys/tmpqtuo3nbn/extensions/fxdri...@googlecode.com/components
 /command-processor.js:12622)
 at DelayedCommand.prototype.execute/<
 
(file:///tmp/django_m_oympys/tmpqtuo3nbn/extensions/fxdri...@googlecode.com/components
 /command-processor.js:12564)

 ==
 ERROR: test_many_to_many
 (admin_widgets.tests.AdminRawIdWidgetSeleniumFirefoxTests)
 --
 selenium.common.exceptions.TimeoutException: Message:


 ==
 ERROR: test_prepopulated_fields
 (admin_views.tests.SeleniumAdminViewsChromeTests)
 --
 selenium.common.exceptions.NoSuchElementException: Message: no such
 element
   (Session info: chrome=45.0.2454.101)
   (Driver info: chromedriver=2.16,platform=Linux 4.1.6-1-ARCH x86_64)


 ==
 FAIL: test_multiple_locales
 (i18n.test_compilation.MultipleLocaleCompilationTests)
 --
 AssertionError: False is not true

 --
 Ran 10308 tests in 61.830s
 }}}
 {{{
 ==
 ERROR: test_calendar_nonday_class
 (admin_widgets.tests.DateTimePickerSeleniumChromeTests)
 --
 selenium.common.exceptions.NoSuchElementException: Message: no such
 element
   (Session info: chrome=45.0.2454.101)
   (Driver info: chromedriver=2.16,platform=Linux 4.1.6-1-ARCH x86_64)


 ==
 FAIL: test_add_inlines (admin_inlines.tests.SeleniumChromeTests)
 --
 AssertionError: 0 != 1

 --
 Ran 10308 tests in 62.124s
 }}}
 {{{
 ==
 ERROR: test_filter
 (admin_widgets.tests.HorizontalVerticalFilterSeleniumChromeTests)
 --
 selenium.common.exceptions.StaleElementReferenceException: Message: stale
 element reference: element is not attached to the page document
   (Session info: chrome=45.0.2454.101)
   (Driver info: chromedriver=2.16,platform=Linux 4.1.6-1-ARCH x86_64)


 --
 Ran 10308 tests in 65.913s
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups

[Django] #25470: Django cast DATE field to DATETIME unexpectedly

2015-09-26 Thread Django

#25470: Django cast DATE field to DATETIME unexpectedly
--+
 Reporter:  stanleyxu2005 |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I posted a question at http://stackoverflow.com/questions/32795047/have-a
 -perforamance-issue-of-query-date-object-using-django-queryset

 I'm using django 1.8.4 writing a webapp. The backend uses MySQL 5.6
 (MyISAM). Recently the number of table records reaches 1 million, it will
 take 1-1.5 seconds to query all distinct record dates. But using MySQL
 client, it takes less than 0.001 second.

 '''Django Code'''

 {{{
 class Model1(models.Model):
 date = models.DateField(db_index=True)

 # benchmark code
 db_dates = set(Model1.objects.dates("date", kind="day"))
 }}}

 I dumped the django queries.

 {{{
 [{u'time': u'0.000', u'sql': u'SET SQL_AUTO_IS_NULL = 0'},
  {u'time': u'1.989', u'sql': u"SELECT DISTINCT
 CAST(DATE_FORMAT(`model1_table`.`date`, '%Y-%m-%d 00:00:00') AS DATETIME)
 AS `datefield` FROM `model1_table` WHERE `model1_table`.`date` IS NOT NULL
 ORDER BY `datefield` ASC"}
 ]
 }}}

 Actually the second query did a type cast. This is the root cause of the
 slow.

 I'd like to know, why django cast DATE to DATETIME. Is it a bug?

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

[Django] #25469: Autoescape is not possible with Django 1.8 template refactor

2015-09-26 Thread Django

#25469: Autoescape is not possible with Django 1.8 template refactor
-+---
 Reporter:  aidanlister  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.8
 Severity:  Normal   |   Keywords:  templates
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+---
 Passing Context(mydata, autoescape=True) is no longer effective when using
 the non-deprecated format:

 {{{
 from django.template import engines
 engines['django'].from_string('hello {{person}}').render({'person':
 'bob & co'})
 >>> 'hello bob & co'
 }}}

 vs

 {{{
 from django.template import Template,Context
 Template('hello {{person}}').render(Context({'person': 'bob & co'},
 autoescape=False))
 >>> 'hello bob & co'
 }}}

 This is a very useful feature when not generated HTML templates!

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

Re: [Django] #25068: Metaclass conflict when doing createmigrations in ModelState.render

2015-09-26 Thread Django

#25068: Metaclass conflict when doing createmigrations in ModelState.render
-+-
 Reporter:  kosz85   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  metaclass conflict   | Triage Stage:  Accepted
  createmigrations   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kosz85):

 That's not smth to be scared of. I can explain what is happening there:

 Each class has metaclass, which default is `type`. It's class of class.
 You can change it and made your own type declaring metaclass. What new
 migrations did, is bad assumption that class would be created only using
 `type`, and that there would be only simple conflicts.
 First take a note that `Model` metaclass is already set to `BaseModel`.

 Assume such situation:
 class cA with metaclass mA
 class cB with metaclass mB
 class cC(cA, cB) -> metaclass mC

 Python has no problem with standard metaclasses.
 When mA and mB eguals default `type` then python knows that mC is also
 `type`.
 Also when mA or mB equals default `type` and the other not (for example
 `BaseModel`) then he can easily solve conflict because every metaclass is
 derived from `type` so Python is using the other one so mC would be
 `BaseModel`.
 But when mA is custom and mB is custom, he don't know what to do, and
 there are even worse scenarios, there may be 3 or more bases to inherit
 from. Then standard response is to manually build mC that inherit from mA
 and mB (like in normal class inheritance).

 So what is doing this patch is reacting to that `TypeError`, and
 constructing (it's normal factory) such custom metaclass from metaclasses
 that are used in bases of this class. That new metaclass is used then to
 create object, instead of standard type. So no magic ;) The only magic is
 factory and populating metaclasses from bases.

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

Re: [Django] #25421: Twice run tests with --keepdb option in Oracle fails

2015-09-26 Thread Django

#25421: Twice run tests with --keepdb option in Oracle fails
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle test keepdb   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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

40 matches

Mail list logo