date:20150919

Re: [Django] #25431: ModelFormset regression in object clean() accessing a FK

2015-09-19 Thread Django

#25431: ModelFormset regression in object clean() accessing a FK
-+
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #25296: Failed Manager.create() could pollute related models cache

2015-09-19 Thread Django

#25296: Failed Manager.create() could pollute related models cache
-+-
 Reporter:  rubendura|Owner:
 |  raphaelmerx
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f5a33e4840d3ad4d1199e99f5a17a9af1d2176f9" f5a33e48]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5a33e4840d3ad4d1199e99f5a17a9af1d2176f9"
 Fixed #25296 -- Prevented model related object cache pollution when
 create() fails due to an unsaved object.
 }}}

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

Re: [Django] #25135: Deprecate admin list_display allow_tags

2015-09-19 Thread Django

#25135: Deprecate admin list_display allow_tags
-+-
 Reporter:  jaap3|Owner:
 Type:   |  olasitarska
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"00adec6d5f266469bc62e7351d8e6b641872b47a" 00adec6]:
 {{{
 #!CommitTicketReference repository=""
 revision="00adec6d5f266469bc62e7351d8e6b641872b47a"
 Refs #25135 -- Corrected the timeline section of allow_tags deprecation.
 }}}

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

Re: [Django] #23813: Add checks for common URLpattern errors

2015-09-19 Thread Django

#23813: Add checks for common URLpattern errors
--+
 Reporter:  jwa   |Owner:  jwa
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 Sorry about those old test failures, that was a transient issue while I
 was making some updates to Jenkins.

 As noted on the pull request, the current warnings don't show which url
 triggered the warning. I don't think it's acceptable to make the user hunt
 their entire project to track down the cause of the warning. :-)

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

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

Re: [Django] #25432: Django ORM race condition

2015-09-19 Thread Django

#25432: Django ORM race condition
-+-
 Reporter:  yuvadm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yuvadm):

 Replying to [comment:8 shaib]:

 > Can you elaborate on that a  little? In  particular, is the test case
 using Django's test-client for these calls? If it is, there's one thread
 on the server doing everything, and it all happens in the same
 transaction; I'd ask you to check again about caching and replication and
 that sort of thing.

 This isn't Django test client, I'm calling from any external process
 (specifically I'm testing with curl from command line).

 > If it isn't the test-client (or even the Django test framework), I'd ask
 you to verify again that the second request is only sent after full
 processing of the first request has completed.

 Yep, I'm using {{{curl http://example.com/foo && curl
 http://example.com/foo}}}

 > Either way, please also verify that your PostgreSQL configuration is
 sane. I've seen recommendations to make testing faster by turning off its
 fsync etc, and that could be the cause of such behavior.

 This is happening on Heroku Postgres. Any recommendations on how to tinker
 with the config there? Is it known to be problematic?

 > On a side note: I'm pretty sure get_or_create ''only'' works reliably
 under serializable transactions; under the default (read-committed)
 isolation level there are failure scenarios, whether you try to get first
 or create first.

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

Re: [Django] #15760: Feature: JS Hooks for Dynamic Inlines

2015-09-19 Thread Django

#15760: Feature: JS Hooks for Dynamic Inlines
-+-
 Reporter:  mlavin   |Owner:
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  inlines jquery   | Triage Stage:  Accepted
  callback   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Reviewed the updated patch.

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

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

Re: [Django] #25373: Add logging for {% include %} exceptions when template.debug = False

2015-09-19 Thread Django

#25373: Add logging for {% include %} exceptions when template.debug = False
-+
 Reporter:  limnick  |Owner:  limnick
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

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

Re: [Django] #25432: Django ORM race condition

2015-09-19 Thread Django

Comment (by shaib):

> I have seen this happen in a test case where I make two subsequent API
calls that do exactly this and got a ~5% failure rate.

Can you elaborate on that a little? In particular, is the test case
using Django's test-client for these calls? If it is, there's one thread
on the server doing everything, and it all happens in the same
transaction; I'd ask you to check again about caching and replication and
that sort of thing.

If it isn't the test-client (or even the Django test framework), I'd ask
you to verify again that the second request is only sent after full
processing of the first request has completed.

Either way, please also verify that your PostgreSQL configuration is sane.
I've seen recommendations to make testing faster by turning off its fsync
etc, and that could be the cause of such behavior.

On a side note: I'm pretty sure get_or_create ''only'' works reliably
under serializable transactions; under the default (read-committed)
isolation level there are failure scenarios, whether you try to get first
or create first.

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

Re: [Django] #25430: RunSQL documentation is incorrect

2015-09-19 Thread Django

#25430: RunSQL documentation is incorrect
---+--
 Reporter:  fcurella   |Owner:  fcurella
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham ):

 In [changeset:"63147dfa07cfed6c2aa2ad28b4a5664747650352" 63147dfa]:
 {{{
 #!CommitTicketReference repository=""
 revision="63147dfa07cfed6c2aa2ad28b4a5664747650352"
 [1.8.x] Fixed #25430 -- Fixed incorrect RunSQL examples.

 Backport of 95edabb45e016ed269f96acc03d4a2bfcecd6b71 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/066.cc6b46ba01b24f9f7a1ee73620b47c72%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25430: RunSQL documentation is incorrect

2015-09-19 Thread Django

#25430: RunSQL documentation is incorrect
---+--
 Reporter:  fcurella   |Owner:  fcurella
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"95edabb45e016ed269f96acc03d4a2bfcecd6b71" 95edabb4]:
 {{{
 #!CommitTicketReference repository=""
 revision="95edabb45e016ed269f96acc03d4a2bfcecd6b71"
 Fixed #25430 -- Fixed incorrect RunSQL examples.
 }}}

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

Re: [Django] #25432: Django ORM race condition

2015-09-19 Thread Django

Comment (by aaugustin):

Actually making both requests from the same thread doesn't matter because
they may be handled by different processes on the server.

Even at the SERIALIZABLE isolation level, the database is allowed to
serialize transactions made on different connections in any consistent
order.

I think this is part of the consistency model of multi-processes databases
servers, which are distributed systems even if they run on one server

I don't think there's anything specific to Django here. You should be able
to reproduce this behavior with plain WSGI & pyscopg2.

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

Re: [Django] #25432: Django ORM race condition

2015-09-19 Thread Django

#25432: Django ORM race condition
-+-
 Reporter:  yuvadm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 The SERIALIZABLE isolation level is the answer to question 1. at the
 bottom of your bug report, though.

 Regarding question 2. we don't want to document it because too many people
 will think it's a good idea without understanding the consequences and
 because it breaks some APIs e.g. get_or_create doesn't work anymore (I
 think).

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

Re: [Django] #25432: Django ORM race condition

2015-09-19 Thread Django

#25432: Django ORM race condition
-+-
 Reporter:  yuvadm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yuvadm):

 Replying to [comment:4 aaugustin]:
 > Just to be clear, the scenario is the following:
 >

 Yes, exactly.

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

Re: [Django] #25432: Django ORM race condition

2015-09-19 Thread Django

#25432: Django ORM race condition
-+-
 Reporter:  yuvadm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Just to be clear, the scenario is the following:

 - you make the first API request
 - the server processes this request, performs some database operations,
 commits the database transaction, sends back the response
 - you receive and process the response to the first request
 - you make the second API request from the same thread that made the first
 request
 - the server cannot see the data written by the first request

 You question almost looks like the answer should involve isolation levels,
 specifically the SERIALIZABLE level, but if my description above is
 correct that cannot explain the behavior you're describing.

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

Re: [Django] #25432: Django ORM race condition

2015-09-19 Thread Django

#25432: Django ORM race condition
-+-
 Reporter:  yuvadm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yuvadm):

 Replying to [comment:2 aaugustin]:
 > Is it possible that you're writing to the primary and reading from a
 replica? In that case all you're seeing is the replication delay. That
 would explain why you can't reproduce locally.

 Nope, there's only a single Postgres database at play.

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

Re: [Django] #25432: Django ORM race condition

2015-09-19 Thread Django

#25432: Django ORM race condition
-+-
 Reporter:  yuvadm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Is it possible that you're writing to the primary and reading from a
 replica? In that case all you're seeing is the replication delay. That
 would explain why you can't reproduce locally.

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

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

Re: [Django] #22341: Split django.db.models.fields.related into multiple modules.

2015-09-19 Thread Django

#22341: Split django.db.models.fields.related into multiple modules.
-+-
 Reporter:  loic84   |Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 See https://github.com/django/django/pull/5318.

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

Re: [Django] #25432: Django ORM race condition

2015-09-19 Thread Django

#25432: Django ORM race condition
-+-
 Reporter:  yuvadm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yuvadm):

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


Comment:

 This has also been referenced in
 https://code.djangoproject.com/ticket/20429#comment:22

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

[Django] #25432: Django ORM race condition

2015-09-19 Thread Django

#25432: Django ORM race condition
--+
 Reporter:  yuvadm|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I've hit an interesting problem that isn't covered by the current Django
 documentation, and might even be a bug that Django can handle better. It
 started off as a SO question at http://stackoverflow.com/q/32661885/24545
 but here's the gist of it.

 After creating a new object {{{MyModel.objects.create(foo=goo)}}} and
 inserting it into the database, it is possible that immediate subsequent
 calls to fetch that object might fail (i.e.
 {{{MyModel.objects.get(foo=goo)}}} will throw {{{DoesNotExist}}}). I have
 seen this happen in a test case where I make two subsequent API calls that
 do exactly this and got a ~5% failure rate.

 In most cases this might not be a problem, but I am using this query to
 make sure I'm not creating two duplicate objects. This is essentially an
 UPSERT problem. In my case, my solution was to set {{{unique=True}}} on my
 {{{foo}}} field and attempt to create the object in any case, which will
 naturally fail on a duplicate, then I just catch the {{{IntegrityError}}}
 and fail gracefully. In this we we use DB semantics which guarantees no
 duplicates.

 The relevant settings for this test case are: PostgreSQL, default Django
 transaction settings and no specific caching.

 So 2 questions here:

 1. What happens if my application '''requires''' that any two transactions
 {{{a}}} and {{{b}}} behave such that {{{b}}} always sees fresh data that
 was written in {{{a}}}? How can I enforce this in Django?
 2. How do we document this behavior in a better way? If this is possible
 or impossible, Django must be clearer on how such transactions are
 handled.

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

Re: [Django] #25160: Move unsaved model instance assignment check to model.save()

2015-09-19 Thread Django

#25160: Move unsaved model instance assignment check to model.save()
-+-
 Reporter:  timgraham|Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"c3904deb919823af577adf5d9d35e9c113eb8289" c3904deb]:
 {{{
 #!CommitTicketReference repository=""
 revision="c3904deb919823af577adf5d9d35e9c113eb8289"
 Fixed #25160 (again) -- Moved data loss check on reverse relations.

 Moved data loss check when assigning to a reverse one-to-one relation on
 an unsaved instance to Model.save(). This is exactly the same change as
 e4b813c but for reverse relations.
 }}}

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

Re: [Django] #25160: Move unsaved model instance assignment check to model.save()

2015-09-19 Thread Django

#25160: Move unsaved model instance assignment check to model.save()
-+-
 Reporter:  timgraham|Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"1abd177696ef72843557980fbdd352176ed2800e" 1abd177]:
 {{{
 #!CommitTicketReference repository=""
 revision="1abd177696ef72843557980fbdd352176ed2800e"
 [1.8.x] Fixed #25160 (again) -- Moved data loss check on reverse
 relations.

 Moved data loss check when assigning to a reverse one-to-one relation on
 an unsaved instance to Model.save(). This is exactly the same change as
 e4b813c but for reverse relations.

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

Re: [Django] #22341: Split django.db.models.fields.related into multiple modules.

2015-09-19 Thread Django

Comment (by aaugustin):

The discussions on the previous attempt show that grouping code by the
type of relation (one-to-one, one-to-many, many-to-many) doesn't work very
well. It raises hard questions about where code would end up after
plausible refactorings.

I'd like to suggest a different approach: group code by the type of
objects defined:

- descriptors
- managers
- "rel objects" (these don't have a good name)
- etc.

This is straightforward, reasonably future proof — if we introduce a new
kind of object it's easy to add a module.

It groups similar code nicely and allows for module docstrings explaining
the role of each layer.

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

Re: [Django] #25418: URL Validator to check only hostname part without domain nor tld

2015-09-19 Thread Django

#25418: URL Validator to check only hostname part without domain nor tld
--+
 Reporter:  foxmask   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by foxmask):

 I'm sorry to speak about the topic, as I didn't know all about this
 history, if it's boring ; close that ticket.
 Regards

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

Re: [Django] #12118: in-memory test database does not work with threads

2015-09-19 Thread Django

#12118: in-memory test database does not work with threads
-+-
 Reporter:  bluebird75   |Owner:  coldmind
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  threads  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by hjwp):

 Incidentally, in case it's of use to anyone else that's temporarily stuck
 on an earlier versions of django, you can hack a workaround for this by
 using a path in `/dev/shm` in `TEST_NAME`:


 {{{
 DATABASES['default']['TEST_NAME'] = '/dev/shm/myproject-
 djangotestdb.sqlite'
 }}}

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

Re: [Django] #22341: Split django.db.models.fields.related into multiple modules.

2015-09-19 Thread Django

#22341: Split django.db.models.fields.related into multiple modules.
-+-
 Reporter:  loic84   |Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


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

Re: [Django] #13110: Allow multiple enclosures in Atom feeds

2015-09-19 Thread Django

#13110: Allow multiple enclosures in Atom feeds
-+-
 Reporter:  Piaume   |Owner:
 |  unaizalakain
 Type:  New feature  |   Status:  closed
Component:  contrib.syndication  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  multiple,| Triage Stage:  Accepted
  enclosures, atom, feed 1.9 |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

Re: [Django] #13110: Allow multiple enclosures in Atom feeds

2015-09-19 Thread Django

#13110: Allow multiple enclosures in Atom feeds
-+-
 Reporter:  Piaume   |Owner:
 |  unaizalakain
 Type:  New feature  |   Status:  new
Component:  contrib.syndication  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  multiple,| Triage Stage:  Accepted
  enclosures, atom, feed 1.9 |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Unai Zalakain ):

 In [changeset:"a4b80e242162a7d6ac2337a2a621a82027c549b7" a4b80e24]:
 {{{
 #!CommitTicketReference repository=""
 revision="a4b80e242162a7d6ac2337a2a621a82027c549b7"
 Refs #13110 -- Fixed mistakes in the new multiple enclosure feed 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/064.a954e9f8a18904841a436f8992316a58%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25160: Move unsaved model instance assignment check to model.save()

2015-09-19 Thread Django

#25160: Move unsaved model instance assignment check to model.save()
-+-
 Reporter:  timgraham|Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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

Re: [Django] #23813: Add checks for common URLpattern errors

2015-09-19 Thread Django

#23813: Add checks for common URLpattern errors
-+-
 Reporter:  jwa  |Owner:  jwa
 Type:  New feature  |   Status:  new
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

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

Re: [Django] #25160: Move unsaved model instance assignment check to model.save()

2015-09-19 Thread Django

#25160: Move unsaved model instance assignment check to model.save()
-+-
 Reporter:  timgraham|Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * has_patch:  0 => 1


Comment:

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

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

Re: [Django] #24793: Subtracting DateTime fields in a query expression should use timediff

2015-09-19 Thread Django

#24793: Subtracting DateTime fields in a query expression should use timediff
-+-
 Reporter:  sparkyb  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  datetime duration| Triage Stage:  Accepted
  expression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by LegoStormtroopr):

 @jarshwah

 I've got a work around that I think works for SQLite using SQLites native
 `julianday` function, and am keen to progress this as an actual solution,
 but the code is a little dense for me.

 Would you be able to point me in the direction of where the subtract
 expressions are handled?

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

Re: [Django] #25418: URL Validator to check only hostname part without domain nor tld

2015-09-19 Thread Django

#25418: URL Validator to check only hostname part without domain nor tld
--+
 Reporter:  foxmask   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  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 claudep):

 * type:  Bug => New feature


Comment:

 In 4e2e8f39d19d79a59c2696b2c40cb619a54fa745, we added some flexibility to
 add whitelisted hostnames for `EmailValidator`. It might make sense to add
 the same for `URLValidator`, but it would probably require to (again!)
 restructure that validator.

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

Re: [Django] #25424: "AttributeError: 'proxy' object has no attribute 'decode'" using reverse_lazy in test client

2015-09-19 Thread Django

#25424: "AttributeError: '__proxy__' object has no attribute 'decode'" using
reverse_lazy in test client
-+-
 Reporter:  SoftwareMaven|Owner:
 |  SoftwareMaven
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"1a09b3c398b42800de864023dad872d83b196181" 1a09b3c]:
 {{{
 #!CommitTicketReference repository=""
 revision="1a09b3c398b42800de864023dad872d83b196181"
 Fixed #25424 -- Use force_str for test client URLs.

 urlparse() fails with an AttributeError ("'__proxy__' object has no
 attribute 'decode'") if reverse_lazy is used to look up the URL
 (this is exactly the same problem that caused ticket #18776). The
 solution is to use force_str() on the path before handing it to
 urlparse().
 }}}

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

Re: [Django] #25423: Using custom tag without {% load %} result in confusing traceback

2015-09-19 Thread Django

#25423: Using custom tag without {% load %} result in confusing traceback
--+
 Reporter:  yegle |Owner:  chiller
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Template system   |  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 chiller):

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

Re: [Django] #25431: ModelFormset regression in object clean() accessing a FK

2015-09-19 Thread Django

#25431: ModelFormset regression in object clean() accessing a FK
-+--
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

 If the patch gets approved, I'd like to tentatively backport this to 1.8.

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

Re: [Django] #25423: Using custom tag without {% load %} result in confusing traceback

2015-09-19 Thread Django

#25423: Using custom tag without {% load %} result in confusing traceback
--+
 Reporter:  yegle |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  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 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/063.29d623cc85e42dfbff800adaea083ed5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25431: ModelFormset regression in object clean() accessing a FK

2015-09-19 Thread Django

#25431: ModelFormset regression in object clean() accessing a FK
-+--
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by claudep):

 Just apply that patch to reproduce the problem in Django's test suite:
 {{{
 #!diff
 diff --git a/tests/model_formsets/models.py
 b/tests/model_formsets/models.py
 index df6a687..7b7337f 100644
 --- a/tests/model_formsets/models.py
 +++ b/tests/model_formsets/models.py
 @@ -37,6 +37,10 @@ class Book(models.Model):
  def __str__(self):
  return self.title

 +def clean(self):
 +# Ensure author is always accessible in clean method
 +assert self.author.name is not None
 +

  @python_2_unicode_compatible
  class BookWithCustomPK(models.Model):
 }}}

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

[Django] #25431: ModelFormset regression in object clean() accessing a FK

2015-09-19 Thread Django

#25431: ModelFormset regression in object clean() accessing a FK
---+
   Reporter:  claudep  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Forms|Version:  1.8
   Severity:  Release blocker  |   Keywords:  regression
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 When a ModelForm with an inline formset is validated (at least when all
 objects are new), the inline instances are constructed without the link to
 their parent model, because the fk field is excluded from the instance
 construction (see BaseModelForm._post_clean).

 Like #25349, this regression is probably caused by
 45e049937d2564d11035827ca9a9221b86215e45/#13776.

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

Re: [Django] #25160: Move unsaved model instance assignment check to model.save()

2015-09-19 Thread Django

#25160: Move unsaved model instance assignment check to model.save()
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 For consistency, I think we should make the same change on reverse
 relations.

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

Re: [Django] #25160: Move unsaved model instance assignment check to model.save()

2015-09-19 Thread Django

#25160: Move unsaved model instance assignment check to model.save()
-+-
 Reporter:  timgraham|Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (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 aaugustin):

 * owner:  timgraham => aaugustin
 * status:  new => assigned
 * has_patch:  1 => 0
 * 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/067.fcbb1a2479bf3195a311cba329dce066%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #13110: Allow multiple enclosures in Atom feeds

2015-09-19 Thread Django

#13110: Allow multiple enclosures in Atom feeds
-+-
 Reporter:  Piaume   |Owner:
 |  unaizalakain
 Type:  New feature  |   Status:  new
Component:  contrib.syndication  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  multiple,| Triage Stage:  Accepted
  enclosures, atom, feed 1.9 |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by unaizalakain):

 * has_patch:  0 => 1


Comment:

 Sorry about that…
 New PR: https://github.com/django/django/pull/5315

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

41 matches

Mail list logo