Re: [Django] #22125: Unnecessary creation of index for ManyToManyField

[Django]

#22125: Unnecessary creation of index for ManyToManyField
-+-
 Reporter:  tbhtan3@…|Owner:  bwreilly
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:  needsinfo
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by anonymous):

 By the way, a very quick way to verify is to actually create a compound
 index, and then use "EXPLAIN" to check whether a SELECT statement based on
 the leftmost prefix can make use of the compound index. Of course this is
 assuming you have access to those core DBs, of which Oracle could be a bit
 of a 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/075.23d0a57b3b591bb5ec264eb06ff118e5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22125: Unnecessary creation of index for ManyToManyField

[Django]

#22125: Unnecessary creation of index for ManyToManyField
-+-
 Reporter:  tbhtan3@…|Owner:  bwreilly
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:  needsinfo
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by alucard):

 For the core DBs, they usually use B-Tree indexes so I think if [a,b] is
 indexed, then [a] would be a redundant index. To generalize this, any
 leftmost prefix of an indexed tuple would be redundant. This is definitely
 true for MySQL.


 However, for hash indexes (and possibly other types), both [a] and [a,b]
 would be perfectly valid and non-redundant.

 Source: https://dev.mysql.com/doc/refman/5.5/en/index-btree-hash.html
 To quote: "[Hash index] Only whole keys can be used to search for a row.
 (With a B-tree index, any leftmost prefix of the key can be used to find
 rows.)"

 I think we need to have an opt-out on a per table basis (based on Meta
 options), or even better, per ManyToManyField basis (based on a setting to
 __init__)

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

Re: [Django] #22276: BaseFormSet.is_valid() produces ValidationError when there is no management form

[Django]

#22276: BaseFormSet.is_valid() produces ValidationError when there is no 
management
form
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.6
 Severity:  Normal |   Resolution:  invalid
 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 anonymous):

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


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

Re: [Django] #22276: BaseFormSet.is_valid() produces ValidationError when there is no management form

[Django]

#22276: BaseFormSet.is_valid() produces ValidationError when there is no 
management
form
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.6
 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 anonymous):

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


Comment:

 So it turns out this oddball behaviour is necessary because the formset
 cannot be rendered after the lack of management form has been detected,
 hence you should perform special behaviour for these cases of management
 form tampering (e.g. redirecting to the same page to make the user start
 over).

 Sorry for wasting anyone's time on 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.3deba8bf3c9ea997564533d6bef5ec47%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22276: BaseFormSet.is_valid() produces ValidationError when there is no management form

[Django]

#22276: BaseFormSet.is_valid() produces ValidationError when there is no 
management
form
+
 Reporter:  anonymous   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.6
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I was torn between reporting this as a bug or a feature request, but then
 I thought if I make it a feature request it will most likely break a lot
 of Django apps and hence I guess that means it's more of a bug...

 Anyway so the line in question is django/forms/formsets.py:292 (in Django
 version 1.6.1):
 {{{
 for i in range(0, self.total_form_count()):
 }}}

 ...where the self.total_form_count() executes this line
 django/forms/formsets.py:106 (in Django version 1.6.1):
 {{{
 return min(self.management_form.cleaned_data[TOTAL_FORM_COUNT],
 self.absolute_max)
 }}}

 ..which then raises this exception django/forms/formsets.py:87 (in Django
 version 1.6.1):
 {{{
 raise ValidationError(
 _('ManagementForm data is missing or has been tampered
 with'),
 code='missing_management_form',
 )
 }}}

 That stack trace occurs if/when a user submits a formset after stripping
 out the management form hidden fields.

 I have been using Django for a few years now and have never come across an
 exception being raised by a form/formset is_valid() call before. So my
 point is that I believe this exception should never be allowed to leave
 the BaseFormSet.is_valid() call, because it is an oddball behaviour
 compared to the rest of the is_valid() implementations.

 I.e. I believe there should be a check in BaseFormSet.is_valid() which
 checks for the presence of a valid management form (first) and returns
 False if it is not present, as opposed to raising an exception.

 Yes I could wrap the is_valid() call in a try/catch, but I believe this is
 an unnecessary hack caused by a bad design deviation of the implementation
 of the BaseFormSet.is_valid() method.

 I didn't bother creating a patch and test cases, because I have a feeling
 this will get rejected or something like that, but I just thought I should
 bring this up, as I can't find mention of it anywhere and it seems
 important to me.

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

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

Re: [Django] #22125: Unnecessary creation of index for ManyToManyField

[Django]

#22125: Unnecessary creation of index for ManyToManyField
-+-
 Reporter:  tbhtan3@…|Owner:  bwreilly
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:  needsinfo
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by Joshua Yanovski):

 SQL Fiddle may help (I can't link it since it would be marked as spam, but
 the address is pretty easy to determine).  Oracle and MySQL both do this
 as well.

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

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

Re: [Django] #22125: Unnecessary creation of index for ManyToManyField

[Django]

#22125: Unnecessary creation of index for ManyToManyField
-+-
 Reporter:  tbhtan3@…|Owner:  bwreilly
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:  needsinfo
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by bwreilly):

 I've confirmed PostgreSQL and SQLite both exhibit this behavior
 ([https://gist.github.com/anonymous/9575316 Gist]), I'll check MySQL when
 I get a chance. I don't have access to an Oracle instance, but I'll check
 their documentation.

 Additionally, I've fixed the issue with `unique_together=[('a','b','c')]`,
 added tests, and moved the functionality to an overridable method
 ([https://github.com/OneOcean/django/compare/django:master...master
 compare]). Sorry it isn't a pull request at the moment, I'm going to fix
 that Monday.

 Besides [https://docs.djangoproject.com/en/dev/ref/models/options/#unique-
 together Model Meta options unique_together] and
 [https://docs.djangoproject.com/en/dev/ref/models/fields/#db-index Fields
 db_index], should I update the documentation anywhere else?

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

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

Re: [Django] #22275: unique_together with foreign keys fails migration

[Django]

#22275: unique_together with foreign keys fails migration
---+--
 Reporter:  ryanhiebert|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by ryanhiebert):

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


Comment:

 I also have a repository on Github that has a demonstration of the
 problem: https://github.com/ryanhiebert/unique_together_dj_migrations. The
 {{{master}}} branch demonstrates the problem. The {{{syncdb}}} branch
 shows that forcing {{{syncdb}}} behavior makes it work, and the {{{late-
 unique}}} branch demonstrates that waiting until after creating the
 initial migration to add the {{{unique_together}}} constraint is a work-
 around.

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

[Django] #22275: unique_together with foreign keys fails migration

[Django]

#22275: unique_together with foreign keys fails migration
---+
 Reporter:  ryanhiebert|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When {{{unique_together}}} includes foreign keys, sometimes those fields
 are added in separate migrations. (why?) However, {{{unique_together}}}
 remains in the initial migration, before the field referenced in
 {{{unique_together}}} is created. Adding the {{{unique_together}}}
 constraint then fails.

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

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

Re: [Django] #22125: Unnecessary creation of index for ManyToManyField

[Django]

#22125: Unnecessary creation of index for ManyToManyField
-+-
 Reporter:  tbhtan3@…|Owner:  bwreilly
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:  needsinfo
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by sfrost@…):

 The SQL standard *doesn't talk about indexes*, so claiming that it doesn't
 happen to talk about how unique constraints are implemented is a bit like
 trying to rearrange deck chairs on the Titanic.

 The index is redundant in every database that I've ever come across- and
 any that are sensible will do the same.  How can a unique constraint be at
 all performant if there isn't a fast way to find an existing value?
 Allowing some backend to "opt-out" is fine, but it certainly shouldn't be
 the default.

 Note that only the index on the *first* column would be redundant; an
 independent index on the second or subsequent columns which are included
 in a unique constraint could be quite useful.

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

Re: [Django] #22242: Setting cookie that is too large fails silently

[Django]

#22242: Setting cookie that is too large fails silently
-+-
 Reporter:  Euphorbium   |Owner:  pirosb3
   |   Status:  assigned
 Type:  Bug  |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by pirosb3):

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


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

Re: [Django] #22242: Setting cookie that is too large fails silently

[Django]

#22242: Setting cookie that is too large fails silently
-+-
 Reporter:  Euphorbium   |Owner:
   |   Status:  new
 Type:  Bug  |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by pirosb3):

 * has_patch:  0 => 1


Comment:

 I have made a documentation patch. Please let me know if anything else
 should be added.

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

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

[Django] #22274: better tutorial for geodjango

[Django]

#22274: better tutorial for geodjango
---+
 Reporter:  digi_c@…   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  GIS|Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hi, I like geodjango and have some basic knowledge of GIS and django. But
 I feel, that the tutorial as a way to complex for beginners. It's not
 completely bad, but I have a few suggestions:

 * use primitive data like points (less complex to understand)
 * make basic full application (add/edit/show of simple geodata, not only
 via admin interface)
 * show best practise (dataformats instead of WKT, JSON streaming, webmap
 tiling or clustering)

 Maybe anybody has an idea about a rewrite :)

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

Re: [Django] #22268: values_list() on a ManyToManyField returns extra None's when iterated over.

[Django]

#22268: values_list() on a ManyToManyField returns extra None's when iterated 
over.
-+-
 Reporter:  k_sze|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  orm, values_list,|  Needs documentation:  0
  ManyToManyField|  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by anubhav9042):

 One thing I want to clear out is that I think that {{{values}}} and
 {{{values_list}}} return dictionary/tuple type data for all objects
 present, hence this might not be a bug.
 eg.
 {{{
 Class.objects.values_list()
 }}}
 will give you something like
 {{{
 [(1L, 1L, u'Software Engineering'), (2L, 1L, u'Computer Engineering')]
 }}}
 thus for
 {{{
 Class.objects.values_list('students')
 }}}
 you are bound to get
 {{{
 [(1L,), (None,)]
 }}}

 Thoughts??

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

Re: [Django] #21798: Model validation should complain if both `add_now` and `auto_add_now` are specified.

[Django]

#21798: Model validation should complain if both `add_now` and `auto_add_now` 
are
specified.
-+-
 Reporter:  charettes|Owner:  anonymous
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-
Changes (by pirosb3):

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

Re: [Django] #21798: Model validation should complain if both `add_now` and `auto_add_now` are specified.

[Django]

#21798: Model validation should complain if both `add_now` and `auto_add_now` 
are
specified.
-+-
 Reporter:  charettes|Owner:  anonymous
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-

Comment (by pirosb3):

 Hi

 I have opted for a simple DeprecationWarning.
 I also did a small amount of refactoring, to avoid duplication. Let me
 know if we want me to change it.

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

 Probably we will want to squash merge (once ready)? I have done a few
 useless commits that shouldn't mess up the existing history.

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

[django/django] 834d78: Remove u prefixes, skip test unless spatial db.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 834d78ffc3a7eb62d55ac269f83ac0e7473662ea
  
https://github.com/django/django/commit/834d78ffc3a7eb62d55ac269f83ac0e7473662ea
  Author: Marc Tamlyn 
  Date:   2014-03-15 (Sat, 15 Mar 2014)

  Changed paths:
M django/contrib/gis/tests/migrations/migrations/0001_initial.py
M django/contrib/gis/tests/migrations/test_commands.py

  Log Message:
  ---
  Remove u prefixes, skip test unless spatial db.

Refs #22001, d22b291890c1736a40c0ad97448c7318df2eebb2


-- 
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/53244c5aaeae0_1c96fc7d448698b%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22184: template_tests relies on leaking state

[Django]

#22184: template_tests relies on leaking state
-+---
 Reporter:  aaugustin|Owner:  anubhav9042
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"659b5678fcb89417ce1967bc590fdd693f906e69"]:
 {{{
 #!CommitTicketReference repository=""
 revision="659b5678fcb89417ce1967bc590fdd693f906e69"
 Fixed #22184 -- Allowed template_tests.tests to be run isolated
 }}}

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

[django/django] 659b56: Fixed #22184 -- Allowed template_tests.tests to be...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 659b5678fcb89417ce1967bc590fdd693f906e69
  
https://github.com/django/django/commit/659b5678fcb89417ce1967bc590fdd693f906e69
  Author: Anubhav Joshi 
  Date:   2014-03-15 (Sat, 15 Mar 2014)

  Changed paths:
M tests/template_tests/tests.py

  Log Message:
  ---
  Fixed #22184 -- Allowed template_tests.tests to be run isolated


-- 
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/53243ae8a3f49_31ce1289d34783aa%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22184: template_tests relies on leaking state

[Django]

#22184: template_tests relies on leaking state
-+---
 Reporter:  aaugustin|Owner:  anubhav9042
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---

Comment (by anubhav9042):

 An import was missing which created the function used in creating
 {{{cache_loader}}}
 https://github.com/django/django/pull/2433

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

Re: [Django] #22223: reverse() escapes unreserved characters

[Django]

#3: reverse() escapes unreserved characters
--+
 Reporter:  erik.van.zijst@…  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (URLs)   |  Version:  1.6
 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 claudep):

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

Re: [Django] #22223: reverse() escapes unreserved characters

[Django]

#3: reverse() escapes unreserved characters
--+--
 Reporter:  erik.van.zijst@…  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (URLs)   |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by aaugustin):

 Related bug filed against `urllib`: http://bugs.python.org/issue2637

 See also `django.utils.encoding.iri_to_uri` whose docstring discusses RFC
 3986, with different character sets from those I mentioned :(

 See also `django.utils.html.smart_urlquote` which uses
 `safe=b'!*\'();:@&=+$,/?#[]~'`. I'm not sure where that list comes from.

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

Re: [Django] #22267: django.utils.html.smart_urlquote() is incorrectly unquoting the url

[Django]

#22267: django.utils.html.smart_urlquote() is incorrectly unquoting the url
---+
 Reporter:  meenzam@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by erikr):

 You might want to have a look at #3 and
 http://bugs.python.org/issue2637 regarding which characters should be safe
 for which segments of the URL.

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

Re: [Django] #22223: reverse() escapes unreserved characters

[Django]

#3: reverse() escapes unreserved characters
--+--
 Reporter:  erik.van.zijst@…  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (URLs)   |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by aaugustin):

 This change is indeed documented in the release notes. It's a consequence
 of #13260. See [https://code.djangoproject.com/ticket/13260#comment:17 my
 analysis] for details.

 The change suggested here would still preserve the requirements of #13260,
 which was primarily concerned with % characters in variable parts of URLs.

 Now the question is -- what characters do we consider safe? By default
 [http://docs.python.org/2/library/urllib.html#urllib.quote urllib.quote]
 preserves `A-Za-z0-9_.-` and characters defined as safe, which default to
 `/`.

 Based on RFC 1738:

 1. {{{ <>"#%{}|\^~[]`}}} are unsafe and must be encoded (that list
 includes the SPACE character).
 2. `;/?:@=&` are reserved and must be encoded unless they are used for
 their special meaning.
 3. `$-_.+!*'(),` are safe and need not be encoded.

 We can certainly put the third set of characters in the safe list.

 If characters from the second set end up unencoded in URLs generated by
 Django, we start relying on user-agent quirks to re-encode them properly
 in HTTP request lines. However, `/` is part of this list and considered
 safe by the stdlib by default (which may not mean much; the stdlib
 contains many unfortunate API choices).


 Sinc the path segment always starts with a slash following the host and
 ends at the end of the URL or with one of `?`, `;` or `#` (which is always
 unsafe), we may choose to preserve `/:@=&`, that is, all of the second set
 except for `?` and `;`. If we want to be more careful, we may choose to
 preserve only `/` and `:` because `/` is safe by default and `:` is only
 used to separate the protocol from the remainder of the URL. That would
 resolve your problem.

 Can you clarify how you came up with `/:@&=+$,`? If you're including some
 characters from the third set above, you should probably include all of
 them.

 The fix should be backported to 1.6.x since it's a regression.

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

Re: [Django] #22267: django.utils.html.smart_urlquote() is incorrectly unquoting the url

[Django]

#22267: django.utils.html.smart_urlquote() is incorrectly unquoting the url
---+
 Reporter:  meenzam@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by erikr):

 * component:  Template system => Utilities


Comment:

 That commit is built upon your previous patch, so it's very hard for me to
 review. At first sight, I don't think that inline function is really
 necessary, given how simple it is. But the rest I can't really review in
 this way. Also, it would be good to have some tests for how urlize handles
 the invalid URLs for which you now want to return None, as that behaviour
 should not 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/075.7068c2b063634ad21cc626e5a781734e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22184: template_tests relies on leaking state

[Django]

#22184: template_tests relies on leaking state
-+---
 Reporter:  aaugustin|Owner:  anubhav9042
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---

Comment (by anubhav9042):

 I think we need to use
 https://github.com/django/django/blob/master/tests/template_tests/tests.py#L547
 in the loaders. I am having some problem in overriding settings(I have
 tried using this way).

 Thoughts?

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