date:20141104

Re: [Django] #21429: BaseCommand should use logging instead of custom output wrappers

2014-11-04 Thread Django

#21429: BaseCommand should use logging instead of custom output wrappers
-+-
 Reporter:  Nical|Owner:
 Type:  New feature  |  berkerpeksag
Component:  Core (Management |   Status:  assigned
  commands)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  command output   | Triage Stage:  Accepted
  logger |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 Do we want to keep the old `stdout/stderr` way of outputting messages in
 addition to the new API? This would make `self.stdout.write/self.info` and
 `self.stderr.write/self.error` redundants. Or did you intend to deprecate
 `self.stdout/self.stderr`?

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

Re: [Django] #23750: django.core.checks.register shouldn't be (primarily) a decorator

2014-11-04 Thread Django

#23750: django.core.checks.register shouldn't be (primarily) a decorator
-+-
 Reporter:  shaib|Owner:
 Type:   |  averybigant
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  1.7
  checks)|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by averybigant):

 * has_patch:  0 => 1
 * needs_tests:  1 => 0


Comment:

 pull request: https://github.com/django/django/pull/3473

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

Re: [Django] #23761: Mysql validator crashes with None db_type return. - Backport of master fix to 1.7

2014-11-04 Thread Django

#23761: Mysql validator crashes with None db_type return. - Backport of master 
fix
to 1.7
--+
 Reporter:  adepue|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (System checks)  |  Version:  1.7
 Severity:  Release blocker   |   Resolution:
 Keywords:  mysql db_type | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_tests:  0 => 1
 * severity:  Normal => Release blocker
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 A regression test and a mention in the 1.7.2 release notes is also
 required.

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

Re: [Django] #23761: Mysql validator crashes with None db_type return. - Backport of master fix to 1.7

2014-11-04 Thread Django

#23761: Mysql validator crashes with None db_type return. - Backport of master 
fix
to 1.7
-+-
 Reporter:  adepue   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  1.7
  checks)|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  mysql db_type|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by adepue:

Old description:

> A fix was made in August in master:
> https://github.com/django/django/commit/e9103402c0fa873aea58a6a11dba510cd308cb84#diff-14
>
> The fix contains a lot more than is needed for this specific issue,
> however the specific changes to django/db/backends/mysql/validation.py
> would be great to have in Django 1.7.
>
> When implementing a custom field type with a db_type() method that
> returns None, on Django 1.6 and below we would signify not to create a
> column at all.
> With Django 1.7, this causes a crash with the mysql backend.
> The issue is already fixed in master and this simply backports the safety
> check.
>
> This worked fine in < Django 1.7 and works fine in upstream.

New description:

 When implementing a custom field type with a db_type() method that returns
 None, on Django 1.6 and below we would signify not to create a column at
 all.
 With Django 1.7, this causes a crash with the mysql backend.
 The issue is already fixed in master and this simply backports the safety
 check.

 A fix was made in August in master:
 
https://github.com/django/django/commit/e9103402c0fa873aea58a6a11dba510cd308cb84#diff-14

 The fix contains a lot more than is needed for this specific issue,
 however the specific changes to django/db/backends/mysql/validation.py
 would be great to have in Django 1.7.

 This worked fine in < Django 1.7 and works fine in upstream.

--

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

Re: [Django] #23761: Mysql validator crashes with None db_type return. - Backport of master fix to 1.7

2014-11-04 Thread Django

#23761: Mysql validator crashes with None db_type return. - Backport of master 
fix
to 1.7
-+-
 Reporter:  adepue   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  1.7
  checks)|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  mysql db_type|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by adepue:

Old description:

> A fix was made in August in master:
> https://github.com/django/django/commit/e9103402c0fa873aea58a6a11dba510cd308cb84#diff-14
>
> The fix contains a lot more than is needed for this specific issue,
> however the specific changes to django/db/backends/mysql/validation.py
> would be great to have in Django 1.7
>
> The issue is that if you create a custom field that returns None for
> db_type(), then it causes crashes due to dereference None to check the
> startswith().
>
> This worked fine in < Django 1.7 and works fine in upstream.

New description:

 A fix was made in August in master:
 
https://github.com/django/django/commit/e9103402c0fa873aea58a6a11dba510cd308cb84#diff-14

 The fix contains a lot more than is needed for this specific issue,
 however the specific changes to django/db/backends/mysql/validation.py
 would be great to have in Django 1.7.

 When implementing a custom field type with a db_type() method that returns
 None, on Django 1.6 and below we would signify not to create a column at
 all.
 With Django 1.7, this causes a crash with the mysql backend.
 The issue is already fixed in master and this simply backports the safety
 check.

 This worked fine in < Django 1.7 and works fine in upstream.

--

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

Re: [Django] #23761: Mysql validator crashes with None db_type return. - Backport of master fix to 1.7

2014-11-04 Thread Django

#23761: Mysql validator crashes with None db_type return. - Backport of master 
fix
to 1.7
-+-
 Reporter:  adepue   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  1.7
  checks)|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  mysql db_type|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by adepue):

 * component:  Uncategorized => Core (System checks)
 * easy:  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/064.32fe527b2c95d4f2aae25eb9b27e2f2e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23761: Mysql validator crashes with None db_type return. - Backport of master fix to 1.7

2014-11-04 Thread Django

#23761: Mysql validator crashes with None db_type return. - Backport of master 
fix
to 1.7
---+--
 Reporter:  adepue |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  mysql db_type  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by adepue):

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


Comment:

 Backport fix PR'd here:
 https://github.com/django/django/pull/3470

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

[Django] #23761: Mysql validator crashes with None db_type return. - Backport of master fix to 1.7

2014-11-04 Thread Django

#23761: Mysql validator crashes with None db_type return. - Backport of master 
fix
to 1.7
---+---
 Reporter:  adepue |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:  mysql db_type
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+---
 A fix was made in August in master:
 
https://github.com/django/django/commit/e9103402c0fa873aea58a6a11dba510cd308cb84#diff-14

 The fix contains a lot more than is needed for this specific issue,
 however the specific changes to django/db/backends/mysql/validation.py
 would be great to have in Django 1.7

 The issue is that if you create a custom field that returns None for
 db_type(), then it causes crashes due to dereference None to check the
 startswith().

 This worked fine in < Django 1.7 and works fine in upstream.

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

Re: [Django] #23730: Incorrect reliance on SimpleCookie roundtripping

2014-11-04 Thread Django

#23730: Incorrect reliance on SimpleCookie roundtripping
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 The Python ticket to introduce stricter parsing is
 [http://bugs.python.org/issue22796 #22796]. Django's test suite is broken
 by the patch proposed on the Python ticket but passes once again with my
 pull request.

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

Re: [Django] #23459: not faking 0001_initial migration

2014-11-04 Thread Django

Comment (by brian):

Hello,

Just noticed I hadn't replied to this for some time.

I would suggest that some sort of verbose/debugging output would be very
helpful. So you can see why Django isn't faking the migration.

e.g. "Not faking migration as expected table XYZ does not exist."

So it is possible to find out exactly what is going wrong without
resorting to hacking Django, as I previously did.

(For me it is most likely undetected errors in south migrations that only
occur under limited conditions that actually cause this)

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

Re: [Django] #21906: dumpdata should not use router.allow_syncdb

2014-11-04 Thread Django

#21906: dumpdata should not use router.allow_syncdb
-+-
 Reporter:  yscumc   |Owner:
 Type:  Bug  |  andersonresende
Component:  Core (Management |   Status:  assigned
  commands)  |  Version:  1.5
 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 andersonresende):

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


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

Re: [Django] #21429: BaseCommand should use logging instead of custom output wrappers

2014-11-04 Thread Django

#21429: BaseCommand should use logging instead of custom output wrappers
-+-
 Reporter:  Nical|Owner:
 Type:  New feature  |  berkerpeksag
Component:  Core (Management |   Status:  assigned
  commands)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  command output   | Triage Stage:  Accepted
  logger |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by berkerpeksag):

 * owner:  nobody => berkerpeksag
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

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

 This PR implements an initial integration of logging module in
 BaseCommand. I've also updated the documentation a bit. If this approach
 is okay, I'll update all management commands and 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/063.28f7d89a35797fd30e643b094fc6b50f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16501: validators.py don't like unicode slug

2014-11-04 Thread Django

#16501: validators.py don't like unicode slug
---+
 Reporter:  norn   |Owner:  pbnan
 Type:  New feature|   Status:  new
Component:  Core (Other)   |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords:  unicode, slug  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by timgraham):

 Well, I realized that 3rd approach is more or less the same as the PR
 linked in comment 16.

 I created a [https://groups.google.com/d/topic/django-
 developers/Ic2hH3AWdUg/discussion django-developers thread] to get
 feedback on the two approaches.

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

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

Re: [Django] #16501: validators.py don't like unicode slug

2014-11-04 Thread Django

#16501: validators.py don't like unicode slug
---+
 Reporter:  norn   |Owner:  pbnan
 Type:  New feature|   Status:  new
Component:  Core (Other)   |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords:  unicode, slug  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by timgraham):

 An alternate approach suggested by Claude on the mailing list was to
 "create a new `validate_uslug` validator (better name anyone?) and allow a
 custom validator to be passed to the SlugField constructor." We need
 someone to compare these three approaches (at least) and find a consensus
 on the DevelopersMailingList in order to move this issue forward.

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

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

Re: [Django] #22391: fallback to pymysql if MySQLdb not available

2014-11-04 Thread Django

#22391: fallback to pymysql if MySQLdb not available
-+-
 Reporter:  CollinAnderson   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by collinanderson):

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


Comment:

 I think I'm fine with closing for now, though I still think pymysql is
 quite popular due to it being pure python.

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

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

Re: [Django] #23746: Allow assertNumQueries to clear caches before it runs

2014-11-04 Thread Django

#23746: Allow assertNumQueries to clear caches before it runs
---+
 Reporter:  wrwrwr |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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 wrwrwr):

 * needs_better_patch:  1 => 0


Comment:

 A somewhat [https://github.com/wrwrwr/django/compare/ticket_23746?expand=1
 different solution], with the same effect:
 * added a new `pre_capture_queries` signal sent when entering the
 `CaptureQueriesContext` (also for the base manager not only
 `assertNumQueries`);
 * dropped the `clear_caches` toggle as in the new context it seemed to
 general (which caches?); if you really want to miss some queries,
 selectively disconnecting their respective receivers is a less convenient,
 but more fine-grained option.

 There are some other possibilities to consider: -- a more general non-
 testing-only `clear_caches` signal, -- some `register` function on the
 test runner, or just bringing back the toggle for convenience.

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

Re: [Django] #23756: Fall DST change breaks timezone.py make_aware

2014-11-04 Thread Django

#23756: Fall DST change breaks timezone.py make_aware
---+
 Reporter:  mdineen|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  1.7
 Severity:  Normal |   Resolution:  invalid
 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):

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


Comment:

 I see this is [https://docs.djangoproject.com/en/dev/topics/i18n/timezones
 /#interpretation-of-naive-datetime-objects documented], so I think ticket
 can be closed then.

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

Re: [Django] #23531: Add CommonMiddleware.response_redirect_class to customize the redirect class

2014-11-04 Thread Django

#23531: Add CommonMiddleware.response_redirect_class to customize the redirect
class
-+-
 Reporter:  mattrobenolt |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  common, middleware,  | Triage Stage:  Accepted
  redirect   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"df0523debcc2d0984f1bc11d323f04227d4b388b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="df0523debcc2d0984f1bc11d323f04227d4b388b"
 Fixed #23531 -- Added CommonMiddleware.response_redirect_class.
 }}}

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

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

Re: [Django] #22726: Prevent setting nullable relations on unsaved objects

2014-11-04 Thread Django

#22726: Prevent setting nullable relations on unsaved objects
-+-
 Reporter:  vzima|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

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


Comment:

 As far as I can tell, this is a duplicate of #10811 which has been fixed
 in master (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/063.426bd6ba3689d753025878c394a3d371%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23756: Fall DST change breaks timezone.py make_aware

2014-11-04 Thread Django

#23756: Fall DST change breaks timezone.py make_aware
---+
 Reporter:  mdineen|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by aaugustin):

 Yes, the implementation was specifically designed to raise an exception on
 ambiguous inputs.

 If you have a use case where it's important to enter datetimes in the
 ambiguous period, then it's up to you to implement a widget that deals
 with the ambiguity. Django doesn't ship one because there isn't a commonly
 accepted UI for dealing with this.

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

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

Re: [Django] #18088: Add a "supports_foreign_key" database feature to ease testing

2014-11-04 Thread Django

#18088: Add a "supports_foreign_key" database feature to ease testing
--+
 Reporter:  akaariai  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  1.4
 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 timgraham):

 The `supports_foreign_keys` flag was added in
 d683263f97aedd67f17f4b78ac65d915f4e70d36, but there are still bits of the
 proposed patch that could be applied.

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

Re: [Django] #22391: fallback to pymysql if MySQLdb not available

2014-11-04 Thread Django

#22391: fallback to pymysql if MySQLdb not available
-+-
 Reporter:  CollinAnderson   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by timgraham):

 Do we still need this now that we have support for mysqlclient (with no
 changes to Django)?

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

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

Re: [Django] #23757: Spatialite backend doesn't support 3d introspection

2014-11-04 Thread Django

#23757: Spatialite backend doesn't support 3d introspection
-+
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  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
-+

Comment (by timgraham):

 If that's the case, it sounds good to me. I verified the new tests pass on
 Ubuntu 14.04 and added a new build to Jenkins "django-master-trusty" to
 help us going forward. We need some workaround on 1.7 and 1.6 (like
 skipping tests) before creating similar builds for those versions, or we
 can simply skip the Spatial builds there.

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

Re: [Django] #23749: migrations.RunPython broken with dbrouters.

2014-11-04 Thread Django

#23749: migrations.RunPython broken with dbrouters.
-+-
 Reporter:  alfredperlstein  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations dbrouter  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by timgraham):

 Ah yes, that was the ticket I was looking for but couldn't find - forgot
 it had been closed. Anyway, wouldn't `schema_editor.connection.alias` give
 you the name of the database? If so, we should likely document the
 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/073.df27eb2623e9d7a4a3dcf4eede68a60d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23756: Fall DST change breaks timezone.py make_aware

2014-11-04 Thread Django

#23756: Fall DST change breaks timezone.py make_aware
---+
 Reporter:  mdineen|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by mdineen):

 Replying to [comment:2 aaugustin]:
 > This is done on purpose according to the Zen of Python: "in the face of
 ambiguity, refuse the temptation to guess."
 >
 > Celery's solution is to assume that naive datetimes are in UTC. We can't
 adopt this solution for `make_aware` because it takes a `timezone`
 argument which can have a value other than UTC.
 >
 > Always assuming the earliest date may work for your use case, but it may
 be considered a silent data corruption bug for other use cases, so it
 isn't an assumption we can enforce in the framework.

 Okay, without specifying a solution, I'd like to highlight that the line
 below causes problems every time in my code.

 https://github.com/django/django/blob/master/django/utils/timezone.py#L361

 Can be reproduced with any app using tz, admin, any date field and a date
 in the affected range.

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

Re: [Django] #23531: Add CommonMiddleware.response_redirect_class to customize the redirect class

2014-11-04 Thread Django

#23531: Add CommonMiddleware.response_redirect_class to customize the redirect
class
-+-
 Reporter:  mattrobenolt |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  common, middleware,  | Triage Stage:  Accepted
  redirect   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by berkerpeksag):

 * needs_better_patch:  1 => 0


Comment:

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

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

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

Re: [Django] #23752: Automate migrating a ForeignKey to ManyToManyField (was: Migrating ForeignKey to ManyToManyField raise ValueError("…they are not compatible types…"))

2014-11-04 Thread Django

#23752: Automate migrating a ForeignKey to ManyToManyField
-+--
 Reporter:  ad-m |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

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

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

Re: [Django] #23752: Migrating ForeignKey to ManyToManyField raise ValueError("…they are not compatible types…")

2014-11-04 Thread Django

#23752: Migrating ForeignKey to ManyToManyField raise ValueError("…they are not
compatible types…")
-+--
 Reporter:  ad-m |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timgraham):

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


Comment:

 I'm not sure your solution would generalize to all situations. I think
 automatically generating a data migration is risky as well. If you wish to
 get other opinions, please raise the issue on the DevelopersMailingList.
 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/062.49b2dbfcbcba137dfe649db24b772b53%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23742: Option to run Django tests in reverse

2014-11-04 Thread Django

#23742: Option to run Django tests in reverse
---+
 Reporter:  wrwrwr |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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:  Unreviewed => Accepted


Comment:

 This seams reasonable and helpful. It would be better if the documentation
 for the existing `runtests.py` options was submitted separately. There is
 also some missing documentation for the new argument to
 `DiscoverTestRunner`.

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

Re: [Django] #20550: Add an option to preserve the database between test runs

2014-11-04 Thread Django

#20550: Add an option to preserve the database between test runs
---+
 Reporter:  aaugustin  |Owner:  gchp
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"e645b79ef5e5238c418df8f4ab5d52eb7bbc78e7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e645b79ef5e5238c418df8f4ab5d52eb7bbc78e7"
 Added missing docs to DiscoverRunner for keepdb option; refs #20550.
 }}}

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

Re: [Django] #23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix

2014-11-04 Thread Django

Comment (by inglesp):

The behaviour changed in dcdc579d162b750ee3449e34efd772703592faca.

I suppose a fix would be to start the aliases at A and, after reaching Z,
use AA, AB, and so on. But I'm not sure that such a deeply nested query
is going to be hit in real life. richardhowardsparx, how did you hit
this?

It does feel like we're mis-using `assert` -- in a framework like Django,
I think they should be used more to guard against the possibility that the
framework has got itself into an invalid state, while in this case, it's
being used to guard against arguably-invalid user code. Would a better
error message be an acceptable resolution?

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

Re: [Django] #23691: devserver autoreload: OSError: [Errno 2] No such file or directory

2014-11-04 Thread Django

#23691: devserver autoreload: OSError: [Errno 2] No such file or directory
-+-
 Reporter:  sergei-maertens  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Management |  Version:  1.7
  commands)  |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:  development server,  |  Unreviewed
  autoreload |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

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


Comment:

 I think we'll need more details in order to reproduce and debug the issue.

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

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

Re: [Django] #23760: ModelForm wrong default value on field without fields Meta attribute neither initial data.

2014-11-04 Thread Django

#23760: ModelForm wrong default value on field without fields Meta attribute
neither initial data.
-+-
 Reporter:  aRkadeFR |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  Forms|   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  form, modelform, |  Unreviewed
  default, value |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

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


Comment:

 Model field defaults are used for `Form.initial`, not if the user doesn't
 provide a value in the data.

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

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

[Django] #23760: ModelForm wrong default value on field without fields Meta attribute neither initial data.

2014-11-04 Thread Django

#23760: ModelForm wrong default value on field without fields Meta attribute
neither initial data.
-+-
 Reporter:  aRkadeFR |  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |Version:  1.6
Component:  Forms|   Keywords:  form, modelform,
 Severity:  Normal   |  default, value
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 I haven't found any similar ticket.

 Create a Model with a BooleanField, null=False, default=True, blank=True.

 Create the ModelForm with the Meta attribute model = ModelClass

 Then if you want to create a ModelClass through the ModelForm(data={ 
 without the BooleanField } ) , this will setup the booleanfield to False .

 This is pretty unconvenient when upgrading a model without touching the
 forms.

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

Re: [Django] #23757: Spatialite backend doesn't support 3d introspection

2014-11-04 Thread Django

#23757: Spatialite backend doesn't support 3d introspection
-+
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  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
-+

Comment (by claudep):

 I *think* the remaining failures (unreproduceable on my system, even with
 Spatialite 3.0) are related to GEOS (see
 http://trac.osgeo.org/geos/ticket/292 which is fixed in GEOS 3.3). That is
 the GEOS version Spatialite is compiled with. In that case, we could
 simply skip those tests when GEOS < 3.3.

 Extract of a traceback of one of those errors happening on the CI server
 (django.contrib.gis.tests.geo3d.tests.Geo3DTest.test_3d_hasz):
 {{{
 Traceback (most recent call last):
   File ".../python2.7/django/contrib/gis/tests/geo3d/tests.py", line 116,
 in test_3d_hasz
 self._load_interstate_data()
   File ".../python2.7/django/contrib/gis/tests/geo3d/tests.py", line 95,
 in _load_interstate_data
 Interstate3D.objects.create(name=name, line=line_3d)
 ...
 File ".../python2.7/django/db/backends/sqlite3/base.py", line 507, in
 execute
 return Database.Cursor.execute(self, query, params)
 IntegrityError: geo3d_interstate3d.line violates Geometry constraint
 [geom-type or SRID not allowed]
 }}}

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

Re: [Django] #23641: Apps.set_installed_apps causes signals registered with apps as senders not to be received

2014-11-04 Thread Django

#23641: Apps.set_installed_apps causes signals registered with apps as senders 
not
to be received
--+
 Reporter:  wrwrwr|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  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


Comment:

 Even if the root cause of the failures is not directly related to this, we
 cannot commit this until those failures are worked around in this patch or
 until the related ticket is resolved. Currently our build doesn't have
 these failures on a regular basis.

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

Re: [Django] #13181: ChoiceField.choices need to accept callable, not only list or tuple

2014-11-04 Thread Django

#13181: ChoiceField.choices need to accept callable, not only list or tuple
--+
 Reporter:  mariarchi |Owner:  inglesp
 Type:  New feature   |   Status:  closed
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  ChoiceField, choices  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"74e1980cf96eb45079bef464fabdcbe0a6db2423"]:
 {{{
 #!CommitTicketReference repository=""
 revision="74e1980cf96eb45079bef464fabdcbe0a6db2423"
 Fixed #13181 -- Added support for callable choices to forms.ChoiceField

 Thanks vanschelven and expleo for the initial 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/067.bbb6c7b025f4485de30b987e91b45a22%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23759: Storage.get_available_name should preserve all file extensions, not just the first one

2014-11-04 Thread Django

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

Comment:

In general, I think a period is a valid character in a filename, so we
cannot simply assume everything to the right of the first period is the
file extension. Some different strategies for the issue are detailed on
[http://stackoverflow.com/questions/6525334/getting-file-extension-using-
pattern-matching-in-python stackoverflow]. I am not sure its up to Django
to pick one, but we could at least document the caveat and link how to
write your own storage subclass so someone can implement the behavior they
desire. Thoughts?

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

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

Re: [Django] #23750: django.core.checks.register shouldn't be (primarily) a decorator

2014-11-04 Thread Django

#23750: django.core.checks.register shouldn't be (primarily) a decorator
-+-
 Reporter:  shaib|Owner:
 Type:   |  averybigant
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  1.7
  checks)|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by averybigant):

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

Re: [Django] #23754: DisallowedModelAdminToField when using get_inline_instances()

2014-11-04 Thread Django

#23754: DisallowedModelAdminToField when using get_inline_instances()
---+-
 Reporter:  timgraham  |Owner:  charettes
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.4
 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 charettes):

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


Comment:

 Good idea, let's document this as a requirement for older versions of
 Django. I should be able to come up with a draft in the next few days.

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

[Django] #23759: Storage.get_available_name should preserve all file extensions, not just the first one

2014-11-04 Thread Django

#23759: Storage.get_available_name should preserve all file extensions, not just
the first one
--+
 Reporter:  thenewguy |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  File uploads/storage  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 `get_available_name` only preserves the first file extension.  If the file
 is `foo.tar.gz` then `get_available_name` will return `foo.tar_RANDOM.gz`
 instead of `foo_RANDOM.tar.gz`

 https://github.com/django/django/blob/master/django/core/files/storage.py#L71


 {{{
 def get_available_name(self, name):
 """
 Returns a filename that's free on the target storage system, and
 available for new content to be written to.
 """
 dir_name, file_name = os.path.split(name)
 file_root, file_ext = os.path.splitext(file_name)
 # If the filename already exists, add an underscore and a random 7
 # character alphanumeric string (before the file extension, if one
 # exists) to the filename until the generated filename doesn't
 exist.
 while self.exists(name):
 # file_ext includes the dot.
 name = os.path.join(dir_name, "%s_%s%s" % (file_root,
 get_random_string(7), file_ext))

 return name
 }}}

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

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

Re: [Django] #23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix

2014-11-04 Thread Django

#23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix
-+-
 Reporter:  richardhowardsparx   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  bump_prefix  |  Unreviewed
  subquery alias |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by prathik):

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


Comment:

 While debugging I saw that the list self.subq_aliases grows from U to Z in
 bump_prefix and upon reaching Z the AssertionError is thrown, not sure if
 it is done on purpose to prevent infinite loops from happening or a side-
 effect of something else.

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

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

Re: [Django] #23741: [System Check for migrations] Check presence of all foreign keys

2014-11-04 Thread Django

#23741: [System Check for migrations] Check presence of all foreign keys
--+
 Reporter:  notsqrt   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"d373e223bdb0722b1d7ff9c470f3bf562815507c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d373e223bdb0722b1d7ff9c470f3bf562815507c"
 [1.7.x] Added a warning about nonexistent FK constraints when unmigrated
 apps depend on migrated ones.

 Thanks NotSqrt for the report; refs #23741.

 Backport of f0ff452451 from master
 }}}

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

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

Re: [Django] #23741: [System Check for migrations] Check presence of all foreign keys

2014-11-04 Thread Django

#23741: [System Check for migrations] Check presence of all foreign keys
--+
 Reporter:  notsqrt   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"f0ff452451c0a2db6db53b6f068c794a47450d78"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f0ff452451c0a2db6db53b6f068c794a47450d78"
 Added a warning about nonexistent FK constraints when unmigrated apps
 depend on migrated ones.

 Thanks NotSqrt for the report; refs #23741.
 }}}

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

[Django] #23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix

2014-11-04 Thread Django

#23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix
-+-
 Reporter:  richardhowardsparx   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.7
  (models, ORM)  |   Keywords:  bump_prefix subquery
 Severity:  Normal   |  alias
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Regression from Django 1.6

 The following code in the interactive shell will reproduce the issue:

 {{{#!python
 from django.contrib.auth.models import User
 i = 0
 x = User.objects.filter(pk=1)
 while True:
 x = User.objects.filter(pk__in=x)
 i+=1
 }}}
 In django 1.7 it will throw the following AssertionError

 {{{#!python
 ...
 ... in bump_prefix(self, outer_query)
 829 while self.alias_prefix in self.subq_aliases:
 830 self.alias_prefix = chr(ord(self.alias_prefix) + 1)
 --> 831 assert self.alias_prefix < 'Z'
 832 self.subq_aliases =
 self.subq_aliases.union([self.alias_prefix])
 833 outer_query.subq_aliases =
 outer_query.subq_aliases.union(self.subq_aliases)

 AssertionError:
 }}}

 while in django 1.6 it will loop infinitely.

 I have tested this using multiple models in the loop, with the same
 outcome.

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

Re: [Django] #13181: ChoiceField.choices need to accept callable, not only list or tuple

2014-11-04 Thread Django

#13181: ChoiceField.choices need to accept callable, not only list or tuple
--+
 Reporter:  mariarchi |Owner:  inglesp
 Type:  New feature   |   Status:  assigned
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  ChoiceField, choices  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by inglesp):

 * needs_better_patch:  1 => 0


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

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

46 matches

Mail list logo