Re: [Django] #24083: Docs incorrectly refer to form's is_bound() method

[Django]

#24083: Docs incorrectly refer to form's is_bound() method
---+
 Reporter:  ajenhl |Owner:  claudep
 Type:  Bug|   Status:  assigned
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:  1  |UI/UX:  0
---+
Changes (by claudep):

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

Re: [Django] #23815: CsrfViewMiddleware UnicodeDecodeError

[Django]

#23815: CsrfViewMiddleware UnicodeDecodeError
-+-
 Reporter:  codeitloadit |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  middleware   | Triage Stage:  Ready for
  CsrfViewMiddleware |  checkin
  UnicodeDecodeError |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"d8fb557a519a419a53d648ce1ef12dad8673151f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d8fb557a519a419a53d648ce1ef12dad8673151f"
 [1.7.x] Fixed #23815 -- Prevented UnicodeDecodeError in CSRF middleware

 Thanks codeitloadit for the report, living180 for investigations
 and Tim Graham for the review.
 Backport of 27dd7e7271 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/070.0e6d3cce61447bc5712bf3e812dc3099%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23815: CsrfViewMiddleware UnicodeDecodeError

[Django]

#23815: CsrfViewMiddleware UnicodeDecodeError
-+-
 Reporter:  codeitloadit |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  middleware   | Triage Stage:  Ready for
  CsrfViewMiddleware |  checkin
  UnicodeDecodeError |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"27dd7e727153cbf12632a2161217340123687c44"]:
 {{{
 #!CommitTicketReference repository=""
 revision="27dd7e727153cbf12632a2161217340123687c44"
 Fixed #23815 -- Prevented UnicodeDecodeError in CSRF middleware

 Thanks codeitloadit for the report, living180 for investigations
 and Tim Graham for the review.
 }}}

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

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

Re: [Django] #24084: Alias related properties inside values()

[Django]

#24084: Alias related properties inside values()
-+-
 Reporter:  iambibhas|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 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 charettes):

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


Comment:

 > Does it seem like a feature worth considering?

 Yes, this is duplicate of #16735.

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

[Django] #24084: Alias related properties inside values()

[Django]

#24084: Alias related properties inside values()
--+
 Reporter:  iambibhas |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Right now we can use values() to fetch properties like this -

 {{{
 >>> Entry.objects.values('blog')
 [{'blog': 1}, ...]
 }}}

 But I have a case where I need to fetch a property from a related mode so
 I'm doing this -

 {{{
 >>> Boundary.objects.values('id', 'school__liblangagg__class_name')
 [{'school__liblangagg__class_name': 6, 'id': 8999},
 {'school__liblangagg__class_name': 5, 'id': 8954},
 {'school__liblangagg__class_name': 3, 'id': 9000},
 {'school__liblangagg__class_name': 2, 'id': 8942},]
 }}}

 It'd be really convenient if I could alias the related property. Something
 like this -

 {{{
 >>> Boundary.objects.values('id', ('class_name',
 'school__liblangagg__class_name'))
 [{'class_name': 6, 'id': 8999}, ... ]
 }}}

 So in place of the string representing the related property, we could have
 a tuple (alias, related_string). The output looks a bit ugly to pass this
 on to somewhere and it's a bit of work to iterate over all of them and
 replace the key.

 Does it seem like a feature worth considering?

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

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by djbug:

Old description:

> I've experienced this with PostgreSQL but I suspect it could be true for
> other databases too.
>
> [http://www.postgresql.org/docs/9.3/static/indexes-unique.html PostgreSQL
> docs] say:
>
> {{{
> there's no need to manually create indexes on unique columns; doing so
> would just duplicate the automatically-created index.
> }}}
>
> Further the docs say:
>
> `The index covers the columns that make up the [...] unique constraint
> [...] and is the mechanism that enforces the constraint.`
>
> However this model in Django with `unique=True` on a `TextField` creates
> an index on top of the unique constraint.
> {{{
>
> class Book(models.Model):
> name = models.TextField(unique=True)
> }}}
>
> creates following table & constraints in PostgreSQL:
>
> {{{
> CREATE TABLE book (
> id integer NOT NULL,
> name text NOT NULL,
> );
>
> ALTER TABLE ONLY book ADD CONSTRAINT book_name_key UNIQUE (name);
> CREATE INDEX book_name_like ON book USING btree (name text_pattern_ops);
> }}}
>
> Please correct me if I'm wrong. My conclusion is that database enforce
> unique constraint by way of an index. Adding another index is a waste.
> There's some mention of this fact in an old bug report
> ([https://code.djangoproject.com/ticket/3030#comment:3 comment 3] &
> [https://code.djangoproject.com/ticket/3030#comment:6 comment 6] ) but it
> looks like the issue got dropped.
>
> However, if the justification to add a second index is
> [https://code.djangoproject.com/ticket/12234 Bug Report 12234] then it
> might be more efficient to interpret a `unique=True` as
>

> {{{
> CREATE UNIQUE INDEX "book_name_like_idx" ON "book" ("name"
> text_pattern_ops);
>
> }}}
>
> instead of a `UNIQUE` constraint, an `INDEX` and an implicit index by the
> database.

New description:

 I've experienced this with PostgreSQL but I suspect it could be true for
 other databases too.

 [http://www.postgresql.org/docs/9.3/static/indexes-unique.html PostgreSQL
 docs] say:

 {{{
 there's no need to manually create indexes on unique columns; doing so
 would just duplicate the automatically-created index.
 }}}

 Further the docs say:

 `The index covers the columns that make up the [...] unique constraint
 [...] and is the mechanism that enforces the constraint.`

 However this model in Django with `unique=True` on a `TextField` creates
 an index on top of the unique constraint.
 {{{

 class Book(models.Model):
 name = models.TextField(unique=True)
 }}}

 creates following table & constraints in PostgreSQL:

 {{{
 CREATE TABLE book (
 id integer NOT NULL,
 name text NOT NULL,
 );

 ALTER TABLE ONLY book ADD CONSTRAINT book_name_key UNIQUE (name);
 CREATE INDEX book_name_like ON book USING btree (name text_pattern_ops);
 }}}

 Please correct me if I'm wrong. My conclusion is that databases enforce
 unique constraint by way of an index. Adding another index is a waste.
 There's some mention of this fact in an old bug report
 ([https://code.djangoproject.com/ticket/3030#comment:3 comment 3] &
 [https://code.djangoproject.com/ticket/3030#comment:6 comment 6] ) but it
 looks like the issue got dropped.

 I've also verified this with the following create table statement in
 PostgreSQL (no explicit index). A `SELECT` on `name` uses an index scan
 instead of a sequential scan (which means there's an implicit index). So
 in this case, Django doesn't need to add a `CREATE INDEX` statement.

 {{{
 CREATE TABLE book (
 id serial primary key,
 name text UNIQUE
 );
 }}}

 However, if the justification to add a second index is to use
 `text_pattern_ops` ( [https://code.djangoproject.com/ticket/12234 Bug
 Report 12234] ) then it might be more efficient to interpret a
 `unique=True` in the above table as

 {{{
 CREATE TABLE book (
 id serial primary key,
 name text
 );

 CREATE UNIQUE INDEX book_name_like ON book USING btree (name
 text_pattern_ops);
 }}}

 i.e. no `UNIQUE` constraint in the table, only a `UNIQUE INDEX`.

--

--
Ticket URL: 
Django 
The Web 

Re: [Django] #24023: Apps with intial_data and migrations kill test runner

[Django]

#24023: Apps with intial_data and migrations kill test runner
---+--
 Reporter:  alexhayes  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.7
 Severity:  Normal |   Resolution:  duplicate
 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 alexhayes):

 I can confirm that this issue has indeed been resolved in 1.7.2.

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

Re: [Django] #23712: BaseForm._html_output() uses inconsistent formatting for normal row

[Django]

#23712: BaseForm._html_output() uses inconsistent formatting for normal row
+
 Reporter:  alflanagan  |Owner:  raully7
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  master
 Severity:  Normal  |   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):

 * easy:  1 => 0


Comment:

 Did you see the existing [https://github.com/django/django/pull/3529 pull
 request] and the questions on it?

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

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

Re: [Django] #23712: BaseForm._html_output() uses inconsistent formatting for normal row

[Django]

#23712: BaseForm._html_output() uses inconsistent formatting for normal row
+
 Reporter:  alflanagan  |Owner:  raully7
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  1   |UI/UX:  0
+
Changes (by raully7):

 * owner:   => raully7
 * status:  new => assigned


Comment:

 I'll try to create a patch before this weekend.

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

[Django] #24083: Docs incorrectly refer to form's is_bound() method

[Django]

#24083: Docs incorrectly refer to form's is_bound() method
---+
 Reporter:  ajenhl |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 The docs at https://docs.djangoproject.com/en/dev/topics/forms/#bound-and-
 unbound-form-instances refer to a "form’s is_bound() method". However, as
 correctly stated at
 https://docs.djangoproject.com/en/dev/ref/forms/api/#django.forms.Form.is_bound
 this is an attribute, not a 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/049.6591d535af51a8a1bca7ed8387e2cfbf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+-
 Reporter:  svetlyak40wt |Owner:  jdunck
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  model inheritance,   | Triage Stage:  Accepted
  signals, dispatch, proxy,  |
  subclass   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 I think the last effort toward fixing this was jdunck's branch which is
 not available anymore.

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

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

Re: [Django] #23285: Non-deterministic test: admin_views.tests.AdminViewBasicTest.test_change_list_sorting_model_admin_reverse

[Django]

#23285: Non-deterministic test:
admin_views.tests.AdminViewBasicTest.test_change_list_sorting_model_admin_reverse
---+---
 Reporter:  timgraham  |Owner:  parasgithub
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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 timgraham):

 Saw the failure on the CI server today on Python 2.

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

Re: [Django] #24022: Deprecate {% ssi %} template tag

[Django]

#24022: Deprecate {% ssi %} template tag
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  1.8-alpha| 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 Tim Graham ):

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


Comment:

 In [changeset:"de9ebdd39cb4f4b65475b43e0e32772d5a315654"]:
 {{{
 #!CommitTicketReference repository=""
 revision="de9ebdd39cb4f4b65475b43e0e32772d5a315654"
 Fixed #24022 -- Deprecated the ssi tag.
 }}}

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

Re: [Django] #23940: Disallow/warn on fields named exact

[Django]

#23940: Disallow/warn on fields named exact
-+-
 Reporter:  zhiyajun11   |Owner:  nicwest
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by MarkusH):

 * cc: info+coding@… (added)
 * stage:  Ready for checkin => Accepted


Comment:

 Delaying the patch until further investigation

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

Re: [Django] #23940: Disallow/warn on fields named exact

[Django]

#23940: Disallow/warn on fields named exact
-+-
 Reporter:  zhiyajun11   |Owner:  nicwest
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by jarshwah):

 I think we should try to fix this rather than add a warning. It should be
 possible to first check if the "part" is a field and use that if so.

 {{{
 .filter('field__exact__exact')
 }}}

 For each part ("field", "exact", "exact"):

 {{{
 try:
 get_field(part)
 except:
 try:
 get_transform(part)
 except:
 get_lookup(part)
 }}}

 There's already similar code to this that first tries the transform then
 falls back to lookup. We should just need to introduce similar logic that
 first checks if a part is actually a field.

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

Re: [Django] #23940: Disallow/warn on fields named exact

[Django]

#23940: Disallow/warn on fields named exact
-+-
 Reporter:  zhiyajun11   |Owner:  nicwest
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by collinanderson):

 Marcus and I were talking on IRC about this.

 - Is this issue specific to exact? Are _all_ lookups a problem? Looking at
 the code it's probably an issue for `iexact` and `isnull` also.
 - Would it be possible to support having a field named "exact"?

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

Re: [Django] #23940: Disallow/warn on fields named exact

[Django]

#23940: Disallow/warn on fields named exact
-+-
 Reporter:  zhiyajun11   |Owner:  nicwest
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by MarkusH):

 I was thinking about a more general solution that takes all registered
 lookups and transforms into account.

 {{{
MarkusH | wouldn't it make more sense to raise errors if fields,
 transforms and/or lookups clash?
 collinanderson | MarkusH: no idea. i haven't messed around with custom
 lookups
MarkusH | jarshwah_: if you are around ---^
 collinanderson | MarkusH: right, i was thinking that, but it's only an
 issue for primary_key fields, right?
 collinanderson | MarkusH: or any field referenced by a foreignkey
MarkusH | I think it's a general problem
MarkusH | any field you can possibly reference via relations
MarkusH | if you have a standalone model, no FK pointing to or
 from, you should be safe
MarkusH | collinanderson: so, what do I do with the issue now? Do I
 set its triage state back to accepted after I dumped my thoughts there?
 collinanderson | MarkusH: hah. i'm totally not a triager-expert.
 collinanderson | MarkusH: but let's say you have book with fk->author
 collinanderson | MarkusH: ohh, i get it. yeah
MarkusH | ok
 collinanderson | MarkusH: ohh, see, you could do either
 book_author_id__gte=2
 collinanderson | MarkusH: or book__author__id__gte=2
 collinanderson | MarkusH: both of those would work with a field on author
 named "gte"
 collinanderson | right?
MarkusH | yes
 collinanderson | and django doesn't really do that internally at all, but
 id _does_ do __exact a bunch
 collinanderson | right? (at least this ^^ is my assumption)
MarkusH | but what about book__author__foo='bar' (where foo can be
 a field, transform or lookup) do?
 collinanderson | right, and in that case it should be a field, not a
 transform or lookup
MarkusH | afaik, if no lookup is given, exact is assumed
 collinanderson | seems to me you if you wanted a transform/lookup in that
 case you could just do book__author__pk__foo='bar'
 collinanderson | or book__author_id__foo='bar'
MarkusH | ahh, right
MarkusH | thanks
 collinanderson | and maybe it's possible to change django so it allows for
 a field named "exact" in the same way
MarkusH | hang on
 collinanderson | (i'm saying this all in theory, i haven't actually tried
 any of this :)
MarkusH | the test case attached to the PR has a model with a field
 "exact"
 collinanderson | and i assume the bad news is it uses the lookup/transform
 instead of the field?
MarkusH | ok. The PR is about preventing certain problems by not
 allowing them to happen
MarkusH | it specializes the exact lookup
MarkusH | it isn't about a way to find another way to access a
 field
MarkusH | so, in practice, every lookup and transform should
 prevent a field of that name
 }}}

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

Re: [Django] #22608: Migrations optimizer slow (due to double working?)

[Django]

#22608: Migrations optimizer slow (due to double working?)
--+
 Reporter:  davids|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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 MarkusH):

 * needs_better_patch:  1 => 0


Comment:

 PR: https://github.com/django/django/pull/3830

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

Re: [Django] #24022: Deprecate {% ssi %} template tag

[Django]

#24022: Deprecate {% ssi %} template tag
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-alpha| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 See my comments on the PR; it's still close enough to bo considered RFC.

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

Re: [Django] #24022: Deprecate {% ssi %} template tag

[Django]

#24022: Deprecate {% ssi %} template tag
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-alpha| 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 berkerpeksag):

 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/3846 PR #3846] LGTM.

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

Re: [Django] #24022: Deprecate {% ssi %} template tag

[Django]

#24022: Deprecate {% ssi %} template tag
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  1.8-alpha | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by prestontimmons):

 I added a pull request for 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/067.c3c815a83cae1f5ccc0fc2e158495efe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24022: Deprecate {% ssi %} template tag

[Django]

#24022: Deprecate {% ssi %} template tag
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  1.8-alpha | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by prestontimmons):

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

Re: [Django] #24072: Add wsgi.file_wrapper support to responses

[Django]

#24072: Add wsgi.file_wrapper support to responses
+
 Reporter:  collinanderson  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  HTTP handling   |  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
+

Comment (by Tim Graham ):

 In [changeset:"a9aec1154e5b65fcaf608801905a1bbafcfbfbf7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a9aec1154e5b65fcaf608801905a1bbafcfbfbf7"
 Closed files in FileResponse; refs #24072
 }}}

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

Re: [Django] #23359: Add ability to show the migration plan

[Django]

#23359: Add ability to show the migration plan
-+-
 Reporter:  Markush2010  |Owner:  MarkusH
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"e08318b4ef25cfe7d1cfbc5ae7d134ee477506ba"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e08318b4ef25cfe7d1cfbc5ae7d134ee477506ba"
 Refs #23359 -- Removed double newline from output of migrate --list

 Thanks Berker Peksag for the review.
 }}}

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

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

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by djbug:

Old description:

> I've experienced this with PostgreSQL but I suspect it could be true for
> other databases too.
>
> [http://www.postgresql.org/docs/9.3/static/indexes-unique.html PostgreSQL
> docs] say:
>
> {{{
> there's no need to manually create indexes on unique columns; doing so
> would just duplicate the automatically-created index.
> }}}
>
> Further the docs say:
>
> `The index covers the columns that make up the [...] unique constraint
> [...] and is the mechanism that enforces the constraint.`
>
> However this model in Django with `unique=True` on a `TextField` creates
> an index on top of the unique constraint.
> {{{
>
> class Book(models.Model):
> name = models.TextField(unique=True)
> }}}
>
> creates following table & constraints in PostgreSQL:
>
> {{{
> CREATE TABLE book (
> id integer NOT NULL,
> name text NOT NULL,
> );
>
> ALTER TABLE ONLY book ADD CONSTRAINT book_name_key UNIQUE (name);
> CREATE INDEX book_name_like ON book USING btree (name text_pattern_ops);
> }}}
>
> Please correct me if I'm wrong. My conclusion is that database enforce
> unique constraint by way of an index. Adding another index is a waste.
> There's some mention of this fact in an old bug report
> ([https://code.djangoproject.com/ticket/3030#comment:3 comment 3] &
> [https://code.djangoproject.com/ticket/3030#comment:6 comment 6] ) but it
> looks like the issue got dropped.
>
> However, if the justification to add a second index is
> [https://code.djangoproject.com/ticket/12234 Bug Report 12234] then it
> might be more efficient to interpret a unique constraint as
>

> {{{
> CREATE UNIQUE INDEX "book_name_like_idx" ON "book" ("name"
> text_pattern_ops);
>
> }}}
>
> instead of a `UNIQUE` constraint, an `INDEX` and an implicit index by the
> database.

New description:

 I've experienced this with PostgreSQL but I suspect it could be true for
 other databases too.

 [http://www.postgresql.org/docs/9.3/static/indexes-unique.html PostgreSQL
 docs] say:

 {{{
 there's no need to manually create indexes on unique columns; doing so
 would just duplicate the automatically-created index.
 }}}

 Further the docs say:

 `The index covers the columns that make up the [...] unique constraint
 [...] and is the mechanism that enforces the constraint.`

 However this model in Django with `unique=True` on a `TextField` creates
 an index on top of the unique constraint.
 {{{

 class Book(models.Model):
 name = models.TextField(unique=True)
 }}}

 creates following table & constraints in PostgreSQL:

 {{{
 CREATE TABLE book (
 id integer NOT NULL,
 name text NOT NULL,
 );

 ALTER TABLE ONLY book ADD CONSTRAINT book_name_key UNIQUE (name);
 CREATE INDEX book_name_like ON book USING btree (name text_pattern_ops);
 }}}

 Please correct me if I'm wrong. My conclusion is that database enforce
 unique constraint by way of an index. Adding another index is a waste.
 There's some mention of this fact in an old bug report
 ([https://code.djangoproject.com/ticket/3030#comment:3 comment 3] &
 [https://code.djangoproject.com/ticket/3030#comment:6 comment 6] ) but it
 looks like the issue got dropped.

 However, if the justification to add a second index is
 [https://code.djangoproject.com/ticket/12234 Bug Report 12234] then it
 might be more efficient to interpret a `unique=True` as


 {{{
 CREATE UNIQUE INDEX "book_name_like_idx" ON "book" ("name"
 text_pattern_ops);

 }}}

 instead of a `UNIQUE` constraint, an `INDEX` and an implicit index by the
 database.

--

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

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by djbug):

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


Old description:

> I've experienced this with PostgreSQL but I suspect it could be true for
> other databases too.
>
> [http://www.postgresql.org/docs/9.3/static/indexes-unique.html PostgreSQL
> docs] say:
>
> {{{
> there's no need to manually create indexes on unique columns; doing so
> would just duplicate the automatically-created index.
> }}}
>
> Further the docs say:
>
> `The index covers the columns that make up the [...] unique constraint
> [...] and is the mechanism that enforces the constraint.`
>
> However this model in Django with `unique=True` on a `TextField` creates
> an index on top of the unique constraint.
> {{{
>
> class Book(models.Model):
> name = models.TextField(unique=True)
> }}}
>
> creates following table & constraints in PostgreSQL:
>
> {{{
> CREATE TABLE book (
> id integer NOT NULL,
> name text NOT NULL,
> );
>
> ALTER TABLE ONLY book ADD CONSTRAINT book_name_key UNIQUE (name);
> CREATE INDEX book_name_like ON book USING btree (name text_pattern_ops);
> }}}
>
> Please correct me if I'm wrong. My conclusion is that database enforce
> unique constraint by way of an index. Adding another index is a waste.
> There's some mention of this fact in an old bug report
> ([https://code.djangoproject.com/ticket/3030#comment:3 comment 3] &
> [https://code.djangoproject.com/ticket/3030#comment:6 comment 6] ) but it
> looks like the issue got dropped.
>
> However, if the justification to add a second index is
> [https://code.djangoproject.com/ticket/12234 Bug Report 12234] then it
> might be more efficient to interpret a unique constraint as
>

> {{{
> CREATE UNIQUE INDEX "book_name_like" ON "book" ("name" text_pattern_ops);
>
> }}}

New description:

 I've experienced this with PostgreSQL but I suspect it could be true for
 other databases too.

 [http://www.postgresql.org/docs/9.3/static/indexes-unique.html PostgreSQL
 docs] say:

 {{{
 there's no need to manually create indexes on unique columns; doing so
 would just duplicate the automatically-created index.
 }}}

 Further the docs say:

 `The index covers the columns that make up the [...] unique constraint
 [...] and is the mechanism that enforces the constraint.`

 However this model in Django with `unique=True` on a `TextField` creates
 an index on top of the unique constraint.
 {{{

 class Book(models.Model):
 name = models.TextField(unique=True)
 }}}

 creates following table & constraints in PostgreSQL:

 {{{
 CREATE TABLE book (
 id integer NOT NULL,
 name text NOT NULL,
 );

 ALTER TABLE ONLY book ADD CONSTRAINT book_name_key UNIQUE (name);
 CREATE INDEX book_name_like ON book USING btree (name text_pattern_ops);
 }}}

 Please correct me if I'm wrong. My conclusion is that database enforce
 unique constraint by way of an index. Adding another index is a waste.
 There's some mention of this fact in an old bug report
 ([https://code.djangoproject.com/ticket/3030#comment:3 comment 3] &
 [https://code.djangoproject.com/ticket/3030#comment:6 comment 6] ) but it
 looks like the issue got dropped.

 However, if the justification to add a second index is
 [https://code.djangoproject.com/ticket/12234 Bug Report 12234] then it
 might be more efficient to interpret a unique constraint as


 {{{
 CREATE UNIQUE INDEX "book_name_like_idx" ON "book" ("name"
 text_pattern_ops);

 }}}

 instead of a `UNIQUE` constraint, an `INDEX` and an implicit index by the
 database.

--

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

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

[Django] #24082: Unique=True on TextField or CharField should not create an index

[Django]

#24082: Unique=True on TextField or CharField should not create an index
--+
 Reporter:  djbug |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I've experienced this with PostgreSQL but I suspect it could be true for
 other databases too.

 [http://www.postgresql.org/docs/9.3/static/indexes-unique.html PostgreSQL
 docs] say:

 {{{
 there's no need to manually create indexes on unique columns; doing so
 would just duplicate the automatically-created index.
 }}}

 Further the docs say:

 `The index covers the columns that make up the [...] unique constraint
 [...] and is the mechanism that enforces the constraint.`

 However this model in Django with `unique=True` on a `TextField` creates
 an index on top of the unique constraint.
 {{{

 class Book(models.Model):
 name = models.TextField(unique=True)
 }}}

 creates following table & constraints in PostgreSQL:

 {{{
 CREATE TABLE book (
 id integer NOT NULL,
 name text NOT NULL,
 );

 ALTER TABLE ONLY book ADD CONSTRAINT book_name_key UNIQUE (name);
 CREATE INDEX book_name_like ON book USING btree (name text_pattern_ops);
 }}}

 Please correct me if I'm wrong. My conclusion is that database enforce
 unique constraint by way of an index. Adding another index is a waste.
 There's some mention of this fact in an old bug report
 ([https://code.djangoproject.com/ticket/3030#comment:3 comment 3] &
 [https://code.djangoproject.com/ticket/3030#comment:6 comment 6] ) but it
 looks like the issue got dropped.

 However, if the justification to add a second index is
 [https://code.djangoproject.com/ticket/12234 Bug Report 12234] then it
 might be more efficient to interpret a unique constraint as


 {{{
 CREATE UNIQUE INDEX "book_name_like" ON "book" ("name" text_pattern_ops);

 }}}

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

Re: [Django] #23815: CsrfViewMiddleware UnicodeDecodeError

[Django]

#23815: CsrfViewMiddleware UnicodeDecodeError
-+-
 Reporter:  codeitloadit |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  middleware   | Triage Stage:  Ready for
  CsrfViewMiddleware |  checkin
  UnicodeDecodeError |
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/070.52953bdd1f35ffa94a8f5a9aa47faf85%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23861: Fields referenced in migrations cannot be (re)moved, even if migrations have been squashed

[Django]

#23861: Fields referenced in migrations cannot be (re)moved, even if migrations
have been squashed
-+-
 Reporter:  spookylukey  |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"789baf9c3a432297ff775aee7f174494e4fd9962"]:
 {{{
 #!CommitTicketReference repository=""
 revision="789baf9c3a432297ff775aee7f174494e4fd9962"
 Fixed test failures introduced in refs #23861.
 }}}

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

Re: [Django] #24081: Latest six update broke Python 2.5 compatibility

[Django]

#24081: Latest six update broke Python 2.5 compatibility
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.4
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"2fd8054fda5b8ec304d675f82f4bd80c16e3fd95"]:
 {{{
 #!CommitTicketReference repository=""
 revision="2fd8054fda5b8ec304d675f82f4bd80c16e3fd95"
 [1.4.x] Fixed #24081 -- Downgraded six to 1.8.0.

 This reverts commit a25c444bc701b496f2b05f57fc3ec42cdac9dd85.

 six 1.9+ requires Python 2.6 so this commit restores Python 2.5
 compatibility.
 }}}

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

Re: [Django] #24081: Latest six update broke Python 2.5 compatibility (was: Latest six update broken Python 2.5 compatibility)

[Django]

#24081: Latest six update broke Python 2.5 compatibility
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 We'll downgrade six to 1.8 as it has dropped Python 2.5 support in 1.9+.

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

Re: [Django] #24078: GenericIPAddressField is inconsistent with nulls

[Django]

#24078: GenericIPAddressField is inconsistent with nulls
-+-
 Reporter:  jarshwah |Owner:  jarshwah
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by loic):

 All bug fixes are backwards incompatible by nature, I don't think release
 notes are required here.

 LGTM.

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

Re: [Django] #23931: db_manager() method doesn't increment creation_counter

[Django]

#23931: db_manager() method doesn't increment creation_counter
-+-
 Reporter:  rhettg   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by loic):

 * cc: loic (added)


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

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

Re: [Django] #23931: db_manager() method doesn't increment creation_counter

[Django]

#23931: db_manager() method doesn't increment creation_counter
-+-
 Reporter:  rhettg   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by loic):

 I'm sitting on the fence here.

 `db_manager()` was designed to generate short-lived managers, not to be
 assigned as class managers. That said, other short-lived managers (and
 short-lived fields in custom lookups/expressions for that matter) increase
 the creation counters (e.g. `Category().article_set`) so `db_manager()`
 probably should too, if only for consistency.

 However supporting non-empty `db` or `hints` attributes for long-lived
 managers is something that would require a fair amount of investigation
 and some hard design decisions:

 - Are these supposed to be default values to be used when nothing else is
 provided at query time? In that case what about `hints`, should they be
 merged? Current implementation of `RelatedManager.get_queryset()`
 completely overrides `hints`.

 - Are these supposed to be definitive values? Current implementation of
 `RelatedManager.create|get_or_create|update_or_create()` asks the router
 directly for `db` and doesn't account that one may be set already on the
 manager.

 If we recognize that long-lived managers can have a `db` or `hints` state
 (as it would be the case if we made them `__init__()` arguments) then we
 must define the behavior. Right now setting these may work for some cases,
 but the behavior is largely undefined as far as Django is concerned.

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

[Django] #24081: Latest six update broken Python 2.5 compatibility

[Django]

#24081: Latest six update broken Python 2.5 compatibility
---+
   Reporter:  timgraham|  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Core (Other) |Version:  1.4
   Severity:  Release blocker  |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Only relevant to the 1.4 branch, but we'll need an update of six or a
 workaround before the next release.

 https://bitbucket.org/gutworth/six/issue/111/operatormethodcaller-doesnt-
 exist-on

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

Re: [Django] #23815: CsrfViewMiddleware UnicodeDecodeError

[Django]

#23815: CsrfViewMiddleware UnicodeDecodeError
-+-
 Reporter:  codeitloadit |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  middleware   | Triage Stage:  Accepted
  CsrfViewMiddleware |
  UnicodeDecodeError |
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


Comment:

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

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

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

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

[Django]

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+--
 Reporter:  stevejalim |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  sqlite | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by stevejalim):

 Thanks shaib - I'll see what gdb can turn up.

 Yes, I'd already considered providing a sample project, but that's not
 practical as the segfault appears to happen in different places/times in
 the suite run and a small run does not trigger it. I shall keep digging.

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

Re: [Django] #23815: CsrfViewMiddleware UnicodeDecodeError

[Django]

#23815: CsrfViewMiddleware UnicodeDecodeError
-+-
 Reporter:  codeitloadit |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  middleware   | Triage Stage:  Accepted
  CsrfViewMiddleware |
  UnicodeDecodeError |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Reproducible with:
 {{{
 #!diff
 diff --git a/tests/csrf_tests/tests.py b/tests/csrf_tests/tests.py
 index 9c6e2e5..f22cddb 100644
 --- a/tests/csrf_tests/tests.py
 +++ b/tests/csrf_tests/tests.py
 @@ -300,6 +300,11 @@ class CsrfViewMiddlewareTest(TestCase):
  req2 = CsrfViewMiddleware().process_view(req, post_form_view, (),
 {})
  self.assertNotEqual(None, req2)
  self.assertEqual(403, req2.status_code)
 +# Non-ASCII
 +req.META['HTTP_REFERER'] = b'\xd8B\xf6I\xdf'
 +req2 = CsrfViewMiddleware().process_view(req, post_form_view, (),
 {})
 +self.assertNotEqual(None, req2)
 +self.assertEqual(403, req2.status_code)

  @override_settings(ALLOWED_HOSTS=['www.example.com'])
  def test_https_good_referer(self):
 }}}

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

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

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

[Django]

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+--
 Reporter:  stevejalim |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  sqlite | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by shaib):

 * cc: shaib (added)


Comment:

 `gdb` can be used to debug Python programs at both Python and C levels;
 this may help you.

 See https://docs.python.org/devguide/gdb.html and
 https://wiki.python.org/moin/DebuggingWithGdb

 Another info which may be even more useful is to pinpoint a test which
 causes the segfault. If you can share code (I assume, smaller than your
 entire project) which causes the failure it will be very helpful.

 If possible, try running your code on other versions of Python -- non-
 Ubuntu, or even Python3. You may be able to get a consistent segfault that
 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/068.e8a12316110fd666ea98347b23d0db9f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23815: CsrfViewMiddleware UnicodeDecodeError

[Django]

#23815: CsrfViewMiddleware UnicodeDecodeError
-+-
 Reporter:  codeitloadit |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  middleware   | Triage Stage:  Accepted
  CsrfViewMiddleware |
  UnicodeDecodeError |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by living180):

 I was able to reproduce with Django 1.7.2/Python 2.7.9.  Reproducing
 requires accessing Django using HTTPS, because the affected code is behind
 `if request.is_secure():`.  To achieve this, I used the `django-sslserver`
 application (https://github.com/teddziuba/django-sslserver) in conjunction
 with a simple project with the Django admin enabled.  Using the `requests`
 module to supply a bad `REFERER` header when POST-ing to the admin login
 page:

 {{{#!python
 import requests

 requests.post('https://localhost:8000/admin/login/',
   headers={'referer': '\xd8B\xf6I\xdf'},
   verify=False).text
 }}}

 I get the `UnicodeDecodeError`.

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

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

Re: [Django] #23861: Fields referenced in migrations cannot be (re)moved, even if migrations have been squashed

[Django]

#23861: Fields referenced in migrations cannot be (re)moved, even if migrations
have been squashed
-+-
 Reporter:  spookylukey  |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"c87ee41954737869e6026d6fb12394ec4f79d50a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="c87ee41954737869e6026d6fb12394ec4f79d50a"
 Fixed #23861 -- Added an API to deprecate model fields.

 Thanks Markus Holterman and Berker Peksag for review.
 }}}

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

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

Re: [Django] #8280: Commands framework doesn't support alternate import methods

[Django]

#8280: Commands framework doesn't support alternate import methods
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  command zip  | 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 Claude Paroz ):

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


Comment:

 In [changeset:"6e1c9c6568c405bfa481dda4249abe2960173547"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6e1c9c6568c405bfa481dda4249abe2960173547"
 Fixed #8280 -- Allowed management command discovery for eggs

 Thanks jdetaeye for the report, bhuztez and jdetaeye for the
 initial patches, Tim Graham and Berker Peksag for the reviews.
 }}}

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

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

Re: [Django] #23861: Fields referenced in migrations cannot be (re)moved, even if migrations have been squashed

[Django]

#23861: Fields referenced in migrations cannot be (re)moved, even if migrations
have been squashed
-+-
 Reporter:  spookylukey  |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   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 MarkusH):

 * stage:  Accepted => Ready for checkin


Comment:

 LGTM

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

Re: [Django] #24072: Add wsgi.file_wrapper support to responses

[Django]

#24072: Add wsgi.file_wrapper support to responses
+
 Reporter:  collinanderson  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  HTTP handling   |  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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"3d2cae0896ee8026d1c2c5d31e4c4c8f74f2fef4"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3d2cae0896ee8026d1c2c5d31e4c4c8f74f2fef4"
 Fixed #24072 -- Added FileResponse for streaming binary files.
 }}}

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

Re: [Django] #23861: Fields referenced in migrations cannot be (re)moved, even if migrations have been squashed

[Django]

#23861: Fields referenced in migrations cannot be (re)moved, even if migrations
have been squashed
-+-
 Reporter:  spookylukey  |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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):

 * needs_tests:  1 => 0


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

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

Re: [Django] #24061: When deleting a model with foreignkey, redundant RemoveField created.

[Django]

#24061: When deleting a model with foreignkey, redundant RemoveField created.
+
 Reporter:  SonOfLilit  |Owner:  coldmind
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  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
+
Description changed by coldmind:

Old description:

> {{{
> $ pip freeze
> Django==1.7.1
> wsgiref==0.1.2
> }}}
>
> I add a model that inherits from another model, makemigrations, delete
> that model, makemigrations, and the SQLite backend generates this illegal
> SQL when trying to delete the last field "model_ptr" from the table:
>
> {{{
> INSERT INTO "bug_b__new" () SELECT  FROM "bug_b"
> }}}
>
> Easy repro:
>
> {{{
> $ mkvirtualenv bug
> $ git clone g...@github.com:SonOfLilit/django-sqlite-migrations-bug.git
> $ cd django-sqlite-migrations-bug
> $ python manage.py test
> }}}
>
> Here is what happens:
>
> {{{
> $ python -m pdb manage.py test
> > d:\projects\galago\bug\sqlitebug\manage.py(2)()
> -> import os
> (Pdb) c
> Creating test database for alias 'default'...
> Traceback (most recent call last):
>   File "c:\Python27\Lib\pdb.py", line 1314, in main
> pdb._runscript(mainpyfile)
>   File "c:\Python27\Lib\pdb.py", line 1233, in _runscript
> self.run(statement)
>   File "c:\Python27\Lib\bdb.py", line 400, in run
> exec cmd in globals, locals
>   File "", line 1, in 
>   File "manage.py", line 2, in 
> import os
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\core\management\__init__.py", line 385, in
> execute_from_command_line
> utility.execute()
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\core\management\__init__.py", line 377, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\core\management\commands\test.py", line 50, in
> run_from_argv
> super(Command, self).run_from_argv(argv)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\core\management\base.py", line 288, in run_from_argv
> self.execute(*args, **options.__dict__)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\core\management\commands\test.py", line 71, in execute
> super(Command, self).execute(*args, **options)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\core\management\base.py", line 338, in execute
> output = self.handle(*args, **options)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\core\management\commands\test.py", line 88, in handle
> failures = test_runner.run_tests(test_labels)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\test\runner.py", line 147, in run_tests
> old_config = self.setup_databases()
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\test\runner.py", line 109, in setup_databases
> return setup_databases(self.verbosity, self.interactive, **kwargs)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\test\runner.py", line 299, in setup_databases
> serialize=connection.settings_dict.get("TEST", {}).get("SERIALIZE",
> True),
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\db\backends\creation.py", line 377, in create_test_db
> test_flush=True,
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\core\management\__init__.py", line 115, in call_command
> return klass.execute(*args, **defaults)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\core\management\base.py", line 338, in execute
> output = self.handle(*args, **options)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\core\management\commands\migrate.py", line 160, in handle
> executor.migrate(targets, plan, fake=options.get("fake", False))
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\db\migrations\executor.py", line 63, in migrate
> self.apply_migration(migration, fake=fake)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\db\migrations\executor.py", line 97, in apply_migration
> migration.apply(project_state, schema_editor)
>   File "c:\Users\sonoflilit\.virtualenvs\galago\lib\site-
> packages\django\db\migrations\migration.py", line 107, in apply
> operation.database_forwards(self.app_label, schema_editor,
> project_state, new_state)
>   File 

Re: [Django] #24061: When deleting a model with foreignkey, redundant RemoveField created. (was: Deleting last field from model which inherits from non-abstract model creates redundant removefield ope

[Django]

#24061: When deleting a model with foreignkey, redundant RemoveField created.
+
 Reporter:  SonOfLilit  |Owner:  coldmind
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  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
+

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

Re: [Django] #24067: Renaming models prompts for content type deletions (was: Renaming Models asks for double confirmation (and doesn't preserve relationships?))

[Django]

#24067: Renaming models prompts for content type deletions
-+
 Reporter:  doepunk  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * type:  Bug => New feature
 * stage:  Unreviewed => Accepted


Comment:

 I'm not sure if automating the data migration is a good idea, but we
 should likely at least document these considerations if not.

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

Re: [Django] #23815: CsrfViewMiddleware UnicodeDecodeError

[Django]

#23815: CsrfViewMiddleware UnicodeDecodeError
-+-
 Reporter:  codeitloadit |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  middleware   | Triage Stage:  Accepted
  CsrfViewMiddleware |
  UnicodeDecodeError |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Can you test with Django 1.7 and/or master? 1.6 is only receiving security
 fixes so if this issue has been fixed since then we can close the ticket.

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

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

Re: [Django] #24073: Deactivate translations instead of forcing 'en-us' in management commands

[Django]

#24073: Deactivate translations instead of forcing 'en-us' in management 
commands
-+-
 Reporter:  claudep  |Owner:  claudep
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Unreviewed => Ready for checkin


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

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

Re: [Django] #23815: CsrfViewMiddleware UnicodeDecodeError

[Django]

#23815: CsrfViewMiddleware UnicodeDecodeError
-+-
 Reporter:  codeitloadit |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  middleware   | Triage Stage:  Accepted
  CsrfViewMiddleware |
  UnicodeDecodeError |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by living180):

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


Comment:

 I've seen this in production:  Django 1.6.5, Python 2.7, and here are some
 examples of `REFERER` causing the issue:

 `'\xd8B\xf6I\xdf'`

 `'|\xcaH'`

 Let me know if I can be of any help resolving this issue.

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

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

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

[Django]

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+--
 Reporter:  stevejalim |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  sqlite | 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):

 I think there is little chance we can help without additional information,
 especially the git bisect results.

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

Re: [Django] #24072: Add wsgi.file_wrapper support to responses (was: wsgi.file_wrapper)

[Django]

#24072: Add wsgi.file_wrapper support to responses
+
 Reporter:  collinanderson  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  HTTP handling   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by timgraham):

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

Re: [Django] #24075: Can't migrate contenttypes and auth to zero

[Django]

#24075: Can't migrate contenttypes and auth to zero
-+
 Reporter:  apollo13 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * version:  master => 1.7
 * stage:  Unreviewed => Accepted


Comment:

 If it's feasible, an easy way to introspect whether a model's table exists
 seems useful (not sure if that solution could be backported to 1.7
 though).

 #22411 is where that error message was added, so maybe that fix could be
 modified as well if we can do better.

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

Re: [Django] #23605: ORM neglects to use aliases it has set up when certain multiple subqueries are used

[Django]

#23605: ORM neglects to use aliases it has set up when certain multiple 
subqueries
are used
-+-
 Reporter:  ris  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  orm subquery alias   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ris):

 Hmm. That's interesting. Just upgraded to 1.7.2 and the test case posted
 here is indeed fixed. However it doesn't fix ''our'' specific test case
 that this test was distilled from.

 So that means somewhere in the distillation from our test case to this
 abstract one there is another bug lurking.

 Should probably open it as another bug if I can pin this one down to
 another failing test case.

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

Re: [Django] #24061: Deleting last field from model which inherits from non-abstract model creates redundant removefield operation

[Django]

#24061: Deleting last field from model which inherits from non-abstract model
creates redundant removefield operation
+
 Reporter:  SonOfLilit  |Owner:  coldmind
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  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 coldmind):

 {{{
  MarkusH, and issue that I posted in last comment is related
 if RemoveField operation on foreignkey (when deleting a whole model) is
 redundant
  truecoldmind: a state that is working.
  if you keep a fk field around w/o the reverenced model being
 available, it is as if you define a fk w/o the model being available.
  truecoldmind: Try a models.py with https://dpaste.de/WAud
  Django will complain and fail to start
  if the FK fields are not removed, you end up with an internal
 state that is exactly as shown there
  MarkusH: At a glance, it looks like those operations remove the
 FKs from the models to be removed, not those pointing at them.
  MarkusH, lets look on example https://dpaste.de/ThsG. When
 deleting ModelB, RemoveField operation will be created. For what? We
 remove only ModelB, this foreignkey is the field of ModelB, and will be
 deleted if ModelB will be dropped
  truecoldmind: As I said above, I think this is to make sure that
 the reverse relationships are removed from the models that remain.
  ok, I'll have a more detailed look at the code
  shaib, in that case foreignkey is only part of ModelB and
 does not affects other models
  no, ModelA has a modelb attribute. Look up reverse relationships.
  Sorry, modelb_set.
  shaib, it have it because foreignkey is present in model.
 How it is related to schema migration ?
  This is indeed weired.
  migrations also manage the models in memory (so that data
 migrations can use them)
  I don't see a reason for the RemoveField operations (yet)
  truecoldmind: the reverse relation for a FK field (e.g. FK from
 Book to Author: book_set) is created by the FK field
  shaib: please correct me if I'm wrong ;)
  So, if I delete the Book model (and thus don't have a FK to
 Author anymore), there can't be a reverse relation
  It would be better IMO if removing a model would clean up all
 reverse relations created by FKs in that model, but I'm not sure this is
 the case.
  that ^
  MarkusH, yes. and with Book as OneToOne field will be as
 author.book. But I don't understand how it is related to table drop
 operation
  shaib: that's what I'd expected as well
  I guess I'm missing something
  if you look at the comment of that function, might be that the
 optimizer is missing something…
  apollo13: I don't see the reason for adding the RemoveField
 operations in the first place
  maybe simplicity for now
  apollo13, what simplicity? If you look at #24061, this
 thing is producing at least 2 bugs (first is it the title of ticket,
 second is in comments)
  https://code.djangoproject.com/ticket/24061
  so?
  apollo13, so what is the exact reason for RemoveField in
 this concrete example?
  truecoldmind: as I said: maybe simplicity
  I'll elaborate: Perhaps the people who wrote migrations realized
 they need to clean up reverse relationships and thought it was simpler to
 do in the autodetector than in the model-deletion operation.
 }}}


 
 Some thoughts how it can be resolved:
 {{{
  maybe another operation is needed here, where only
 `state_forwards` (without database operations) will be available?
  for example, we can create `StateOperation(Operation)`,
 then prohibit database operations here, so we will can do cleanup in that
 way. Or it is must be hidden from user that will be reading the migration
 source?
 }}}

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

Re: [Django] #24077: Error installing Django 1.7.2

[Django]

#24077: Error installing Django 1.7.2
---+--
 Reporter:  duytrung   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.7
 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
---+--
Changes (by claudep):

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

Re: [Django] #8280: Commands framework doesn't support alternate import methods

[Django]

#8280: Commands framework doesn't support alternate import methods
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  command zip  | 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/066.d35b62a50c67932a97bf43a6a86c3cf4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

[Django]

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+--
 Reporter:  stevejalim |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  sqlite | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by stevejalim):

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


Old description:

> A project has a reasonably large number of tests (~1600). As part of our
> dev workflow, we run tests against sqlite first, then against postgres
> before checkin.
>
> On 1.7.1 all tests pass on sqlite, bar some deliberate DB-specific
> exclusions for tests that need specific postgres features. They also all
> pass on postgres.
>
> On 1.7.2, all tests still pass on postgres (though the server needed a
> restart) but the sqlite test run fails at varying points with
> "segmentation fault" (and an exit code of 139, accordingly).
>
> The segmentation fault occurs regardless of whether an in-memory or file-
> based database is used. When the file-based run crashes, the DB is around
> 495k in size.
>
> There is very little output, even at max verbosity, because this is
> coming from something lower down than Django itself. However, because it
> only started happening with 1.7.2 and goes away when we revert to 1.7.1,
> I am assuming a change somewhere caused the regression.
>
> Setup spec:
> *  Headless Virtualbox + Vagrant with 1GB allocated RAM
> *  Ubuntu 14.04 LTS, fully up to date
> *  libsqlite3-0 version: 3.8.2-1ubuntu2 amd64
> *  Python: 2.7.5 (up-to-date version for 14.04 - unclear which parts, if
> any of 2.7.8 have been backported)

New description:

 A project has a reasonably large number of tests (~1600). As part of our
 dev workflow, we run tests against sqlite first, then against postgres
 before checkin.

 On 1.7.1 all tests pass on sqlite, bar some deliberate DB-specific
 exclusions for tests that need specific postgres features. They also all
 pass on postgres.

 On 1.7.2, all tests still pass on postgres (though the server needed a
 restart) but the sqlite test run fails at varying points with
 "segmentation fault" (and an exit code of 139, accordingly).

 The segmentation fault occurs regardless of whether an in-memory or file-
 based database is used. When the file-based run crashes, the DB is around
 495k in size.

 There is very little output, even at max verbosity, because this is coming
 from something lower down than Django itself. However, because it only
 started happening with 1.7.2 and goes away when we revert to 1.7.1, I am
 assuming a change somewhere caused the regression.

 Setup spec:
 *  Headless Virtualbox + Vagrant with 1GB allocated RAM
 *  Ubuntu 14.04 LTS, fully up to date
 *  libsqlite3-0 version: 3.8.2-1ubuntu2 amd64
 *  Python: 2.7.5 (up-to-date version for 14.04 - unclear which parts, if
 any of 2.7.8 have been backported)

 Any steers here would be much appreciated. apollo13 on #django pointed out
 that I could git bisect the commits between 1.7.1 and 1.7.2, which I am
 open to doing if I can make the time.

 Cheers
 Steve

--

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

[Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

[Django]

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+
 Reporter:  stevejalim |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:  sqlite
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 A project has a reasonably large number of tests (~1600). As part of our
 dev workflow, we run tests against sqlite first, then against postgres
 before checkin.

 On 1.7.1 all tests pass on sqlite, bar some deliberate DB-specific
 exclusions for tests that need specific postgres features. They also all
 pass on postgres.

 On 1.7.2, all tests still pass on postgres (though the server needed a
 restart) but the sqlite test run fails at varying points with
 "segmentation fault" (and an exit code of 139, accordingly).

 The segmentation fault occurs regardless of whether an in-memory or file-
 based database is used. When the file-based run crashes, the DB is around
 495k in size.

 There is very little output, even at max verbosity, because this is coming
 from something lower down than Django itself. However, because it only
 started happening with 1.7.2 and goes away when we revert to 1.7.1, I am
 assuming a change somewhere caused the regression.

 Setup spec:
 *  Headless Virtualbox + Vagrant with 1GB allocated RAM
 *  Ubuntu 14.04 LTS, fully up to date
 *  libsqlite3-0 version: 3.8.2-1ubuntu2 amd64
 *  Python: 2.7.5 (up-to-date version for 14.04 - unclear which parts, if
 any of 2.7.8 have been backported)

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

Re: [Django] #24061: Deleting last field from model which inherits from non-abstract model creates redundant removefield operation

[Django]

#24061: Deleting last field from model which inherits from non-abstract model
creates redundant removefield operation
+
 Reporter:  SonOfLilit  |Owner:  coldmind
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  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 MarkusH):

 Regarding your first question: the autodetector needs to remove all
 foreign key fields **in the same app** that point towards to model you are
 removing to keep a working state.

 Regarding your second question: I don't see a correlation between those
 two issues. Please open a new ticket for that 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.329750b3079809b2fa9c99054f820fcd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24061: Deleting last field from model which inherits from non-abstract model creates redundant removefield operation

[Django]

#24061: Deleting last field from model which inherits from non-abstract model
creates redundant removefield operation
+
 Reporter:  SonOfLilit  |Owner:  coldmind
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  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 coldmind):

 Opened question:
 {{{
 truecoldmind> Can anyone explain the exact reason why while deleting model
 in migration need to create foreign key deletion operations?
  I'm talking about this
 
https://github.com/django/django/blob/572ad9a92e08797f12e547477efcce7893159cfb/django/db/migrations/autodetector.py#L619
  if I understand right, when deleting model, where was a
 foreign key, deleting a whole model will delete foreign key index too. But
 field operation removal will be created anyway.
 }}}

 After this I found another related bug.
 Consider following:

 {{{
 class ModelA(models.Model):
 field1 = models.BooleanField(default=False)

 class ModelB(models.Model):
 another_field1 = models.TextField(blank=True)
 related_field = models.ForeignKey(ModelA)
 }}}

 After creating inital migration, I deleted model, so migration will look
 like:

 {{{
 class Migration(migrations.Migration):

 dependencies = [
 ('blankapp', '0001_initial'),
 ]

 operations = [
 migrations.RemoveField(
 model_name='modelb',
 name='related_field',
 ),
 migrations.DeleteModel(
 name='ModelB',
 ),
 ]
 }}}

 And, when you will try to migrate backwards, `LookupError: App 'blankapp'
 doesn't have a 'modelb' model.` will be raised, because migration will try
 to add `related_field` to model which does not exists yet.

 Should this issue be resolved in this ticket or in another?

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

Re: [Django] #24079: Duplicate results of `ManyToManyField` when using 'through' (was: Duplicate results of `ManyToManyField` when using 'though')

[Django]

#24079: Duplicate results of `ManyToManyField` when using 'through'
-+-
 Reporter:  tanzaho  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 tanzaho:

Old description:

> When using a many 2 many relation ship with 'though' parameter, the DB is
> returning duplicates when several relations exists for the same pair of
> objects.
>
> I have the following relations :
>
> {{{
>   tag 1
>   user 1 ->  article 1
>   tag 2
>   user 1 ->  article 1
> }}}
>
> '''Expected behavior :'''
>

> {{{
> user = User.objects.get(pk=1)
> print user.article.all()
> []
> }}}
>

> '''Observed behavior'''
>

> {{{
> user = User.objects.get(pk=1)
> print user.article.all()
> [, ]
> }}}
>
> More details on Stack Overflow :
> http://stackoverflow.com/questions/2065/duplicate-results-of-
> manytomanyfield-when-using-though

New description:

 When using a many 2 many relation ship with 'through' parameter, the DB is
 returning duplicates when several relations exists for the same pair of
 objects.

 I have the following relations :

 {{{
   tag 1
   user 1 ->  article 1
   tag 2
   user 1 ->  article 1
 }}}

 '''Expected behavior :'''


 {{{
 user = User.objects.get(pk=1)
 print user.article.all()
 []
 }}}


 '''Observed behavior'''


 {{{
 user = User.objects.get(pk=1)
 print user.article.all()
 [, ]
 }}}

 More details on Stack Overflow :
 http://stackoverflow.com/questions/2065/duplicate-results-of-
 manytomanyfield-when-using-though

--

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

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

Re: [Django] #24078: GenericIPAddressField is inconsistent with nulls

[Django]

#24078: GenericIPAddressField is inconsistent with nulls
-+-
 Reporter:  jarshwah |Owner:  jarshwah
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Ready for checkin


Comment:

 See PR https://github.com/django/django/pull/3840

 Not sure if release notes are required, or if this could be considered a
 backwards incompatible change.

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

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

Re: [Django] #24079: Duplicate results of `ManyToManyField` when using 'though'

[Django]

#24079: Duplicate results of `ManyToManyField` when using 'though'
-+-
 Reporter:  tanzaho  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 tanzaho):

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


Comment:

 Solved (http://stackoverflow.com/a/2286/2550237)
 One should use distinct() to remove duplicate entries.

 I think a comment in the doc should be appropriated in the many 2 many
 section.

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

[Django] #24079: Duplicate results of `ManyToManyField` when using 'though'

[Django]

#24079: Duplicate results of `ManyToManyField` when using 'though'
--+
 Reporter:  tanzaho   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When using a many 2 many relation ship with 'though' parameter, the DB is
 returning duplicates when several relations exists for the same pair of
 objects.

 I have the following relations :

 {{{
   tag 1
   user 1 ->  article 1
   tag 2
   user 1 ->  article 1
 }}}

 '''Expected behavior :'''


 {{{
 user = User.objects.get(pk=1)
 print user.article.all()
 []
 }}}


 '''Observed behavior'''


 {{{
 user = User.objects.get(pk=1)
 print user.article.all()
 [, ]
 }}}

 More details on Stack Overflow :
 http://stackoverflow.com/questions/2065/duplicate-results-of-
 manytomanyfield-when-using-though

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

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