date:20151120

Re: [Django] #25748: Glossary: Project vs App

2015-11-20 Thread Django

#25748: Glossary: Project vs App
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 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 aaugustin):

 Discussion: https://groups.google.com/d/msg/django-developers/E8ViGUa-
 BT0/E4SLXsg6AwAJ

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

Re: [Django] #25792: Rename JsonResponse to JSONResponse

2015-11-20 Thread Django

#25792: Rename JsonResponse to JSONResponse
-+-
 Reporter:  danifus  |Owner:  danifus
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by danifus):

 * has_patch:  0 => 1


Comment:

 The changes for this ticket can be found on the following commit:

 
https://github.com/danifus/django/commit/9381fda7b86b34f21d1656df60c60b8225734773

 Let me know of any improvements and I'll get it into shape.

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

Re: [Django] #25792: Rename JsonResponse to JSONResponse

2015-11-20 Thread Django

#25792: Rename JsonResponse to JSONResponse
-+-
 Reporter:  danifus  |Owner:  danifus
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by danifus):

 * status:  new => assigned
 * needs_docs:   => 0
 * owner:  nobody => danifus
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.45848fb6230ee4153f36d6217af09cff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25792: Rename JsonResponse to JSONResponse

2015-11-20 Thread Django

#25792: Rename JsonResponse to JSONResponse
--+
 Reporter:  danifus   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  HTTP handling |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Rename django.http.JsonResponse to JSONResponse. This change brings the
 capitalization of 'JSON' in line with the rest of the project where it is
 spelt with either all capitals or all lower case (eg.
 django.contrib.sessions.serializers.JSONSerializer,
 django.contrib.postgres.fields.JSONField, json_dumps_params, etc.)

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

Re: [Django] #5763: Queryset doesn't have a "not equal" filter operator

2015-11-20 Thread Django

#5763: Queryset doesn't have a "not equal" filter operator
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  qs-rf| Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by unaizalakain):

 * cc: unai@… (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/066.84bcecc4a895237716364ef16cdc7037%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25748: Glossary: Project vs App

2015-11-20 Thread Django

#25748: Glossary: Project vs App
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 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 zachborboa):

 * cc: zachborboa@… (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/065.df85b4fa71b7d8d880a23b67f99b4c8d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25787: Existence checks for related database sets

2015-11-20 Thread Django

#25787: Existence checks for related database sets
-+-
 Reporter:  JustusAdam   |Owner:
 |  andersonresende
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ManyToMany,  | Triage Stage:
  contains, in   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by andersonresende):

 * owner:  nobody => andersonresende
 * needs_better_patch:   => 0
 * status:  new => assigned
 * 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.bbe83577bd1180e7ef7ebcb12bf57ab2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25791: Implement autoreload behaviour for cached template loader

2015-11-20 Thread Django

#25791: Implement autoreload behaviour for cached template loader
--+
 Reporter:  jaap3 |  Owner:  nobody
 Type:  New   | Status:  new
  feature |
Component:  Template  |Version:  master
  system  |
 Severity:  Normal|   Keywords:  autoreload templates cached loader
 Triage Stage:|  Has patch:  1
  Unreviewed  |
Easy pickings:  0 |  UI/UX:  0
--+
 It would be nice to be able get the speed benefit of the cached template
 loader during development, but without the downside of having to restart
 the server every time you change a template. It turns out it's possible
 with just a few changes.

 Because it's not really possible to configure the cached template loader I
 did have to base this patch on the fix for #25788. Enabling autoreloading
 for the cached template loader would work like this:

 {{{
 TEMPLATES = [{
 'BACKEND': 'django.template.backends.django.DjangoTemplates',
 'DIRS': [os.path.join(BASE_DIR, 'templates')],
 'APP_DIRS': True
 'OPTIONS': {
 'cache_templates': True,
 'autoreload': DEBUG
 }
 }]
 }}}

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

Re: [Django] #25790: Admin magic change list UI ordering is too helpful?

2015-11-20 Thread Django

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

Comment:

There is some work in this branch:
https://github.com/django/django/compare/master...ramiro:ticket_25790?expand=1

I'm thinking now it's wrong or at least incomplete.

I suspect this is overloading the `ModelAdmin.ordering` option (which is
for specifying the change list default/initial ordering) with an
additional function.

A possible solution, provided the feature proposed by this ticket is
accepted, is to have another option e.g. `orderable_by` which when not
provided makes things behave like they do now and when specified (a list
of fields) is ORed with `ordering` to get the final list of columns which
will actually be allowed to sort by.

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

Re: [Django] #25790: Admin magic change list UI ordering is too helpful?

2015-11-20 Thread Django

#25790: Admin magic change list UI ordering is too helpful?
-+-
 Reporter:  ramiro   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  sorting ordering | Triage Stage:
  change list changelist admin   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by ramiro:

Old description:

> Consider this model:
>
> {{{
> # models.py
> from __future__ import unicode_literals
>
> from django.db import models
>

> class CreditCard(models.Model):
> issued_to = models.CharField(max_length=40)
> valid_to = models.DateField()
> last_four_digits = models.CharField(max_length=4)
> }}}
>
> And this admin.py for the app:
> {{{
> from django.contrib import admin
>
> from app.models import CreditCard
>

> class CCAdmin(admin.ModelAdmin):
> list_display = [
> 'issued_to',
> 'valid_to',
> 'last_four_digits',
> ]
> ordering = ['valid_to']
>
> def last4digits(self, obj):
> """So we don't get bogus ordering by this field in the change
> list view."""
> return obj.last_four_digits
> last4digits.short_description = '4 last digits'
>

> admin.site.register(CreditCard, CCAdmin)
> }}}
>
> The user has specified explicitly he/she wants the change list view grid
> to be sortable by default by the credt card expiration date by using the
> `ModelAdmin.ordering`option.
>
> Now, the interactive sorting changelist functionality that allows one to
> sort by a column by clicking on its header automagically allows one to
> also sort by other columns chosen by a documented logic (i.e. not if
> callable columns, etc.).
>
> In the example, it allows users to also sort by the name of the credit
> card owner which, even if not asked for, seems useful.
>
> Where it doesn't make so much sense is, for the example, in the case of
> the 'last four digits' column. IMHO there should be a way to express
> which columns one wants this functionality  without having to resort to
> things like
>
> {{{
> class CCAdmin(admin.ModelAdmin):
> list_display = [
> 'issued_to',
> 'valid_to',
> 'last4digits',
> ]
> #...
>
> def last4digits(self, obj):
> """So we don't get bogus ordering by this field in the change
> list view."""
> return obj.last_four_digits
> last4digits.short_description = '4 last digits'
> }}}

New description:

 Consider this model:

 {{{
 # models.py
 from __future__ import unicode_literals

 from django.db import models


 class CreditCard(models.Model):
 issued_to = models.CharField(max_length=40)
 valid_to = models.DateField()
 last_four_digits = models.CharField(max_length=4)
 }}}

 And this admin.py for the app:
 {{{
 from django.contrib import admin

 from app.models import CreditCard


 class CCAdmin(admin.ModelAdmin):
 list_display = [
 'issued_to',
 'valid_to',
 'last_four_digits',
 ]
 ordering = ['valid_to']


 admin.site.register(CreditCard, CCAdmin)
 }}}

 The user has specified explicitly he/she wants the change list view grid
 to be sortable by default by the credt card expiration date by using the
 `ModelAdmin.ordering`option.

 Now, the interactive sorting changelist functionality that allows one to
 sort by a column by clicking on its header automagically allows one to
 also sort by other columns chosen by a documented logic (i.e. not if
 callable columns, etc.).

 In the example, it allows users to also sort by the name of the credit
 card owner which, even if not asked for, seems useful.

 Where it doesn't make so much sense is, for the example, in the case of
 the 'last four digits' column. IMHO there should be a way to express which
 columns one wants this functionality  without having to resort to things
 like

 {{{
 class CCAdmin(admin.ModelAdmin):
 list_display = [
 'issued_to',
 'valid_to',
 'last4digits',
 ]
 #...

 def last4digits(self, obj):
 """So we don't get bogus ordering by this field in the change list
 view."""
 return obj.last_four_digits
 last4digits.short_description = '4 last digits'
 }}}

--

--
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 ema

[Django] #25790: Admin magic change list UI ordering is too helpful?

2015-11-20 Thread Django

#25790: Admin magic change list UI ordering is too helpful?
-+-
   Reporter:  ramiro |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component: |Version:  1.8
  contrib.admin  |   Keywords:  sorting ordering
   Severity:  Normal |  change list changelist admin
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Consider this model:

 {{{
 # models.py
 from __future__ import unicode_literals

 from django.db import models


 class CreditCard(models.Model):
 issued_to = models.CharField(max_length=40)
 valid_to = models.DateField()
 last_four_digits = models.CharField(max_length=4)
 }}}

 And this admin.py for the app:
 {{{
 from django.contrib import admin

 from app.models import CreditCard


 class CCAdmin(admin.ModelAdmin):
 list_display = [
 'issued_to',
 'valid_to',
 'last_four_digits',
 ]
 ordering = ['valid_to']

 def last4digits(self, obj):
 """So we don't get bogus ordering by this field in the change list
 view."""
 return obj.last_four_digits
 last4digits.short_description = '4 last digits'


 admin.site.register(CreditCard, CCAdmin)
 }}}

 The user has specified explicitly he/she wants the change list view grid
 to be sortable by default by the credt card expiration date by using the
 `ModelAdmin.ordering`option.

 Now, the interactive sorting changelist functionality that allows one to
 sort by a column by clicking on its header automagically allows one to
 also sort by other columns chosen by a documented logic (i.e. not if
 callable columns, etc.).

 In the example, it allows users to also sort by the name of the credit
 card owner which, even if not asked for, seems useful.

 Where it doesn't make so much sense is, for the example, in the case of
 the 'last four digits' column. IMHO there should be a way to express which
 columns one wants this functionality  without having to resort to things
 like

 {{{
 class CCAdmin(admin.ModelAdmin):
 list_display = [
 'issued_to',
 'valid_to',
 'last4digits',
 ]
 #...

 def last4digits(self, obj):
 """So we don't get bogus ordering by this field in the change list
 view."""
 return obj.last_four_digits
 last4digits.short_description = '4 last digits'
 }}}

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

[Django] #25789: Inefficient Queries Generated due to not using WHERE EXISTS

2015-11-20 Thread Django

#25789: Inefficient Queries Generated due to not using WHERE EXISTS
--+
 Reporter:  cancan101 |  Owner:  nobody
 Type:  Uncategorized | 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
--+
 [http://stackoverflow.com/questions/33764737/django-equivalent-of-
 sqlalchemy-any-to-filter-where-exists/33765323 Reposting question from SO]
 with some more details.

 I believe that the Django ORM is generating seriously inefficient SQL due
 to it not using `WHERE EXISTS` but instead using a `DISTINCT` with a `LEFT
 JOIN`. by comparison, SQLAlchemy will use `WHERE EXISTS`.

 I have two models, `Exam` and `Series`. `Series` objects have a foreign
 key to an `Exam` object. Both of the models contain a field
 `description_user`. I am trying to search for all `Exam`s that have a
 search term in `description_user` or have a child `Series` with that term
 in its `description_user`. I want to do this for a number of search terms
 (requiring all of them). I also want to de-duplicate the results (ie not
 get the same Exam multiple times).

 This is roughly what the filter looks like:

 {{{
 a = (Q(**{'series__description_user__icontains': 'bar'}) |
 Q(**{'description_user__icontains': 'bar'}))
 b = (Q(**{'series__description_user__icontains': 'foo'}) |
 Q(**{'description_user__icontains': 'foo'}))
 c = (Q(**{'series__description_user__icontains': 'baz'}) |
 Q(**{'description_user__icontains': 'baz'}))
 Exam.objects.filter(a & b & c).distinct()
 }}}

 with corresponding SQL:

 {{{
 SELECT DISTINCT
 "exam_storage_exam"."id",
 "exam_storage_exam"."description_user"
 FROM"exam_storage_exam"
 LEFT OUTER JOIN "exam_storage_series"
 ON  (
 "exam_storage_exam"."id" =
 "exam_storage_series"."exam_id"
 AND (
 "exam_storage_series"."removed" IS NULL) )
 WHERE   (
 "exam_storage_exam"."removed" IS NULL
 AND (
 "exam_storage_series"."description_user" LIKE %s ESCAPE \'\\\'
 OR
 "exam_storage_exam"."description_user" LIKE %s ESCAPE \'\\\')
 AND (
 "exam_storage_series"."description_user" LIKE %s ESCAPE \'\\\'
 OR
 "exam_storage_exam"."description_user" LIKE %s ESCAPE \'\\\')
 AND (
 "exam_storage_series"."description_user" LIKE %s ESCAPE \'\\\'
 OR
 "exam_storage_exam"."description_user" LIKE %s ESCAPE \'\\\'))

 }}}

 The issue is that as the number of search terms grows, the size of the
 intermediate data set before the DISTINCT operation grows as well.

 Ideally the SQL would look like:
 {{{
 SELECT *
  FROM exam
WHERE (EXISTS (SELECT 1
 FROM exam_storage_series
   WHERE exam.id = series.exam_id AND (
 series.description_user LIKE '%foo%'
   )) or exam.description_user LIKE '%foo%') AND
 (EXISTS (SELECT 1
 FROM exam_storage_series
   WHERE exam.id = series.exam_id AND (
 series.description_user LIKE '%bar%'
   )) or exam.description_user LIKE '%bar%') AND
 (EXISTS (SELECT 1
 FROM exam_storage_series
   WHERE exam.id = series.exam_id AND (
 series.description_user LIKE '%baz%'
   )) or exam.description_user LIKE '%baz%')
 }}}

 Currently the performance of Django query is terrible. This style
 searching comes up for example in how [https://github.com/tomchristie
 /django-rest-
 
framework/blob/43c45cc9391ec2bed9481a8b309990dec35b6ac8/rest_framework/filters.py#L132-L180
 DRF generates search queries].

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

Re: [Django] #25784: help on collect_static fails if no STATIC_ROOT is defined

2015-11-20 Thread Django

#25784: help on collect_static fails if no STATIC_ROOT is defined
-+-
 Reporter:  kaselis  |Owner:
 Type:   |  alexmorozov
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by alexmorozov):

 * has_patch:  0 => 1


Comment:

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

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

[Django] #25788: Enabling the cached template loader should be easier

2015-11-20 Thread Django

#25788: Enabling the cached template loader should be easier
-+
 Reporter:  jaap3|  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Template system  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 Currently enabling the cached template loader is a lot of effort, you'll
 have to change your settings from something like this:

 {{{
 TEMPLATES = [{
 'BACKEND': 'django.template.backends.django.DjangoTemplates',
 'DIRS': [os.path.join(BASE_DIR, 'templates')],
 'APP_DIRS': True
 }]
 }}}

 To this:

 {{{
 TEMPLATES = [{
 'BACKEND': 'django.template.backends.django.DjangoTemplates',
 'DIRS': [os.path.join(BASE_DIR, 'templates')],
 'OPTIONS': {
 'loaders': [
 ('django.template.loaders.cached.Loader', [
 'django.template.loaders.filesystem.Loader',
 'django.template.loaders.app_directories.Loader',
 ]),
 ],
 },
 }]
 }}}

 Making sure you don't forget to take out the `APP_DIRS` option, figuring
 out what loaders to use and getting the nesting of tuples and lists just
 right.

 I propose adding an option the Django template engine called
 `cache_templates` to simplify all of this. Making the second example look
 more like this:

 {{{
 TEMPLATES = [{
 'BACKEND': 'django.template.backends.django.DjangoTemplates',
 'DIRS': [os.path.join(BASE_DIR, 'templates')],
 'APP_DIRS': True
 'OPTIONS': {'cache_templates': DEBUG}
 }]
 }}}

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

[Django] #25787: Existence checks for related database sets

2015-11-20 Thread Django

#25787: Existence checks for related database sets
-+-
 Reporter:  JustusAdam   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Database layer   |Version:  1.8
  (models, ORM)  |   Keywords:  ManyToMany, contains,
 Severity:  Normal   |  in
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+-
 I have recently had to check for presence of a particular object in a set
 of related objects (either ManyToMany or ForeignKey) and I found it
 unnecessary cumbersome not to be able to use the
 {{{in}}} operator.

 I propose to add an implementation of the {{{__contains__}}} method to the
 {{{ManyRelatedManager}}} object which executes something like the
 following query:

 {{{
 def __contains__(self, obj):
 return self.filter(id=obj.id).exists()
 }}}

 which would enable the following sample behaviour:

 {{{
 my_student = request.user.student
 my_course = Course.objects.get(id=course_id)
 is_teacher = my_student in my_course.teachers
 }}}

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

Re: [Django] #25748: Glossary: Project vs App

2015-11-20 Thread Django

#25748: Glossary: Project vs App
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 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 CarstenF):

 * cc: carsten.fuchs@… (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/065.f42542d020450f660e0c36d2dcc0b8a3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25784: help on collect_static fails if no STATIC_ROOT is defined

2015-11-20 Thread Django

#25784: help on collect_static fails if no STATIC_ROOT is defined
-+-
 Reporter:  kaselis  |Owner:
 Type:   |  alexmorozov
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  master
 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
-+-
Changes (by alexmorozov):

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


Comment:

 Will give it a try.

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

Re: [Django] #25685: Deferred model leak

2015-11-20 Thread Django

#25685: Deferred model leak
-+-
 Reporter:  ppetrid  |Owner:  charettes
 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:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * has_patch:  0 => 1
 * version:  master => 1.8


Comment:

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

Re: [Django] #5763: Queryset doesn't have a "not equal" filter operator

2015-11-20 Thread Django

#5763: Queryset doesn't have a "not equal" filter operator
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  qs-rf| Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by CarstenF):

 * cc: carsten.fuchs@… (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/066.327deca08fccc0f7b2f7e10328df8060%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18392: Use utf8mb4 encoding with MySQL 5.5

2015-11-20 Thread Django

#18392: Use utf8mb4 encoding with MySQL 5.5
-+-
 Reporter:  EmilStenstrom|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  utf8mb4 mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Will that setting work nicely with migrations though? I think we need to
 know the index names for some operations like `AlterField`. It seems
 problematic if we have a way that users can vary the index names without
 updating existing names.

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

Re: [Django] #21221: Widgets and Admin's Media should use the configured staticfiles storage to create the right path to a file

2015-11-20 Thread Django

#21221: Widgets and Admin's Media should use the configured staticfiles storage 
to
create the right path to a file
-+-
 Reporter:  Guilherme Gondim |Owner:  codingjoe
  |
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:  staticfiles, admin,  | Triage Stage:  Accepted
  CachedFilesMixin, media, widgets   |
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 comments for improvement on the
 [https://github.com/django/django/pull/5571 pull request].

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

Re: [Django] #25722: add support for `GEOSCovers`

2015-11-20 Thread Django

#25722: add support for `GEOSCovers`
-+--
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ccc8f67b7760dd12faf6007f12a672a8e03f4d88" ccc8f67b]:
 {{{
 #!CommitTicketReference repository=""
 revision="ccc8f67b7760dd12faf6007f12a672a8e03f4d88"
 Fixed #25722 -- Added the GEOSGeometry.covers() method.
 }}}

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

Re: [Django] #25551: makemigrations when adding a ForeignKey to a newly created model along with a unique_together constraint must create fields before the unique_together constraint

2015-11-20 Thread Django

#25551: makemigrations when adding a ForeignKey to a newly created model along 
with
a unique_together constraint must create fields before the unique_together
constraint
+---
 Reporter:  mssnlayam   |Owner:  avojnovicDk
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+---
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"73a6ab6382809d5452907dcff5767403d8d66985" 73a6ab63]:
 {{{
 #!CommitTicketReference repository=""
 revision="73a6ab6382809d5452907dcff5767403d8d66985"
 Fixed #25551 -- Fixed migration operations ordering when adding fields and
 a unique_together constraint.
 }}}

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

Re: [Django] #8851: Please add a default option to list_filter in the admin interface

2015-11-20 Thread Django

#8851: Please add a default option to list_filter in the admin interface
-+-
 Reporter:  Riskable |Owner:  hvdklauw
 |
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, list_filter,  | Triage Stage:  Accepted
  default|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by hvdklauw):

 * needs_better_patch:  1 => 0


Comment:

 Totally forgot to update the ticket, it's all done and ready 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/093.17d9586c6540e26a816b1879d146fe69%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25786: set_*_order raises ValueError when ForeignKey referenced Model also has OneToOneField

2015-11-20 Thread Django

#25786: set_*_order raises ValueError when ForeignKey referenced Model also has
OneToOneField
-+-
 Reporter:  aktiur   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  order_with_respect_to ForeignKey   |
  OneToOneField  |
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/5695 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.1d87befa384b1ca0b5bdb1c2fc6ffda7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15894: SITE_CACHE does not invalidate in multiprocess environments

2015-11-20 Thread Django

#15894: SITE_CACHE does not invalidate in multiprocess environments
+
 Reporter:  Kronuz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.sites   |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  cache invalidation  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by claudep):

 #25783 was a duplicate with [https://github.com/django/django/pull/5692 a
 patch].

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

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

Re: [Django] #25783: Site.objects.get_current() should use Django's cache framework

2015-11-20 Thread Django

#25783: Site.objects.get_current() should use Django's cache framework
-+-
 Reporter:  patrys   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.sites|  Version:  1.8
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 This is a duplicate of #15894.

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

Re: [Django] #25784: help on collect_static fails if no STATIC_ROOT is defined

2015-11-20 Thread Django

#25784: help on collect_static fails if no STATIC_ROOT is defined
--+
 Reporter:  kaselis   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.staticfiles   |  Version:  master
 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
--+
Changes (by claudep):

 * easy:  0 => 1


Comment:

 Yes, it's easy if we make self.local a (cached?) property.

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

Re: [Django] #25715: refresh_from_db fails to update null'ed ForeignKeys

2015-11-20 Thread Django

#25715: refresh_from_db fails to update null'ed ForeignKeys
-+-
 Reporter:  joshkel  |Owner:  timgraham
 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:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * owner:  andersonresende => timgraham
 * has_patch:  0 => 1


Comment:

 @andersonresende, sorry to take this one if you made any progress on it,
 but I wanted to make sure it's fixed for the next 1.8.x release. Feel free
 to review my patch if you can.

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

Re: [Django] #25783: Site.objects.get_current() should use Django's cache framework

2015-11-20 Thread Django

#25783: Site.objects.get_current() should use Django's cache framework
-+-
 Reporter:  patrys   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.sites|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kezabelle):

 * cc: django@… (added)


Comment:

 Additional point for consideration: the default setting for
 `CACHES['default']` is `LocMemCache`, which would have the same problem as
 the current situation where other processes would not be notified of the
 change, as far as I know.

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

Re: [Django] #25786: set_*_order raises ValueError when ForeignKey referenced Model also has OneToOneField

2015-11-20 Thread Django

#25786: set_*_order raises ValueError when ForeignKey referenced Model also has
OneToOneField
-+-
 Reporter:  aktiur   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  order_with_respect_to ForeignKey   |
  OneToOneField  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

Re: [Django] #25783: Site.objects.get_current() should use Django's cache framework

2015-11-20 Thread Django

#25783: Site.objects.get_current() should use Django's cache framework
-+-
 Reporter:  patrys   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.sites|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by patrys):

 `CACHES['default']` is something you control. If you use multiple
 processes, you should set it to a shared-state storage. This is something
 that Django should document and recommend.

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

Re: [Django] #25779: Redundant try block in WSGIHandler

2015-11-20 Thread Django

#25779: Redundant try block in WSGIHandler
--+
 Reporter:  Uran198   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Attila Tovt ):

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


Comment:

 In [changeset:"8092745593e2aa7b54c6de44d12a893772ace3e9" 80927455]:
 {{{
 #!CommitTicketReference repository=""
 revision="8092745593e2aa7b54c6de44d12a893772ace3e9"
 Fixed #25779 -- Removed redundant try block in WSGIHandler
 }}}

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

Re: [Django] #25780: Remove redundant response.status_code assertions in tests

2015-11-20 Thread Django

#25780: Remove redundant response.status_code assertions in tests
-+-
 Reporter:  timgraham|Owner:
 Type:   |  alexmorozov
  Cleanup/optimization   |   Status:  assigned
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:  1|UI/UX:  0
-+-

Comment (by timgraham):

 Correct - thanks!

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

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

Re: [Django] #25781: admin_views tests should mostly use client.force_login()

2015-11-20 Thread Django

#25781: admin_views tests should mostly use client.force_login()
--+
 Reporter:  timgraham |Owner:  awwester
 Type:  Cleanup/optimization  |   Status:  assigned
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:  1 |UI/UX:  0
--+

Comment (by awwester):

 working on topic branch:
 https://github.com/awwester/django/tree/ticket_25781

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

Re: [Django] #25779: Redundant try block in WSGIHandler

2015-11-20 Thread Django

#25779: Redundant try block in WSGIHandler
--+
 Reporter:  Uran198   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
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 Uran198):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #25781: admin_views tests should mostly use client.force_login()

2015-11-20 Thread Django

#25781: admin_views tests should mostly use client.force_login()
--+
 Reporter:  timgraham |Owner:  awwester
 Type:  Cleanup/optimization  |   Status:  assigned
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:  1 |UI/UX:  0
--+
Changes (by awwester):

 * cc: awwester@… (added)
 * status:  new => assigned
 * owner:  nobody => awwester


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

Re: [Django] #25771: Serialization of natural foreign key in migration scripts does not work

2015-11-20 Thread Django

#25771: Serialization of natural foreign key in migration scripts does not work
-+-
 Reporter:  bowensong|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.8
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  database migration   | Triage Stage:
  serialization  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bowensong):

 Replying to [comment:4 timgraham]:
 > Maybe you can define the `natural_key()` method in the migration and
 then add it to the model retrieved from the apps registry:
 > {{{
 > def natural_key(self):
 > ...
 >
 > Teacher = apps.get_model("mytest", "Teacher")
 > Teacher.natural_key = natural_key
 > }}}

 Thanks, this works perfect.

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

Re: [Django] #25780: Remove redundant response.status_code assertions in tests

2015-11-20 Thread Django

#25780: Remove redundant response.status_code assertions in tests
-+-
 Reporter:  timgraham|Owner:
 Type:   |  alexmorozov
  Cleanup/optimization   |   Status:  assigned
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:  1|UI/UX:  0
-+-
Changes (by alexmorozov):

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


Comment:

 @timgraham, are you talking about these? Could there be a situation when a
 view fails but still returns the wanted text? If not, I'll try to remove
 'em.

 (django)inductor@pushino-gw:~/.virtualenvs/django/src/tests$ ag
 'self.assertEqual\(response.status.{0,100}\s*self.assertContains' .

 generic_views/test_base.py
 250:self.assertEqual(response.status_code, 200)
 251:self.assertContains(response, 'About')

 test_client/tests.py
 732:self.assertEqual(response.status_code, 200)
 733:self.assertContains(response, 'This is a test')
 743:self.assertEqual(response.status_code, 200)
 744:self.assertContains(response, echoed_request_line)

 flatpages_tests/test_middleware.py
 60:self.assertEqual(response.status_code, 200)
 61:self.assertContains(response, "Isn't it flat!")
 75:self.assertEqual(response.status_code, 200)
 76:self.assertContains(response, "Isn't it sekrit!")
 81:self.assertEqual(response.status_code, 200)
 82:self.assertContains(response, "Isn't it flat!")
 96:self.assertEqual(response.status_code, 200)
 97:self.assertContains(response, "Isn't it sekrit!")
 111:self.assertEqual(response.status_code, 200)
 112:self.assertContains(response, "Isn't it special!")
 179:self.assertEqual(response.status_code, 200)
 180:self.assertContains(response, "Root")

 flatpages_tests/test_views.py
 60:self.assertEqual(response.status_code, 200)
 61:self.assertContains(response, "Isn't it flat!")
 75:self.assertEqual(response.status_code, 200)
 76:self.assertContains(response, "Isn't it sekrit!")
 100:self.assertEqual(response.status_code, 200)
 101:self.assertContains(response, "Isn't it special!")

 flatpages_tests/test_csrf.py
 60:self.assertEqual(response.status_code, 200)
 61:self.assertContains(response, "Isn't it flat!")
 75:self.assertEqual(response.status_code, 200)
 76:self.assertContains(response, "Isn't it sekrit!")
 81:self.assertEqual(response.status_code, 200)
 82:self.assertContains(response, "Isn't it flat!")

 admin_inlines/tests.py
 495:self.assertEqual(response.status_code, 200)
 496:self.assertContains(response, "Deleting chapter %s would
 require deleting "

 template_tests/test_response.py
 329:self.assertEqual(response.status_code, 200)
 330:self.assertContains(response, 'This is where you can find
 the snark: /snark/')

 view_tests/tests/test_i18n.py
 211:self.assertEqual(response.status_code, 200)
 212:self.assertContains(response, 'emoji')

 admin_custom_urls/tests.py
 65:self.assertEqual(response.status_code, 200)
 66:self.assertContains(response, 'value="My Action"')
 78:self.assertEqual(response.status_code, 200)
 79:self.assertContains(response,
 'dismissAddRelatedObjectPopup')
 91:self.assertEqual(response.status_code, 200)
 92:self.assertContains(response, 'Change action')
 99:self.assertEqual(response.status_code, 200)
 100:self.assertContains(response, 'Change action')

 admin_views/tests.py
 230:self.assertEqual(response.status_code, 200)
 231:self.assertContains(response, 'value="My Section"',
 295:self.assertEqual(response.status_code, 200)
 296:self.assertContains(response,
 'dismissAddRelatedObjectPopup')
 515:self.assertEqual(response.status_code, 200)
 516:self.assertContains(response, '',
 524:self.assertEqual(response.status_code, 200)
 525:self.assertContains(response, '')
 685:self.assertEqual(response.status_code, 200)
 686:self.assertContains(response,
 'employee__person

Re: [Django] #25783: Site.objects.get_current() should use Django's cache framework

2015-11-20 Thread Django

Comment (by patrys):

I've filed this under “cleanup/optimization” but it also qualifies as a
bug report. In any environment that use more than one process the cache
will not invalidate properly.

Consider two worker processes using the same `SITE_ID`. If one of them
updates current `Site` object's `name` field, only this process will see
signals being fired and only its own local cache will be invalidated. For
every second request the old name will be seen.

Django offers no inter-process messaging to notify other workers that
their caches are no longer valid. To properly work around this problem you
need to implement your own `get_current()` (using a shared-state cache
like the cache framework) and monkey-patch either Django or your third-
party dependencies.

What's worse, `runserver` does not use multiple processes. The buggy
behaviour is isolated to production environments and is impossible to
reproduce locally.

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

Re: [Django] #25722: add support for `GEOSCovers`

2015-11-20 Thread Django

#25722: add support for `GEOSCovers`
-+--
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  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 sir-sigurd):

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

Re: [Django] #25771: Serialization of natural foreign key in migration scripts does not work

2015-11-20 Thread Django

#25771: Serialization of natural foreign key in migration scripts does not work
-+-
 Reporter:  bowensong|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.8
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  database migration   | Triage Stage:
  serialization  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Maybe you can define the `natural_key()` method in the migration and then
 add it to the model retrieved from the apps registry:
 {{{
 def natural_key(self):
 ...

 Teacher = apps.get_model("mytest", "Teacher")
 Teacher.natural_key = natural_key
 }}}

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

Re: [Django] #25783: Site.objects.get_current() should use Django's cache framework

2015-11-20 Thread Django

#25783: Site.objects.get_current() should use Django's cache framework
-+-
 Reporter:  patrys   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.sites|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I'm not sure about this. The caching was added in #3766 to avoid database
 queries but with this change I think anyone using the database cache
 backend no longer gets any benefit.

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

Re: [Django] #25782: Discourage usage of cache_page decorator with UpdateCacheMiddleware (or make middleware ignore decorated views)

2015-11-20 Thread Django

#25782: Discourage usage of cache_page decorator with UpdateCacheMiddleware (or
make middleware ignore decorated views)
--+
 Reporter:  int-ua|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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 timgraham):

 * type:  Uncategorized => Cleanup/optimization
 * 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.6bacb259257cd2c8b36a25b4fe6842f3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25607: IIS deployment - WSGI handler

2015-11-20 Thread Django

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

Comment:

Sorry, but the provided information still doesn't demonstrate to me that
Django is at fault (although I never used IIS before and don't have a
setup to reproduce there error).

Maybe you get can help from other IIS users using
TicketClosingReasons/UseSupportChannels and then reopen this with a better
description of why Django is at fault and what change we need to make? It
would also be helpful if you could bisect to the Django commit where
things stopped working. Thanks!

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

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

Re: [Django] #25784: help on collect_static fails if no STATIC_ROOT is defined

2015-11-20 Thread Django

#25784: help on collect_static fails if no STATIC_ROOT is defined
--+
 Reporter:  kaselis   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.staticfiles   |  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 timgraham):

 * needs_better_patch:   => 0
 * component:  Uncategorized => contrib.staticfiles
 * needs_tests:   => 0
 * version:  1.9rc1 => master
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Would be nice if not too difficult.

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

Re: [Django] #25607: IIS deployment - WSGI handler

2015-11-20 Thread Django

#25607: IIS deployment - WSGI handler
---+--
 Reporter:  atarkowska |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  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 atarkowska):

 Please note that I have no issue with deploying application on Unix using
 apache and mod_wsgi or nginx and gunicorn. This is just IIS and 1.8
 problem

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

Re: [Django] #25786: set_*_order raises ValueError when ForeignKey referenced Model also has OneToOneField

2015-11-20 Thread Django

#25786: set_*_order raises ValueError when ForeignKey referenced Model also has
OneToOneField
-+-
 Reporter:  aktiur   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  order_with_respect_to ForeignKey   |
  OneToOneField  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bmispelon):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * severity:  Normal => Release blocker
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Hi,

 The sample code you gave doesn't actually work but I managed to reproduce
 your issue using this:
 {{{#!python
 class Test(TestCase):
 def test(self):
 e = Entity.objects.create()
 d = Dimension.objects.create(entity=e)
 c1 = d.component_set.create()
 c2 = d.component_set.create()
 d.set_component_order([c1.id, c2.id])
 self.assertQuerysetEqual(d.component_set.all(), [c1.id, c2.id],
 attrgetter('pk'))
 }}}

 I did some digging and this testcase worked in Django 1.7 (was broken in
 1.8 by 34ba86706f0db33d9a0ab44e4abb78703e7262a9) but later got fixed by
 7bec480fe2ace94c8e7f0c88485442bfa74436b4 (which will be part of 1.9).


 I don't think we can simply backport
 7bec480fe2ace94c8e7f0c88485442bfa74436b4 to the 1.8 branch though (because
 it's a new feature). We should figure out if we can extract just the part
 that fixed this regression and not the whole feature.

 I'm marking this as a release blocker for 1.8 as a consequence.

 Thanks.

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

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

Re: [Django] #25650: `GEOSGeomerty.eq` should use `equals` not `equals_exact`

2015-11-20 Thread Django

#25650: `GEOSGeomerty.__eq__` should use `equals` not `equals_exact`
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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 sir-sigurd):

 Replying to [comment:2 claudep]:
 > See also the discussion on #25446. The difficulty here is to find an
 acceptable compatibility path and to take into account backend
 differences. Feel free to try!

 `GEOSGeometry` also supports comparison with WKT strings, which works like
 this:

 {{{
 In [25]: Point(0, 0) == 'POINT (0. 0.)'
 Out[25]: True

 In [26]: Point(0, 0) == 'POINT (0 0)'
 Out[26]: False
 }}}

 I think that it would make behavior more consistent if `__eq__`  created
 geometry from WKT string and then used it for comparison, from other hand
 I think that comparison of different types is not pythonic at all. What do
 you think about 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/068.72ddb7f4a0820d5540d689eaadc9de35%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25607: IIS deployment - WSGI handler

2015-11-20 Thread Django

#25607: IIS deployment - WSGI handler
---+--
 Reporter:  atarkowska |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  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 atarkowska):

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


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

[Django] #25786: set_*_order raises ValueError when ForeignKey referenced Model also has OneToOneField

2015-11-20 Thread Django

#25786: set_*_order raises ValueError when ForeignKey referenced Model also has
OneToOneField
-+-
 Reporter:  aktiur   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.8
  (models, ORM)  |   Keywords:  order_with_respect_to
 Severity:  Normal   |  ForeignKey OneToOneField
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Hello everyone,

 I came across a bug where trying to order models with respect to their
 ForeignKey raises a ValueError when the ForeignKey referenced model has a
 OneToOneField to another completely unrelated model.

 Here is a stripped down version of my models that still triggers the bug

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
   from django.db import models


   class Entity(models.Model):
   pass


   class Dimension(models.Model):
   entity = models.OneToOneField('Entity', primary_key=True)


   class Component(models.Model):
   dimension = models.ForeignKey("Dimension")

   class Meta:
   order_with_respect_to = "dimension"
   }}}
 }}}

 And here is the triggering code :
 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
   >>> e = Entity.objects.create
   >>> d = Dimension.objects.create(entity=e)
   >>> c1 = d.dimension_set.create()
   >>> c2 = d.dimension_set.create()
   >>> d.set_dimension_order([c1.id, c2.id])
   }}}
 }}}

 It raises :
 {{{
 #!div style="font-size: 80%"
 Exception:
   {{{
   Traceback (most recent call last):
File "", line 1, in 
File "C:\Miniconda3\envs\anap-mesis\lib\site-
 packages\django\utils\functional.py", line 17, in _curried
  return _curried_func(*(args + moreargs), **dict(kwargs,
 **morekwargs))
File "C:\Miniconda3\envs\anap-mesis\lib\site-
 packages\django\db\models\base.py", line 1683, in method_set_order
  ordered_obj.objects.filter(**{'pk': j, order_name:
 rel_val}).update(_order=i)
File "C:\Miniconda3\envs\anap-mesis\lib\site-
 packages\django\db\models\manager.py", line 127, in manager_method
  return getattr(self.get_queryset(), name)(*args, **kwargs)
File "C:\Miniconda3\envs\anap-mesis\lib\site-
 packages\django\db\models\query.py", line 679, in filter
  return self._filter_or_exclude(False, *args, **kwargs)
File "C:\Miniconda3\envs\anap-mesis\lib\site-
 packages\django\db\models\query.py", line 697, in _filter_or_exclude
  clone.query.add_q(Q(*args, **kwargs))
File "C:\Miniconda3\envs\anap-mesis\lib\site-
 packages\django\db\models\sql\query.py", line 1309, in add_q
  clause, require_inner = self._add_q(where_part, self.used_aliases)
File "C:\Miniconda3\envs\anap-mesis\lib\site-
 packages\django\db\models\sql\query.py", line 1337, in _add_q
  allow_joins=allow_joins, split_subq=split_subq,
File "C:\Miniconda3\envs\anap-mesis\lib\site-
 packages\django\db\models\sql\query.py", line 1178, in build_filter
  self.check_related_objects(field, value, opts)
File "C:\Miniconda3\envs\anap-mesis\lib\site-
 packages\django\db\models\sql\query.py", line 1073, in
 check_related_objects
  self.check_query_object_type(value, opts)
File "C:\Miniconda3\envs\anap-mesis\lib\site-
 packages\django\db\models\sql\query.py", line 1057, in
 check_query_object_type
  (value, opts.object_name))
  ValueError: Cannot query "Entity object": Must be "Dimension" instance
   }}}
 }}}

 I'm using Python 3.4.3 / Django 1.8.4.

 I'm not very familiar with django's internals, but it seems to me that the
 bug happens in django.db.models.base, in method_set_order, on line 1677.
 More precisely, I have noticed that :
 {{{
 #!div style="font-size: 80%"
 Code excerpt:
   {{{
   >>> m.Component._meta.order_with_respect_to.rel
   
   >>> m.Component._meta.order_with_respect_to.rel.field_name
   'entity'
   }}}
 }}}

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

Re: [Django] #25607: IIS deployment - WSGI handler

2015-11-20 Thread Django

#25607: IIS deployment - WSGI handler
---+--
 Reporter:  atarkowska |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.8
 Severity:  Normal |   Resolution:  needsinfo
 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 atarkowska):

 This is the error:


 {{{
 > c:\omero.server\lib\python\omero_web_iis.py(133)()->None
 -> HandleCommandLine(params)
 (Pdb)
 Exception AttributeError: "'NoneType' object has no attribute 'path'" in
 > ignored
 }}}

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

Re: [Django] #25783: Site.objects.get_current() should use Django's cache framework

2015-11-20 Thread Django

#25783: Site.objects.get_current() should use Django's cache framework
-+-
 Reporter:  patrys   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.sites|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by patrys):

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


Comment:

 Pull request: https://github.com/django/django/pull/5692

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

Re: [Django] #25771: Serialization of natural foreign key in migration scripts does not work

2015-11-20 Thread Django

Comment (by bowensong):

OK, my problem was because I'm using the elasticsearch
([https://www.elastic.co/products/elasticsearch]), and elasticsearch uses
JSON format.
In the normal use case, elasticsearch being updated by the `post_save`
signal, but in the event of data migration, the `post_save` function is
not being called. In that case, I have to do the elasticsearch update in
the migration script, and this didn't work because the natural key issue,
I got wrong (unexpected) data in the JSON.
If you are not going to fix it, would you able to provide any suggestions
about how to do this in a correct way?

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

[Django] #25784: help on collect_static fails if no STATIC_ROOT is defined

2015-11-20 Thread Django

#25784: help on collect_static fails if no STATIC_ROOT is defined
---+
 Reporter:  kaselis|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9rc1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I wanted to read what collect_static command does and typed: ./manage.py
 help collect_static. Instead of seeing the help text, I got
 ImproperlyConfigured exception about attempt to use collect_static with
 missing STATIC_ROOT setting. I don't think trying to read help text should
 raise an exception. I've tried with 1.8.6 and 1.9rc1 versions.

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

Re: [Django] #25773: deprecate `MultiPolygon.cascaded_union` in favor of `GEOSGeometry.unary_union`

2015-11-20 Thread Django

#25773: deprecate `MultiPolygon.cascaded_union` in favor of
`GEOSGeometry.unary_union`
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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 sir-sigurd):

 * has_patch:  0 => 1


Comment:

 PR -- https://github.com/django/django/pull/5690

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

56 matches

Mail list logo