Re: [Django] #24030: default id field not migrated correctly

[Django]

#24030: default id field not migrated correctly
+--
 Reporter:  brian   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by brawaga):

 * status:  closed => new
 * version:  1.7 => 1.8
 * resolution:  fixed =>
 * stage:  Accepted => Unreviewed


Comment:

 I ran into it on Django 1.8.6. This bug still remains.

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

Re: [Django] #26005: uri_to_iri() perfoms percent decoding incorrectly

[Django]

#26005: uri_to_iri() perfoms percent decoding incorrectly
---+---
 Reporter:  Chronial   |Owner:  varunnaganathan
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by varunnaganathan):

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


Comment:

 Hi,i wanted to work on this.Added a small tweak to avoid converting the
 percent encoding for '%' i.e. '%25'.basically I'm replacing all instances
 of '%25' in the uri string with '%'.I tried a few tests and they seem to
 work.Do let me know if that's fine.I'll organize the code and post a PR.
 I'm pretty new to contributing to django so I'm sorry if I wasn't suppose
 to self assign this bug.

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

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

Re: [Django] #24974: Cannot create subclass of form created by `modelform_factory()`, e.g. in `ModelAdmin.get_form()`

[Django]

#24974: Cannot create subclass of form created by `modelform_factory()`, e.g. in
`ModelAdmin.get_form()`
-+-
 Reporter:  mrmachine|Owner:  yoongkang
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  form modelform   | Triage Stage:  Accepted
  modelform_factory modeladmin   |
  get_site metaclass |
  modelformmetaclass |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yoongkang):

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


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

Re: [Django] #8936: admin databrowse (read-only view-only permissions)

[Django]

#8936: admin databrowse (read-only view-only permissions)
---+--
 Reporter:  simon  |Owner:  PetrDlouhy
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  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 PetrDlouhy):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #26140: BinaryField value must be declared "binary" in queries to avoid MySQL 5.7+ warning

[Django]

#26140: BinaryField value must be declared "binary" in queries to avoid MySQL 
5.7+
warning
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by tinycogio):

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

Re: [Django] #26143: SyntaxError for import statement {{ unicode_literals }}from django.apps import AppConfig

[Django]

#26143: SyntaxError for import statement {{ unicode_literals }}from django.apps
import AppConfig
---+--
 Reporter:  heseba |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.9
 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 knbk):

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


Comment:

 Duplicate of #25584.

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

[Django] #26143: SyntaxError for import statement {{ unicode_literals }}from django.apps import AppConfig

[Django]

#26143: SyntaxError for import statement {{ unicode_literals }}from django.apps
import AppConfig
---+
 Reporter:  heseba |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 There are some strange error messages when running setup.py which seem to
 be syntax errors in the files below. The application is successfully
 running, however.

 {{{
 *** Error compiling '/tmp/pip-build-
 5hj2p7vr/django/django/conf/app_template/apps.py'...
   File "/tmp/pip-build-5hj2p7vr/django/django/conf/app_template/apps.py",
 line 1
 {{ unicode_literals }}from django.apps import AppConfig
  ^
 SyntaxError: invalid syntax

 *** Error compiling '/tmp/pip-build-
 5hj2p7vr/django/django/conf/app_template/models.py'...
   File "/tmp/pip-build-
 5hj2p7vr/django/django/conf/app_template/models.py", line 1
 {{ unicode_literals }}from django.db import models
  ^
 SyntaxError: invalid syntax


 ...

 Successfully installed myflights django django-bootstrap3 django-
 bootstrap3-datetimepicker
 Cleaning up...

 }}}

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

Re: [Django] #26140: BinaryField value must be declared "binary" in queries to avoid MySQL 5.7+ warning

[Django]

#26140: BinaryField value must be declared "binary" in queries to avoid MySQL 
5.7+
warning
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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

Re: [Django] #26112: Aggregate Sum of GIS Aggregates fails

[Django]

#26112: Aggregate Sum of GIS Aggregates fails
+-
 Reporter:  yellowcap   |Owner:  yellowcap
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  aggregates  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by shaib):

 * has_patch:  0 => 1


Comment:

 When I submitted the PR I was doubtful about it being the right solution,
 but now I've convinced myself that it is.

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

[Django] #26142: Provide a way for model formsets to disallow new object creation

[Django]

#26142: Provide a way for model formsets to disallow new object creation
---+
   Reporter:  timgraham|  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  Forms|Version:  master
   Severity:  Normal   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Model formsets don't provide a way to create an "edit only" view of
 objects. We see users trying to use `extra=0` to accomplish this, but
 that's not reliable as `extra` is merely meant for the extra number of
 forms to display. You can add more forms with Javascript (or just send
 additional post data).

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

Re: [Django] #26141: __lt__ for model instances

[Django]

#26141: __lt__ for model instances
-+-
 Reporter:  srkunze  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 My initial inclination is that it's better to leave this up to each
 project to implement as needed, as a sensible default may not be so clear.
 See #22843 for some related discussion. I guess it's worth raising on the
 DevelopersMailingList -- if you can get a consensus there on how to
 proceed with the implementation, then let's reopen this.

 As a side note, the implementation above assumes the two objects are the
 same type, or at least that they both have fields with the name as what's
 in the first models `Meta.ordering`.

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

[Django] #26141: __lt__ for model instances

[Django]

#26141: __lt__ for model instances
--+
 Reporter:  srkunze   |  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
--+
 We need to sort a list of model instances (not a queryset).

 After some research, we didn't find a standard way to do this with Django
 model instances. Would it be possible to implement {{{__lt__}}} for model
 instances via the meta class mechanism?

 Currently, we write a wrapper where we implemented the following
 {{{__lt__}}} method:

 {{{
 def __lt__(self, other):
 for criteria in self.object._meta.ordering:
 field = criteria[1:] if criteria.startswith('-') else criteria
 mine = getattr(self.object, field)
 theirs = getattr(other.object, field)
 if isinstance(mine, unicode):
 mine = locale.strxfrm(mine.encode('utf8'))
 theirs = locale.strxfrm(theirs.encode('utf8'))
 if mine == theirs:
 continue
 if criteria.startswith('-'):
 return mine > theirs
 return mine < theirs
 raise NotImplementedError
 }}}

 Please note, that the implementation is locale-aware.

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

Re: [Django] #26133: AbstractBaseUser missing password validaton

[Django]

#26133: AbstractBaseUser missing password validaton
---+--
 Reporter:  hacknaked  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.auth   |  Version:  1.9
 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 hacknaked):

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


Comment:

 You are right Tim, I got confused by the fact that validation is made not
 only in Models but also in Forms and other places. Sorry for the noise.

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

Re: [Django] #26139: UUIDField value must be declared "binary" to avoid MySQL warning

[Django]

#26139: UUIDField value must be declared "binary" to avoid MySQL warning
-+-
 Reporter:  guilhem-bichot   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  MySQL| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Yes, Claude is correct. Django's `UUIDField` uses `char(32)` -- the
 `binary(16)` representation is a third-party implementation. The warnings
 I'm seeing for Django's test suite are for `BinaryField` (created #26140).

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

[Django] #26140: BinaryField value must be declared "binary" in queries to avoid MySQL 5.7+ warning

[Django]

#26140: BinaryField value must be declared "binary" in queries to avoid MySQL 
5.7+
warning
-+-
   Reporter:  timgraham  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 There are a couple warnings with running the Django test suite on MySQL
 5.7:
 {{{
 test_json_serializer (serializers.test_data.SerializerDataTests) ...
 /media/sf_django/django/db/backends/mysql/base.py:112: Warning: Invalid
 utf8 character string: 'FD00'
   return self.cursor.execute(query, args)

 test_set_and_retrieve (model_fields.tests.BinaryFieldTests) ...
 /media/sf_django/django/db/backends/mysql/base.py:112: Warning: Invalid
 utf8 character string: 'FE'
 }}}
 I think these are both fixed by changing our queries from something like

 {{{
 cursor.execute("""
 INSERT INTO `field` (binary)
 VALUES (%s)
 """, data)
 }}}
 to:
 {{{
 cursor.execute("""
 INSERT INTO `field` (binary)
 VALUES (_binary %s)
 """, data)
 }}}
 The "_binary" tells MySQL that the following string is to be interpreted
 as binary, not to be interpreted/validated as utf8.
 http://dev.mysql.com/doc/refman/5.7/en/charset-literal.html

 There's some background in #26139.

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

Re: [Django] #26133: AbstractBaseUser missing password validaton

[Django]

#26133: AbstractBaseUser missing password validaton
---+--
 Reporter:  hacknaked  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by timgraham):

 I'm not sure how/if that would work because the final value for `password`
 is the hashed password and that's not the one we want to validate. Can you
 describe or give example code of the case where you're seeing validation
 is missing?

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

Re: [Django] #26129: bound forms do not display disabled field initial values

[Django]

#26129: bound forms do not display disabled field initial values
-+-
 Reporter:  dieselmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.9
 Severity:  Release blocker  |   Resolution:
 Keywords:  disabled fields, | Triage Stage:  Accepted
  forms  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * Attachment "26129-test.diff" added.


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

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

Re: [Django] #26129: bound forms do not display disabled field initial values

[Django]

#26129: bound forms do not display disabled field initial values
-+-
 Reporter:  dieselmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.9
 Severity:  Release blocker  |   Resolution:
 Keywords:  disabled fields, | Triage Stage:  Accepted
  forms  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Seems to be an important bug in a new feature in 1.9 (#25078). Possible
 test attached -- may need to be adjusted depending on the actual solution.

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

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

Re: [Django] #22377: SQL Logging throws an exception when fields have utf-8 characters

[Django]

#22377: SQL Logging throws an exception when fields have utf-8 characters
-+-
 Reporter:  rolanvc@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  sql logging for  | Triage Stage:
  utf-8  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Old description:

> In django/db/backends/util.py, in CursorDebugWrapper.execute, the line:
>
>  logger.debug('(%.3f) %s; args=%s' % (duration, sql, params),
> extra={'duration': duration, 'sql': sql, 'params':
> params}
> )
>
> throws a "UnicodeDecodeError:ascii codec  " when calling model.save()
> when some fields have utf-8/non-ascii values.  My only workaround is to
> modify it to:
>
>  logger.debug('(%.3f) %s; args=%s' % (duration, sql.decode('utf-8'),
> params),
> extra={'duration': duration, 'sql': sql, 'params':
> params}
> )
>
> I'm hoping there's a better and more elegant way that I could use.
>
> Thanks!
> =)

New description:

 In django/db/backends/util.py, in CursorDebugWrapper.execute, the line:
 {{{
  logger.debug('(%.3f) %s; args=%s' % (duration, sql, params),
 extra={'duration': duration, 'sql': sql, 'params': params}
 )
 }}}
 throws a "UnicodeDecodeError:ascii codec  " when calling model.save()
 when some fields have utf-8/non-ascii values.  My only workaround is to
 modify it to:
 {{{
  logger.debug('(%.3f) %s; args=%s' % (duration, sql.decode('utf-8'),
 params),
 extra={'duration': duration, 'sql': sql, 'params': params}
 )
 }}}
 I'm hoping there's a better and more elegant way that I could use.

 Thanks!
 =)

--

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

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

Re: [Django] #26139: UUIDField value must be declared "binary" to avoid MySQL warning

[Django]

#26139: UUIDField value must be declared "binary" to avoid MySQL warning
-+-
 Reporter:  guilhem-bichot   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 I thought that on non-PostgreSQL databases, the value of UUIDs were always
 saved as strings (`.hex` representation). Is it not the 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/072.a5e125a28fc95cfa2b48fbbc1c64c7eb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25546: Duplicate queries on nested Prefetch objects with custom queries

[Django]

#25546: Duplicate queries on nested Prefetch objects with custom queries
-+-
 Reporter:  piquadrat|Owner:
 Type:   |  francoisfreitag
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  prefetch,| Triage Stage:  Ready for
  prefetch_related   |  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:"bdbe50a491ca41e7d4ebace47bfe8abe50a58211" bdbe50a4]:
 {{{
 #!CommitTicketReference repository=""
 revision="bdbe50a491ca41e7d4ebace47bfe8abe50a58211"
 Fixed #25546 -- Prevented duplicate queries with nested
 prefetch_related().
 }}}

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

Re: [Django] #17208: Dogfood class-based views in contrib.admin

[Django]

#17208: Dogfood class-based views in contrib.admin
-+-
 Reporter:  melinath |Owner:  yoongkang
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  class-based views| Triage Stage:  Accepted
  admin  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yoongkang):

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


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

Re: [Django] #26122: copy.copy() broken with SimpleLazyObject in 1.8.5

[Django]

#26122: copy.copy() broken with SimpleLazyObject in 1.8.5
-+-
 Reporter:  knyghty  |Owner:
 |  benjaminjkraft
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.8
 Severity:  Release blocker  |   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:"dee5896b55385d2c66d8c1b8386604868f7fc6b4" dee5896]:
 {{{
 #!CommitTicketReference repository=""
 revision="dee5896b55385d2c66d8c1b8386604868f7fc6b4"
 [1.9.x] Fixed #26122 -- Fixed copying a LazyObject

 Shallow copying of `django.utils.functional.LazyObject` or its subclasses
 has
 been broken in a couple of different ways in the past, most recently due
 to
 35355a4.

 Backport of 13023ba86746980aace2341ba32a9419e7567751 from master
 }}}

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

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

Re: [Django] #26122: copy.copy() broken with SimpleLazyObject in 1.8.5

[Django]

#26122: copy.copy() broken with SimpleLazyObject in 1.8.5
-+-
 Reporter:  knyghty  |Owner:
 |  benjaminjkraft
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.8
 Severity:  Release blocker  |   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:"79c3950562a3f9c9d6d5e37990dfa9eb84052de7" 79c39505]:
 {{{
 #!CommitTicketReference repository=""
 revision="79c3950562a3f9c9d6d5e37990dfa9eb84052de7"
 [1.8.x] Fixed #26122 -- Fixed copying a LazyObject

 Shallow copying of `django.utils.functional.LazyObject` or its subclasses
 has
 been broken in a couple of different ways in the past, most recently due
 to
 35355a4.
 }}}

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

Re: [Django] #26122: copy.copy() broken with SimpleLazyObject in 1.8.5

[Django]

#26122: copy.copy() broken with SimpleLazyObject in 1.8.5
-+-
 Reporter:  knyghty  |Owner:
 |  benjaminjkraft
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"13023ba86746980aace2341ba32a9419e7567751" 13023ba8]:
 {{{
 #!CommitTicketReference repository=""
 revision="13023ba86746980aace2341ba32a9419e7567751"
 Fixed #26122 -- Fixed copying a LazyObject

 Shallow copying of `django.utils.functional.LazyObject` or its subclasses
 has
 been broken in a couple of different ways in the past, most recently due
 to
 35355a4.
 }}}

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

Re: [Django] #26138: GeoJSON Serializer doesn't include geometry_field if it's not in fields (was: Example for GeoJSON Serializer don't work as described)

[Django]

#26138: GeoJSON Serializer doesn't include geometry_field if it's not in fields
-+-
 Reporter:  brot |Owner:  claudep
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #25848: Django 1.9 breaks django_coverage_plugin, template coverage doesn't work

[Django]

#25848: Django 1.9 breaks django_coverage_plugin, template coverage doesn't work
--+
 Reporter:  nedbatchelder |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Template system   |  Version:  1.9
 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:"218cc71073012cc4e72c150421fc89da626d2923" 218cc71]:
 {{{
 #!CommitTicketReference repository=""
 revision="218cc71073012cc4e72c150421fc89da626d2923"
 [1.9.x] Fixed #25848 -- Set template origin on each node.

 Prior to 55f12f8709, the template origin was available on each node via
 `self.token.source[0]`. This behavior was removed when debug handling was
 simplified, but 3rd-party debugging tools still depend on its presence.
 This updates the Parser to set origin on individual nodes. This enables
 the
 source template to be determined even when template extending or including
 is
 used.

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

Re: [Django] #25848: Django 1.9 breaks django_coverage_plugin, template coverage doesn't work

[Django]

#25848: Django 1.9 breaks django_coverage_plugin, template coverage doesn't work
--+
 Reporter:  nedbatchelder |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Template system   |  Version:  1.9
 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:"cfda1fa3f8d95f0f4a369da9021dbd770e5fa44a" cfda1fa3]:
 {{{
 #!CommitTicketReference repository=""
 revision="cfda1fa3f8d95f0f4a369da9021dbd770e5fa44a"
 Fixed #25848 -- Set template origin on each node.

 Prior to 55f12f8709, the template origin was available on each node via
 `self.token.source[0]`. This behavior was removed when debug handling was
 simplified, but 3rd-party debugging tools still depend on its presence.
 This updates the Parser to set origin on individual nodes. This enables
 the
 source template to be determined even when template extending or including
 is
 used.
 }}}

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

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

Re: [Django] #26139: UUIDField value must be declared "binary" to avoid MySQL warning (was: Django's UUID inserted into MySQL => Warning)

[Django]

#26139: UUIDField value must be declared "binary" to avoid MySQL warning
-+-
 Reporter:  guilhem-bichot   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:   => 0
 * keywords:   => MySQL
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 While the report mentions Django 1.6, I've seen these warnings when
 running the tests for the Django master branch (1.10.dev at this time).

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

Re: [Django] #26138: Example for GeoJSON Serializer don't work as described

[Django]

#26138: Example for GeoJSON Serializer don't work as described
--+
 Reporter:  brot  |Owner:  claudep
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  GIS   |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

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

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

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

Re: [Django] #26138: Example for GeoJSON Serializer don't work as described

[Django]

#26138: Example for GeoJSON Serializer don't work as described
--+
 Reporter:  brot  |Owner:  claudep
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  GIS   |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

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

[Django] #26139: Django's UUID inserted into MySQL => Warning

[Django]

#26139: Django's UUID inserted into MySQL => Warning
+
 Reporter:  guilhem-bichot  |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Uncategorized   |Version:  1.9
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I'm a developer of the MySQL DBMS at Oracle.
 A user of Django (Giovanni Go) reported this:
 http://bugs.mysql.com/bug.php?id=79317
 He writes
 "We use UUID stored as binary(16) PK to identify users.
 We're seeing an issue where MySQL is trying to validate binary as UTF8
 starting with MySQL 5.6.27 when trying to insert (and presumingly
 select) users. It will insert the row, but since Django treats MySQL
 warnings as exception, Django will bail out.
 Setup: Python 2.7, Django 1.6.6, MySQL-python 1.2.5, Ubuntu 14.04/OSX
 Django will treat any MySQL warnings as exception if you have DEBUG
 turned on."

 Then he gives a simple Python, Django-less program to show the issue.

 I don't have a Django installation, but the problem is apparently that:
 - Django generates a UUID object per the user's request
 - it inserts it into a MySQL table column, with a simple INSERT:
 INSERT INTO table (column) VALUES('cryptic chars here');
 those can be really cryptic as a UUID string is made of any bytes from
 0x00 to 0xFF.
 - MySQL expects the string to be valid utf8; it has expected this for
 years, but only recently did it start warning when the string is not
 valid utf8 (this is the relevant change:
 https://github.com/mysql/mysql-server/commit/33a2e5abd ).
 - In fact, the string is not valid utf8: certain sequences of bytes do
 not match utf8 characters. The string is binary. Then it would make
 sense for the client to declare it; which is done this way:
 INSERT INTO table (column) VALUES(_binary 'cryptic chars here');
 The _binary prefix says "what I'm giving you next is binary":
 http://dev.mysql.com/doc/refman/5.7/en/charset-literal.html .
 Another option would be to use the x'' syntax in the INSERT:
 https://dev.mysql.com/doc/refman/5.7/en/hexadecimal-literals.html .
 INSERT INTO table (column) VALUES(x'hex codes of cryptic chars here');

 Is there any chance to modify Django's code to address this issue?

 In the report, please ignore any comments starting from "[25 Jan 2:14]

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