date:20160418

Re: [Django] #22669: bulk_create with empty model fields fails on oracle

2016-04-18 Thread Django

#22669: bulk_create with empty model fields fails on oracle
-+-
 Reporter:  sns1081@…|Owner:  mnach
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  QuerySet.bulk_create   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mnach):

 My investigation of this subject came to this approach:
 {{{
 cursor.setinputsizes(arg0 = cx_Oracle.NUMBER)
 cursor.execute("select 1 from dual union all select :arg0 from dual", arg0
 = None)
 }}}
 by Anthony Tuininga at [https://sourceforge.net/p/cx-
 oracle/mailman/message/35021744/ cx_Oracle mailing list]

 method setinputsizes is a part of
 [https://www.python.org/dev/peps/pep-0249/#id18 Python Database API
 Specification v2.0] and [https://www.python.org/dev/peps/pep-0248/ Python
 Database API Specification v1.0]. Backends which support it:
 * cx_Oracle > 2.4 ([http://cx-
 oracle.readthedocs.org/en/latest/releasenotes.html#version-2-4 release
 notes])
 * pysycopg > 1.99.12
 
([https://github.com/psycopg/psycopg2/blob/1_99_12/psycopg/cursor_type.c#L821-L839
 github tag 1_99_12])
 * mysqlclient > 0.9.2 ([https://github.com/PyMySQL/mysqlclient-
 python/blame/e76b691d9ea69146ac7f8127a6bdccae53b70973/MySQLdb/cursors.py#L166
 github "blame" on this method])
 * sqlite - don't actually know, but sqlite3 in cpython 2.6.8 supports this
 method

 So, I guess that SQLCompiller classes can contain method like
 "prepare_cursor" which gets arguments from, for example, a database
 wrapper and pass them to setinputsizes method (and maybe to setoutputsize
 if it will be needed)

 I need to ask @devs: Is this approach better than using "cast(:var as
 number)" inside query ?

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

Re: [Django] #26429: Name clash of merge migrations after squashing

2016-04-18 Thread Django

#26429: Name clash of merge migrations after squashing
-+-
 Reporter:  xgenadam |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  makemigrations   | Triage Stage:
  merge clash|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> After squashing migrations, further development can result in a merge
> migration with an identical name to a squashed migration.
> This is old merge is still stored in the django_migrations table and the
> new merge will not be applied.
>
> The workaround is to rename the merge to something unique. However the
> automatically generated names should not clash in the first place.

New description:



--

Comment (by izquierdo):

 The docs in
 
https://github.com/django/django/blob/2cd2d188516475ddf256e6267cd82c495fb5c430/django/db/migrations/autodetector.py#L1129
 say that names are not guaranteed to be unique and the timestamp is just a
 best effort to avoid conflicts. So I think rtpg's suggested fix works well
 for merge migrations, and a test to ensure names don't conflict is not
 necessary.

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

Re: [Django] #26429: Name clash of merge migrations after squashing

2016-04-18 Thread Django

#26429: Name clash of merge migrations after squashing
-+-
 Reporter:  xgenadam |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  makemigrations   | Triage Stage:
  merge clash|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by rtpg):

 Did a bit more digging into this, I believe that the fix is changing
 
[(https://github.com/django/django/blob/master/django/core/management/commands/makemigrations.py#L286)],
 from :

 {{{
 new_migration = subclass("%04i_merge" % (biggest_number + 1), app_label)
 }}}

 to :

 {{{
 timestamp = datetime.datetime.now().strftime("%Y%m%d_%H%M")
 new_migration = subclass("%04i_merge_%s" % (biggest_number + 1,
 timestamp), app_label)
 }}}


 I'm not quite sure how to write tests for this, though. You could write
 some models, generate migrations, squash, generate new ones and then
 confirm that everything got run? But I feel like the current `squash`
 migration tests also cover this, and that there isn't really much in term
 of name conflict tests.

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

Re: [Django] #26429: Name clash of merge migrations after squashing

2016-04-18 Thread Django

#26429: Name clash of merge migrations after squashing
-+-
 Reporter:  xgenadam |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  makemigrations   | Triage Stage:
  merge clash|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by rtpg):

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


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

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

Re: [Django] #26429: Name clash of merge migrations after squashing

2016-04-18 Thread Django

#26429: Name clash of merge migrations after squashing
-+-
 Reporter:  xgenadam |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  makemigrations   | Triage Stage:
  merge clash|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by rtpg):

 I just ran into a similar problem, going to detail what happened:

  - Over the course of development, do a merge migration. In our case, it
 was the 21st migration so got named `0021_merge.py`

  - Squash our migrations, deleting `0021_merge.py`

  - Continue development, and through sheer luck, our next 2st migration is
 also a merge commit. It gets named `0021_merge.py`

 - When running migrations, because the original migration was run, this
 new `0021_merge.py` commit is not run


 In my case, this was the dependencies of `0021_merge.py` (the new one):

 {{{
 dependencies = [
 ('document', '0020_auto_20160413_1834'),
 ('document', '0019_auto_20160414_1150'),
 ]
 }}}

 Because the merge commit wasn't run, some people only had the `0020`
 mainline migrations migrated, some people only had the `0019` branch
 migrations run, and some people (who hadn't run `migrate` in a while) had
 the following happen:

   - `migrate` detects `0021_merge.py` as the leaf node
   - there was record of the (old)  `0021_merge.py` migration
   - the system was like "oh, guess you're up to date!" and then doesn't
 run either branch of the merge commit

 Like the OP, I believe the simplest solution is to timestamp the merge
 migrations.

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

Re: [Django] #26516: Add support for HTML5 minlength attribute on forms.CharField

2016-04-18 Thread Django

#26516: Add support for HTML5 minlength attribute on forms.CharField
-+
 Reporter:  jdufresne|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  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 jdufresne):

 * has_patch:  0 => 1


Comment:

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

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

Re: [Django] #26516: Add support for HTML5 minlength attribute on forms.CharField

2016-04-18 Thread Django

#26516: Add support for HTML5 minlength attribute on forms.CharField
-+
 Reporter:  jdufresne|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 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/067.02e0814dddfb0e488c388a9f73818485%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26508: clean up FieldFile.open documentation

2016-04-18 Thread Django

#26508: clean up FieldFile.open documentation
--+
 Reporter:  tobias|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.9
 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):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => 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.a9fa76adf88419708ee526f50d385493%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26516: Add support for HTML5 minlength attribute on forms.CharField

2016-04-18 Thread Django

#26516: Add support for HTML5 minlength attribute on forms.CharField
-+
 Reporter:  jdufresne|  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Forms|Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Just as there is support for the `maxlength` attribute in rendered forms,
 Django should add the `minlength` attribute when it is defined:

 Description of attribute:

 https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#attr-
 minlength

 Can add alongside `maxlength` attribute:

 
https://github.com/django/django/blob/df8d8d4292684d6ffa7474f1e201aed486f02b53/django/forms/fields.py#L234-L239

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

Re: [Django] #20869: Prevent repetitive output to counter BREACH-type attacks

2016-04-18 Thread Django

#20869: Prevent repetitive output to counter BREACH-type attacks
-+-
 Reporter:  patrys   |Owner:  shaib
 Type:  New feature  |   Status:  assigned
Component:  CSRF |  Version:  master
 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


Comment:

 Looks good pending a final review from security experts.

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

Re: [Django] #26515: trim_joins bug with nested related models using ForeignObject

2016-04-18 Thread Django

#26515: trim_joins bug with nested related models using ForeignObject
-+-
 Reporter:  ornoone  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignObject,   | Triage Stage:
  trim_join, orm |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ornoone):

 done right now.

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

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

Re: [Django] #21523: Models DateField to_python method no longer supports mock dates.

2016-04-18 Thread Django

#21523: Models DateField to_python method no longer supports mock dates.
-+-
 Reporter:  hugo@…   |Owner:  akki
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |
 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):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #26508: clean up FieldFile.open documentation

2016-04-18 Thread Django

#26508: clean up FieldFile.open documentation
-+-
 Reporter:  tobias   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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/064.943ce59f145746067cde5b0f45c27f13%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26502: Lookup of attribute 'id' on model inheritance models in InlineModelAdmin fails when using fk_name of parent model

2016-04-18 Thread Django

#26502: Lookup of attribute 'id' on model inheritance models in InlineModelAdmin
fails when using fk_name of parent model
-+-
 Reporter:  Braintelligence  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Forms|  Version:  1.8
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  id, model| Triage Stage:
  inheritance, inherited model,  |  Unreviewed
  inline |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Braintelligence):

 Thank you for clarifying this, I wouldn't have found out about this so
 quick :).
 I will try to create a custom admin form then and not pursue this any
 further for now. Thank you again, very much.

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

Re: [Django] #26512: Add tests for the SpatialRefSysMixin.get_units() method

2016-04-18 Thread Django

#26512: Add tests for the SpatialRefSysMixin.get_units() method
--+
 Reporter:  timgraham |Owner:  niconoe
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by niconoe):

 * owner:  nobody => niconoe
 * 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.5c73dec288e0556fdf10d7fa3a468dd7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22561: EmailMessage should respect RFC2822 on max line length

2016-04-18 Thread Django

#22561: EmailMessage should respect RFC2822 on max line length
-+-
 Reporter:  notsqrt  |Owner:  levkowetz
 Type:  Bug  |   Status:  assigned
Component:  Core (Mail)  |  Version:  master
 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/065.0980b230ee5de781adfc078777986b63%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26498: Data loss of microseconds on MySQL and SQLite

2016-04-18 Thread Django

#26498: Data loss of microseconds on MySQL and SQLite
-+-
 Reporter:  adamchainz   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"0a411b2224c672ddefc6f9755e7a306d82eaf7c2" 0a411b22]:
 {{{
 #!CommitTicketReference repository=""
 revision="0a411b2224c672ddefc6f9755e7a306d82eaf7c2"
 [1.8.x] Fixed #26498 -- Fixed TimeField microseconds round-tripping on
 MySQL and SQLite.

 Thanks adamchainz for the report and review.

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

Re: [Django] #26498: Data loss of microseconds on MySQL and SQLite

2016-04-18 Thread Django

#26498: Data loss of microseconds on MySQL and SQLite
-+-
 Reporter:  adamchainz   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"51400cbce8165d46fdd380e80a95b6248929b38b" 51400cb]:
 {{{
 #!CommitTicketReference repository=""
 revision="51400cbce8165d46fdd380e80a95b6248929b38b"
 [1.9.x] Fixed #26498 -- Fixed TimeField microseconds round-tripping on
 MySQL and SQLite.

 Thanks adamchainz for the report and review.

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

Re: [Django] #26498: Data loss of microseconds on MySQL and SQLite

2016-04-18 Thread Django

#26498: Data loss of microseconds on MySQL and SQLite
-+-
 Reporter:  adamchainz   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"d3c87a2425b30400c3e6ea76585a9a537b6d0386" d3c87a24]:
 {{{
 #!CommitTicketReference repository=""
 revision="d3c87a2425b30400c3e6ea76585a9a537b6d0386"
 Fixed #26498 -- Fixed TimeField microseconds round-tripping on MySQL and
 SQLite.

 Thanks adamchainz for the report and 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/068.d467d21d83ec657675c2a563c1d9945e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26502: Lookup of attribute 'id' on model inheritance models in InlineModelAdmin fails when using fk_name of parent model

2016-04-18 Thread Django

#26502: Lookup of attribute 'id' on model inheritance models in InlineModelAdmin
fails when using fk_name of parent model
-+-
Reporter: Braintelligence |Owner: nobody
Type: Uncategorized| Status: closed
Component: Forms| Version: 1.8
Severity: Normal | Resolution: invalid
Keywords: id, model| Triage Stage:
inheritance, inherited model, | Unreviewed
inline |
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:

The issue is that the field uses a hidden widget by default so the HTML
uses a

[https://github.com/django/django/blob/2c4c67af94318b15df7d9d37b936e07e8168bc73/django/contrib/admin/templates/admin/includes/fieldset.html#L7
"hidden" CSS class] triggered by

[https://github.com/django/django/blob/2c4c67af94318b15df7d9d37b936e07e8168bc73/django/contrib/admin/helpers.py#L101-L104
Fieldline.has_visible_field]. You could likely change the widget in a
custom admin form to workaround this.

It might make sense to try to allow `readonly_fields` to override override
the widget automatically, but I'm not sure if a solution is feasible or if
it might cause some other problems. In any case, let's open a separate
ticket if you want to pursue such a solution since we've deviated quite a
bit from the original report. 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/073.750cd2cb3f128eff2362b776fc81294a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26514: User.refresh_from_db() does not clear Permission cache.

2016-04-18 Thread Django

#26514: User.refresh_from_db() does not clear Permission cache.
--+
 Reporter:  codingjoe |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  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:  1 |UI/UX:  0
--+

Comment (by codingjoe):

 Thanks :)

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

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

Re: [Django] #26515: trim_joins bug with nested related models using ForeignObject

2016-04-18 Thread Django

#26515: trim_joins bug with nested related models using ForeignObject
-+-
 Reporter:  ornoone  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignObject,   | Triage Stage:
  trim_join, orm |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Could you please send a pull request against master with those changes?
 See our PatchReviewChecklist.

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

Re: [Django] #26515: trim_joins bug with nested related models using ForeignObject

2016-04-18 Thread Django

#26515: trim_joins bug with nested related models using ForeignObject
-+-
 Reporter:  ornoone  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignObject,   | Triage Stage:
  trim_join, orm |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ornoone):

 Replying to [comment:1 akaariai]:
 > Can you create a test for this in Django's test suite? See
 tests/foreign_object/ directory for some similar tests.


 I just forked the django repo (hope it was what you expected) and wrote
 down my tests in tests/foreign_object/.

 the test `test_very_deep_optimized_forward` fail without the patch, and
 after patch, all tests pass on my computer.

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

Re: [Django] #26514: User.refresh_from_db() does not clear Permission cache.

2016-04-18 Thread Django

#26514: User.refresh_from_db() does not clear Permission cache.
--+
 Reporter:  codingjoe |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  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:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"12606d2b99dbfe7d0a8f51818e81a29ea2472943" 12606d2]:
 {{{
 #!CommitTicketReference repository=""
 revision="12606d2b99dbfe7d0a8f51818e81a29ea2472943"
 [1.9.x] Fixed #26514 -- Documented that User.refresh_from_db() doesn't
 clear the permission cache.

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

Re: [Django] #26514: User.refresh_from_db() does not clear Permission cache.

2016-04-18 Thread Django

#26514: User.refresh_from_db() does not clear Permission cache.
--+
 Reporter:  codingjoe |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  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:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * type:  Bug => Cleanup/optimization
 * component:  contrib.auth => Documentation
 * 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.bfa04db4ee7a652989ebf8d21408759b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26514: User.refresh_from_db() does not clear Permission cache.

2016-04-18 Thread Django

#26514: User.refresh_from_db() does not clear Permission cache.
--+--
 Reporter:  codingjoe |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"2c4c67af94318b15df7d9d37b936e07e8168bc73" 2c4c67af]:
 {{{
 #!CommitTicketReference repository=""
 revision="2c4c67af94318b15df7d9d37b936e07e8168bc73"
 Fixed #26514 -- Documented that User.refresh_from_db() doesn't clear the
 permission cache.
 }}}

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

Re: [Django] #26514: User.refresh_from_db() does not clear Permission cache.

2016-04-18 Thread Django

#26514: User.refresh_from_db() does not clear Permission cache.
--+--
 Reporter:  codingjoe |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--

Comment (by codingjoe):

 Maybe it's only me. So a line more of documentation seems to be good
 enough.

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

Re: [Django] #26514: User.refresh_from_db() does not clear Permission cache.

2016-04-18 Thread Django

#26514: User.refresh_from_db() does not clear Permission cache.
--+--
 Reporter:  codingjoe |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--

Comment (by timgraham):

 The `ModelBackend` cache
 [https://docs.djangoproject.com/en/stable/topics/auth/default/#permission-
 caching is documented]. I suppose it wouldn't hurt to add a sentence there
 like "`refresh_from_db()` won't clear this cache."

 The value of `user_permissions` isn't actually cached. The cache is stored
 in a private attribute `user._per_cache`. I'm weary of heading down the
 road of adding custom `refresh_from_db()` methods to all models that have
 similar behavior.

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

Re: [Django] #23356: Unable to create template tag which behaves similar to {% verbatim %}

2016-04-18 Thread Django

#23356: Unable to create template tag which behaves similar to {% verbatim %}
--+
 Reporter:  jrief |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  verbatim  | 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):

 * stage:  Unreviewed => Accepted


Comment:

 I'm open to a solution, although I'm not sure if the change proposed in
 the description is ideal.

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

Re: [Django] #26515: trim_joins bug with nested related models using ForeignObject

2016-04-18 Thread Django

#26515: trim_joins bug with nested related models using ForeignObject
-+-
 Reporter:  ornoone  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignObject,   | Triage Stage:
  trim_join, orm |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

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


Comment:

 Can you create a test for this in Django's test suite? See
 tests/foreign_object/ directory for some similar tests.

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

Re: [Django] #26475: Using functools.partial in model field options causes creation of unnecessary migration on every 'makemigrations' call

2016-04-18 Thread Django

#26475: Using functools.partial in model field options causes creation of
unnecessary migration on every 'makemigrations' call
+
 Reporter:  un-def  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.9
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by schinckel):

 I've created a PR for this issue:
 https://github.com/django/django/pull/6470

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

Re: [Django] #26515: trim_joins bug with nested related models using ForeignObject

2016-04-18 Thread Django

#26515: trim_joins bug with nested related models using ForeignObject
---+
 Reporter:  ornoone|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Database layer (models, ORM)   |Version:  1.9
 Severity:  Normal | Resolution:
 Keywords:  ForeignObject, trim_join, orm  |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by ornoone):

 * Attachment "ForeignObject_from_fields__bug_26515.patch" added.

 patch that keep order of targets in trim_joins

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

Re: [Django] #26515: trim_joins bug with nested related models using ForeignObject

2016-04-18 Thread Django

#26515: trim_joins bug with nested related models using ForeignObject
---+
 Reporter:  ornoone|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Database layer (models, ORM)   |Version:  1.9
 Severity:  Normal | Resolution:
 Keywords:  ForeignObject, trim_join, orm  |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by ornoone):

 * Attachment "ForeignObject_from_fields__bug_26515.tar.gz" added.

 simple app to trigger the 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/065.39d477d767a51ef15152a0c67f8ca1a3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26515: trim_joins bug with nested related models using ForeignObject

2016-04-18 Thread Django

#26515: trim_joins bug with nested related models using ForeignObject
-+-
 Reporter:  ornoone  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.9
  (models, ORM)  |   Keywords:  ForeignObject,
 Severity:  Normal   |  trim_join, orm
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+-
 the order in which we declare the `from_fields` and `to_fields` does
 matter if we make a nested lookup.

 it is clear that the fields in from_fields and to_fields must be on the
 same orders, but if 3 models use ForeignObject to links themselves, and
 the fields are the sames on all 3 models, the order in which they are
 declared in both fields must be the same.

 a example app that can trigger the bug follow :

 {{{#!python
 class Address(models.Model):
 company = models.CharField(max_length=1)
 tiers_id = models.IntegerField()
 city = models.CharField(max_length=255)
 postcode = models.CharField(max_length=32)

 class Meta(object):
 unique_together = [
 ("company", "tiers_id"),
 ]


 class Customer(models.Model):
 company = models.CharField(max_length=1)
 customer_id = models.IntegerField()
 name = models.CharField(max_length=255)
 address = ForeignObject(
 Address, on_delete=CASCADE, null=True,
 from_fields=["customer_id", "company"],
 to_fields=["tiers_id", "company"]
 )

 class Meta(object):
 unique_together = [
 ("company", "customer_id"),
 ]

 class Contact(models.Model):
 company_code = models.CharField(max_length=1)
 customer_code = models.IntegerField()
 surname = models.CharField(max_length=255)
 # virtual field
 customer = ForeignObject(
 Customer, on_delete=CASCADE, related_name='contacts',
 # not the same order as for Customer -> address which is
 (customer, company)
 to_fields=["company", "customer_id"],
 from_fields=["company_code", "customer_code"]
 # with same order as for Customer, the bug does not trigger
 # to_fields = ["customer_id", "company"],
 # from_fields = ["customer_code", "company_code"]
 )

 class PhoneNumber(models.Model):
 num = models.CharField(max_length=32)
 type_number = models.IntegerField()
 contact = models.ForeignKey(Contact, on_delete=CASCADE,
 related_name='phonenumbers')

 }}}

 with this models.py, the different orders of the fields Contact.customer
 can break all query like
 `PhoneNumber.objects.filter(contact__customer__address=a)`.(see comment in
 Customer)

 I found the problem is in django.db.models.query.Query.trim_joins line
 1444  on release 1.9.5

 {{{#!python3
 targets = tuple(r[0] for r in info.join_field.related_fields if
 r[1].column in cur_targets)
 }}}

 we see that the new targets is created using the previous used targets,
 but the order of the previous target is not kept, and the order of
 to_fields is used to define the new targets.
 this lead to a query like :

 {{{#!sql
 SELECT "buggyapp_phonenumber"."id", "buggyapp_phonenumber"."num",
 "buggyapp_phonenumber"."type_number", "buggyapp_phonenumber"."contact_id"
 FROM "buggyapp_phonenumber" INNER JOIN "buggyapp_contact" ON
 ("buggyapp_phonenumber"."contact_id" = "buggyapp_contact"."id") WHERE
 ("buggyapp_contact"."company_code" = 10 AND
 "buggyapp_contact"."customer_code" = a)
 }}}
 instead of
 {{{#!sql
 SELECT "buggyapp_phonenumber"."id", "buggyapp_phonenumber"."num",
 "buggyapp_phonenumber"."type_number", "buggyapp_phonenumber"."contact_id"
 FROM "buggyapp_phonenumber" INNER JOIN "buggyapp_contact" ON
 ("buggyapp_phonenumber"."contact_id" = "buggyapp_contact"."id") WHERE
 ("buggyapp_contact"."customer_code" = 10 AND
 "buggyapp_contact"."company_code" = a)
 }}}

 the where part have the values order kept, but the fields order is
 inconsistent and it end with customer_code = 'a' instead of 10.


 the attached files contains a basic app that trigger the bug, and a patch
 in trim_query that will build the new targets with same order as the
 previous.
 the patch is made for django 1.9.5

--
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] #21523: Models DateField to_python method no longer supports mock dates.

2016-04-18 Thread Django

#21523: Models DateField to_python method no longer supports mock dates.
-+-
 Reporter:  hugo@…   |Owner:  akki
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.6
  (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 claudep):

 @akki Could you also explore the duck-typing strategy? See
 https://gist.github.com/claudep/1ec5600d7232bb8007862014a5607c07

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

Re: [Django] #23356: Unable to create template tag which behaves similar to {% verbatim %}

2016-04-18 Thread Django

#23356: Unable to create template tag which behaves similar to {% verbatim %}
-+-
 Reporter:  jrief|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  verbatim | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jrief):

 BTW: In the meantime I found another solution for the described 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/063.9ac0406a25a03616543e414727bd5fa9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26475: Using functools.partial in model field options causes creation of unnecessary migration on every 'makemigrations' call

2016-04-18 Thread Django

#26475: Using functools.partial in model field options causes creation of
unnecessary migration on every 'makemigrations' call
+
 Reporter:  un-def  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.9
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by MarkusH):

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


Comment:

 Tim, I think we should backport this to 1.9, given the half-implemented
 partial support in #25185.

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

Re: [Django] #23356: Unable to create template tag which behaves similar to {% verbatim %}

2016-04-18 Thread Django

#23356: Unable to create template tag which behaves similar to {% verbatim %}
-+-
 Reporter:  jrief|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  verbatim | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by liminspace):

 * has_patch:  1 => 0
 * type:  Uncategorized => Cleanup/optimization


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

Re: [Django] #23356: Unable to create template tag which behaves similar to {% verbatim %}

2016-04-18 Thread Django

#23356: Unable to create template tag which behaves similar to {% verbatim %}
-+--
 Reporter:  jrief|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  verbatim | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by liminspace):

 I am creating template tag and need get code between {% mytag %}...{%
 endmytag %}.
 I read code and saw that similar template tag "verbatim" is hardcode using
 in Lexer.
 This is bad idea because nobody can't create template like "verbatim".
 Please, improve this thing and make django template system more convenient
 and flexible.

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

Re: [Django] #23356: Unable to create template tag which behaves similar to {% verbatim %}

2016-04-18 Thread Django

#23356: Unable to create template tag which behaves similar to {% verbatim %}
-+--
 Reporter:  jrief|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  verbatim | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by liminspace):

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


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

Re: [Django] #16327: "save as new" redirects to list view instead of newly-created item

2016-04-18 Thread Django

#16327: "save as new" redirects to list view instead of newly-created item
---+---
 Reporter:  candlerb   |Owner:  giuliettamasina
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords:  saveasnew  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---

Comment (by giuliettamasina):

 Hey Tim, have you had the chance to look at this one again?

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

Re: [Django] #26513: Add tests for the GeometryColumns.geom_col_name() method.

2016-04-18 Thread Django

#26513: Add tests for the GeometryColumns.geom_col_name() method.
--+
 Reporter:  timgraham |Owner:  bsebi
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by bsebi):

 * owner:  nobody => bsebi
 * 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.08636b268daa546f38f2214c43d3ba53%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26514: User.refresh_from_db() does not clear Permission cache.

2016-04-18 Thread Django

Comment (by codingjoe):

I think the `refresh_from_db` documentation is fine. It's the permissions
cache that could be better documented and maybe even extended.

It is somewhat unexpected, that you can `add` or `set`
`User.user_permissions` but that this will have no effect unless you
allocate a new instance of `User`.
Strictly speaking an m2m relationship is called a "field" in Django, or is
it not? Since the permissions are depended on such a relation, I naturally
presumed the permissions cache would be covered.

It would be a good thing to have a public API to clear the permissions
cache. As a plus it would be great if the cache handles invalidation
itself.

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

Re: [Django] #22561: EmailMessage should respect RFC2822 on max line length

2016-04-18 Thread Django

#22561: EmailMessage should respect RFC2822 on max line length
-+-
 Reporter:  notsqrt  |Owner:  levkowetz
 Type:  Bug  |   Status:  assigned
Component:  Core (Mail)  |  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
-+-

Comment (by notsqrt):

 Seems a good solution to me !

 Replying to [comment:11 claudep]:
 > I added [https://github.com/django/django/pull/6469 this PR] to fallback
 to QP encoding when the body has lines longer than 998. Would this be a
 good 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/065.b90877238c35b58b727bf71b0b7bac84%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

44 matches

Mail list logo