date:20160425

Re: [Django] #26033: Add argon2 password hasher

2016-04-25 Thread Django

#26033: Add argon2 password hasher
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  1.10 | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #26033: Add argon2 password hasher

2016-04-25 Thread Django

#26033: Add argon2 password hasher
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.10 | 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:"a5033dbc58d6e09d28b8abe3acda20b9c60e0b8e" a5033db]:
 {{{
 #!CommitTicketReference repository=""
 revision="a5033dbc58d6e09d28b8abe3acda20b9c60e0b8e"
 Refs #26033 -- Added password hasher support for Argon2 v1.3.

 The previous version of Argon2 uses encoded hashes of the form:
$argon2d$m=8,t=1,p=1$$

 The new version of Argon2 adds its version into the hash:
$argon2d$v=19$m=8,t=1,p=1$$

 This lets Django handle both version properly.
 }}}

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

Re: [Django] #26033: Add argon2 password hasher

2016-04-25 Thread Django

#26033: Add argon2 password hasher
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.10 | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 [https://github.com/django/django/pull/6489 PR] for Argon2 1.3 support.

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

Re: [Django] #26527: HashedFilesMixin StaticFileStorage can't handle nested assets

2016-04-25 Thread Django

#26527: HashedFilesMixin StaticFileStorage can't handle nested assets
-+-
 Reporter:  joshblum |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by dsanders11):

 I've opened a [https://github.com/django/django/pull/6507 WIP PR] for this
 issue. This is a working fix that I've been using in production for 6
 months and it works great. If you need an immediate fix joshblum, try that
 out, the entire `storage.py` file can be backported by itself (confirmed
 this works with 1.8.12, should work with 1.9 as well).

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

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

Re: [Django] #24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash when referenced media changes

2016-04-25 Thread Django

#24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash
when referenced media changes
-+-
 Reporter:  pmclanahan   |Owner:
 |  pmclanahan
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  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 dsanders11):

 I've opened a [https://github.com/django/django/pull/6507 WIP PR] for this
 issue. The tests I've attached are from that PR, and with the exception of
 `test_import_loop` are general test coverage of the issue (fail on
 master).

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

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

Re: [Django] #24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash when referenced media changes

2016-04-25 Thread Django

#24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash
when referenced media changes
-+-
 Reporter:  pmclanahan   |Owner:
 |  pmclanahan
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  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
-+-
Changes (by dsanders11):

 * Attachment "staticfiles-adjustable-paths-tests.patch" added.

 Tests for accurate hash filenames

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

Re: [Django] #26207: Replace dynamic classes with non-data descriptors for deferred instance loading

2016-04-25 Thread Django

#26207: Replace dynamic classes with non-data descriptors for deferred instance
loading
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  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:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


Comment:

 [https://github.com/django/django/pull/6491 Updated PR] with cosmetic
 edits + docs. One TODO remains from Anssi's original PR that I'm not sure
 how to handle.

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

Re: [Django] #19515: Increase the max_length of Redirect.old_path/new_path

2016-04-25 Thread Django

#19515: Increase the max_length of Redirect.old_path/new_path
-+-
 Reporter:  s.shanabrook@…   |Owner:
 Type:   |  saulshanabrook
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.redirects|  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):

 I'd think so (hence why I moved the ticket to 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/080.f9ecd12b95fbf5c8ddd47a5e57991a30%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19515: Increase the max_length of Redirect.old_path/new_path

2016-04-25 Thread Django

#19515: Increase the max_length of Redirect.old_path/new_path
-+-
 Reporter:  s.shanabrook@…   |Owner:
 Type:   |  saulshanabrook
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.redirects|  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 gavinwahl):

 * cc: gavinwahl+gh@… (added)


Comment:

 Django now has built-in migrations. Is this feasible now?

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

Re: [Django] #26542: Extension names are not properly quoted in the PostgreSQL CreateExtension operation

2016-04-25 Thread Django

#26542: Extension names are not properly quoted in the PostgreSQL 
CreateExtension
operation
--+
 Reporter:  conradev  |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by charettes):

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

Re: [Django] #26542: Extension names are not properly quoted in the PostgreSQL CreateExtension operation

2016-04-25 Thread Django

#26542: Extension names are not properly quoted in the PostgreSQL 
CreateExtension
operation
--+--
 Reporter:  conradev  |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by conradev):

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

Re: [Django] #26542: Extension names are not properly quoted in the PostgreSQL CreateExtension operation

2016-04-25 Thread Django

#26542: Extension names are not properly quoted in the PostgreSQL 
CreateExtension
operation
--+
 Reporter:  conradev  |  Owner:
 Type:  Bug   | Status:  new
Component:  contrib.postgres  |Version:  1.9
 Severity:  Normal| Resolution:
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by conradev):

 * Attachment "26542.diff" added.


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

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

[Django] #26542: Extension names are not properly quoted in the PostgreSQL CreateExtension operation

2016-04-25 Thread Django

#26542: Extension names are not properly quoted in the PostgreSQL 
CreateExtension
operation
--+-
 Reporter:  conradev  |  Owner:
 Type:  Bug   | Status:  new
Component:  contrib.postgres  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+-
 Running `CreateExtension('uuid-ossp')` in the current version of Django
 fails with a Postgres syntax error.

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

Re: [Django] #25197: Add a more friendly widget for HStoreField

2016-04-25 Thread Django

#25197: Add a more friendly widget for HStoreField
--+
 Reporter:  gam_phon  |Owner:  funkybob
 Type:  New feature   |   Status:  assigned
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  widget| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  1
--+

Comment (by timgraham):

 As I recall, FunkyBob got discouraged at the lack of feedback on the
 [https://groups.google.com/d/topic/django-
 developers/g71ZgYiHDmo/discussion django-developers thread].

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

Re: [Django] #25197: Add a more friendly widget for HStoreField

2016-04-25 Thread Django

#25197: Add a more friendly widget for HStoreField
--+
 Reporter:  gam_phon  |Owner:  funkybob
 Type:  New feature   |   Status:  assigned
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  widget| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  1
--+

Comment (by krische):

 So is this feature would be really nice. But judging by the lack of
 activity, should I assume it's dead?

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

Re: [Django] #26333: GIS geometries classes should be deconstructibles.

2016-04-25 Thread Django

#26333: GIS geometries classes should be deconstructibles.
-+-
 Reporter:  simondrabble |Owner:  niconoe
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  makemigration gis| Triage Stage:  Accepted
  point pointfield   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by niconoe):

 Indeed, I was using `CreateModel` in my test app. Thanks for your comment,
 will do my best to solve 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/070.926b71162767eafee2b249aa7b507686%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22936: Get rid of field.get_db_prep_lookup()

2016-04-25 Thread Django

#22936: Get rid of field.get_db_prep_lookup()
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"1ba0b22a7a262e63cb7152ef3ab513660156d135" 1ba0b22]:
 {{{
 #!CommitTicketReference repository=""
 revision="1ba0b22a7a262e63cb7152ef3ab513660156d135"
 Refs #22936 -- Removed unused code in Field.get_db_prep_lookup().
 }}}

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

Re: [Django] #25253: MySQL migrations drop & recreate constraints unnecessarily when changing attributes that don't affect the schema

2016-04-25 Thread Django

#25253: MySQL migrations drop & recreate constraints unnecessarily when changing
attributes that don't affect the schema
--+
 Reporter:  trecouvr  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:  migrations m2m mysql  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by piquadrat):

 For what it's worth, I'm also seeing this on PostgreSQL 9.1, Django 1.9.5
 and psycopg2 2.6.1. Specifically, adding an `on_delete` argument to a
 `ForeignKey` (but I was also able to reproduce it with just adding
 `blank=True`) and then running `sqlmigrate` on the generated migration
 results in this output:

 {{{
 BEGIN;
 --
 -- Alter field last_occurrence on event
 --
 ALTER TABLE "event_event" DROP CONSTRAINT
 "last_occurrence_id_refs_id_9b97c921";
 ALTER TABLE "event_event" ADD CONSTRAINT
 "event_event_last_occurrence_id_a6d9e0d9_fk_event_instance_id" FOREIGN KEY
 ("last_occurrence_id") REFERENCES "event_instance" ("id") DEFERRABLE
 INITIALLY DEFERRED;

 COMMIT;
 }}}

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

Re: [Django] #26530: Batch operations on large querysets

2016-04-25 Thread Django

#26530: Batch operations on large querysets
-+-
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 timgraham):

 The server-side cursors ticket is #16614. Should we mark this as a
 duplicate of that one?

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

Re: [Django] #26535: Possible bug - when migrating and removing unique constraint.

2016-04-25 Thread Django

#26535: Possible bug - when migrating and removing unique constraint.
---+--
 Reporter:  jenlu  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


Old description:

> Possible bug - when migrating and removing unique constraint.
>
> Postgres 9.4.1 / 9.5.7 + Django 1.9.5 + psycopg 2.6.1
>
> ——
>
> My setup is models/database representing sports events, and with
> competitors in different events.
>
> Each competitor in different sports has for their model/class:
>
>class Meta:
>unique_together = ('event', 'number')
>
> i.e. ensure a unique starting number in an event, now we are relaxing
> (removing this constraint)
> this but having issues when migrating.
>
> The above is represented in postgress as a UNIQUE constraint
> and in all models.py the above constraint is as-above — but in pg it is
> represented as
>
> (i) UNIQUE (event_id, number)
>
> and sometimes as...
>
> (ii) UNIQUE (number, event_id)
>
> …and now when doing migration - for all tables where it is represented as
> (i) everything
> goes well, but in tables where (ii) the following error:
>
>  File "/Users/XXX/.virtualenvs/ssi195_2711/lib/python2.7/site-
> packages/django/db/migrations/migration.py", line 123, in apply
>operation.database_forwards(self.app_label, schema_editor, old_state,
> project_state)
>  File "/Users/XXX/.virtualenvs/ssi195_2711/lib/python2.7/site-
> packages/django/db/migrations/operations/models.py", line 359, in
> database_forwards
>getattr(new_model._meta, self.option_name, set()),
>  File "/Users/XXX/.virtualenvs/ssi195_2711/lib/python2.7/site-
> packages/django/db/backends/base/schema.py", line 318, in
> alter_unique_together
>self._delete_composed_index(model, fields, {'unique': True},
> self.sql_delete_unique)
>  File "/Users/XXX/.virtualenvs/ssi195_2711/lib/python2.7/site-
> packages/django/db/backends/base/schema.py", line 347, in
> _delete_composed_index
>", ".join(columns),
> ValueError: Found wrong number (0) of constraints for
> match_ppc_ppccompetitor(event_id, number)
>
> So seems to need to do some migrations manually and no biggie - but yet
> strange and unsure if Django or pg issue….
>
> / Jens

New description:

 Possible bug - when migrating and removing unique constraint.

 Postgres 9.4.1 / 9.5.7 + Django 1.9.5 + psycopg 2.6.1

 ——

 My setup is models/database representing sports events, and with
 competitors in different events.

 Each competitor in different sports has for their model/class:
 {{{
class Meta:
unique_together = ('event', 'number')
 }}}
 i.e. ensure a unique starting number in an event, now we are relaxing
 (removing this constraint)
 this but having issues when migrating.

 The above is represented in postgress as a UNIQUE constraint
 and in all models.py the above constraint is as-above — but in pg it is
 represented as

 (i) UNIQUE (event_id, number)

 and sometimes as...

 (ii) UNIQUE (number, event_id)

 …and now when doing migration - for all tables where it is represented as
 (i) everything
 goes well, but in tables where (ii) the following error:
 {{{
  File "/Users/XXX/.virtualenvs/ssi195_2711/lib/python2.7/site-
 packages/django/db/migrations/migration.py", line 123, in apply
operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
  File "/Users/XXX/.virtualenvs/ssi195_2711/lib/python2.7/site-
 packages/django/db/migrations/operations/models.py", line 359, in
 database_forwards
getattr(new_model._meta, self.option_name, set()),
  File "/Users/XXX/.virtualenvs/ssi195_2711/lib/python2.7/site-
 packages/django/db/backends/base/schema.py", line 318, in
 alter_unique_together
self._delete_composed_index(model, fields, {'unique': True},
 self.sql_delete_unique)
  File "/Users/XXX/.virtualenvs/ssi195_2711/lib/python2.7/site-
 packages/django/db/backends/base/schema.py", line 347, in
 _delete_composed_index
", ".join(columns),
 ValueError: Found wrong number (0) of constraints for
 match_ppc_ppccompetitor(event_id, number)
 }}}
 So seems to need to do some migrations manually and no biggie - but yet
 strange and unsure if Django or pg issue….

 / Jens

--

Comment:

 Could you provide a sample project that reproduces the issue?

--
Ticket URL: 
Django

Re: [Django] #26541: Add a DatabaseFeatures.supports_transactions() method for MySQL

2016-04-25 Thread Django

#26541: Add a DatabaseFeatures.supports_transactions() method for MySQL
-+-
 Reporter:  marcinn  |Owner:  nobody
 Type:   |   Status:  new
  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
-+-

Comment (by marcinn):

 > As a workaround until a solution lands in Django, you could create your
 own MySQL backend that sets support_transaction as you like.

 It sound good. Thanks.

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

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

Re: [Django] #26540: Can't run tests without "default" connection set

2016-04-25 Thread Django

#26540: Can't run tests without "default" connection set
-+-
 Reporter:  marcinn  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 This looks like a duplicate of #24394 which is fixed in Django 1.9, though
 there still may be other issues there (#25504).

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

Re: [Django] #26333: GIS geometries classes should be deconstructibles.

2016-04-25 Thread Django

#26333: GIS geometries classes should be deconstructibles.
-+-
 Reporter:  simondrabble |Owner:  niconoe
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  makemigration gis| Triage Stage:  Accepted
  point pointfield   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 I can still reproduce against the master branch.

 The `Point` is still converted to a tuple of floats (which simply drops
 the `srid`) and `migrate` crash if the field's default is actually used
 (e.g. `AddField` instead of `CreateModel` where it's simply ignored).

 Have a look at this test app for more details:
 https://github.com/charettes/django-
 ticketing/commit/dac11b52249e7a061fea81944a5f11e2b92cee86

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

Re: [Django] #26541: Add a DatabaseFeatures.supports_transactions() method for MySQL

2016-04-25 Thread Django

* stage: Unreviewed => Accepted

Comment:

I don't have much MySQL expertise so I'm afraid I can't advise much here
but I don't think Django needs to support the use case of per table
transaction handling. If someone has such a need, perhaps that could be
accomplished by routing to different database aliases.

As a workaround until a solution lands in Django, you could create your
own MySQL backend that sets `support_transaction` as you like. Unless a
discussion on the DevelopersMailingList reaches a different consensus, I
don't think adding something in `OPTIONS` makes sense given that this
doesn't seem to be much of an issue as far as tell. I haven't seen anyone
else hit this problem since the current technique was introduced in Django
1.1 (344f16e2205a4959ba65d975716a38db77d2061e).

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

Re: [Django] #26541: Add a DatabaseFeatures.supports_transactions() method for MySQL

2016-04-25 Thread Django

Comment (by marcinn):

Tim, what about transaction handling where MyISAM engine is set per table?

Checking transaction handling by table creation does not cover this use
case, same as general property of the connection.
So in that case I'd like to see this cleanup as a property/parameter
instead of sniffing feature by table creation (because it is safer and
configurable).

But if you'd like to be perfect you should always inspect transaction (an
atomic session) and raise exception when user is trying to modify "non-
transactional" table. In that case every model should
"support_transaction" or not, and this seems like a design change.

In the other side I'm opposed to MySQL`s engines concept and I'm always
trying to avoid this database where possible. So from my point of view it
is enough to assume that MySQL supports transactions (or not), and allow
to change this property by the user using some OPTION in engine
configuration.

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

Re: [Django] #26538: BaseInlineFormSet Has Inconsistent Fields For Forms

2016-04-25 Thread Django

#26538: BaseInlineFormSet Has Inconsistent Fields For Forms
+
 Reporter:  dsanders11  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by 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/068.78233faf14f8c80d1e15d35a17391044%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26119: Catch ValueError while parsing urls in URLValidator

2016-04-25 Thread Django

#26119: Catch ValueError while parsing urls in URLValidator
--+
 Reporter:  EnTeQuAk  |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):

 * component:  Forms => Core (Other)


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

Re: [Django] #26541: Add a DatabaseFeatures.supports_transactions() method for MySQL (was: Table 'ROLLBACK_TEST' already exists)

2016-04-25 Thread Django

#26541: Add a DatabaseFeatures.supports_transactions() method for MySQL
-+-
 Reporter:  marcinn  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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 timgraham):

 * needs_better_patch:   => 0
 * type:  Bug => Cleanup/optimization
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 For Django's built in database backends, this issues seems to be limited
 to MySQL as the other built in database backend set
 `DatabaseFeatures.supports_transactions = True` and override the default
 implementation which does
 
[https://github.com/django/django/blob/bd145e7209a0e628cced10384bd6f62d65c0f211/django/db/backends/base/features.py#L227-L239
 the feature test] involving the temporary table indicated in the
 traceback. Is it feasible to add a
 `DatabaseFeatures.supports_transactions()` method for the MySQL backend
 that detects transaction support by examining the storage engine?

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

Re: [Django] #19513: update() after annotate(val=Sum(...)) crashes on PostgreSQL & Oracle

2016-04-25 Thread Django

#19513: update() after annotate(val=Sum(...)) crashes on PostgreSQL & Oracle
-+-
 Reporter:  mengzhuo1203@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 timgraham):

 * has_patch:  0 => 1


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

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

Re: [Django] #26052: Consider removing conditional_content_removal

2016-04-25 Thread Django

#26052: Consider removing conditional_content_removal
-+-
 Reporter:  aaugustin|Owner:  susan
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  1.9
 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 Tim Graham ):

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


Comment:

 In [changeset:"bb0b4b705b508451567bcada9106b91b8fca9e86" bb0b4b70]:
 {{{
 #!CommitTicketReference repository=""
 revision="bb0b4b705b508451567bcada9106b91b8fca9e86"
 Fixed #26052 -- Moved conditional_content_removal() processing to the test
 client.
 }}}

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

Re: [Django] #21332: BaseInlineFormSet.add_fields adds multiple InlineForeignKeyFields

2016-04-25 Thread Django

#21332: BaseInlineFormSet.add_fields adds multiple InlineForeignKeyFields
-+-
 Reporter:  Raumkraut|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Forms|  1.6-beta-1
 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 timgraham):

 * has_patch:  0 => 1


Comment:

 #26537 is a duplicate with a [https://github.com/django/django/pull/6503
 PR].

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

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

Re: [Django] #26537: BaseInlineFormSet Adds N Entries to form._meta.fields For FK

2016-04-25 Thread Django

#26537: BaseInlineFormSet Adds N Entries to form._meta.fields For FK
+--
 Reporter:  dsanders11  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Unreviewed
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:   => duplicate


Comment:

 Duplicate of #21332

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

Re: [Django] #26540: Can't run tests without "default" connection set

2016-04-25 Thread Django

#26540: Can't run tests without "default" connection set
-+-
 Reporter:  marcinn  |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 marcinn):

 Setting `dummy` backend results:

 {{{
 Traceback (most recent call last):
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 946, in setUpClass
 if not connections_support_transactions():
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 911, in connections_support_transactions
 for conn in connections.all())
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 911, in 
 for conn in connections.all())
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/utils/functional.py",
 line 59, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/backends/base/features.py",
 line 216, in supports_transactions
 with self.connection.cursor() as cursor:
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/backends/base/base.py",
 line 164, in cursor
 cursor = self.make_cursor(self._cursor())
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/backends/dummy/base.py",
 line 21, in complain
 raise ImproperlyConfigured("settings.DATABASES is improperly
 configured. "
 ImproperlyConfigured: settings.DATABASES is improperly configured. Please
 supply the ENGINE value. Check settings documentation for more details.
 }}}

 > The fact that the default database is mandatory is documented in the
 DATABASES setting

 Yes, but it looks like it could be empty before (?) - #19775.

 > There are still places in Django core code depending on a default
 database (See #13528 for example).

 Yes, also during models registration the default connection is used to
 truncate table names (or something like that). The sqlite3 handler (my
 "default") is preparing some stuff for postgres and mysql (in my case). It
 seems that db router is not used at this stage.

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

Re: [Django] #26530: Batch operations on large querysets

2016-04-25 Thread Django

#26530: Batch operations on large querysets
-+-
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 akaariai):

 I'm ok with the batch(size=100) approach. I haven't had a need for this,
 and I'm unfamiliar how common such cases are. But if this is something
 commonly needed, then I think having an ORM method that does this in a way
 that is both efficient and correct when ran on table modified concurrently
 is the way to go.

 Thinking of this a bit more, batching only on primary key ordering is the
 only safe approach if we want to definitely avoid seeing the same object
 in multiple batches. Otherwise for example:
 {{{
 for batch in qs.order_by('mod_date', 'pk').batch(size=1000):
 for obj in batch:
 obj.foo = 'bar'
 obj.mod_date = datetime.now()
 obj.save()
 }}}
 could end up in indefinite loop.

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

Re: [Django] #26530: Batch operations on large querysets

2016-04-25 Thread Django

#26530: Batch operations on large querysets
-+-
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 mjtamlyn):

 Heh, I actually didn't know about `iterator()`... Good work reading docs
 Marc.

 Batching for background tasks is definitely common though.

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

Re: [Django] #26530: Batch operations on large querysets

2016-04-25 Thread Django

#26530: Batch operations on large querysets
-+-
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 akaariai):

 If the idea is to do something for each object, then
 {{{
 for obj in qs.iterator():
 obj.do_something()
 }}}
 should give you a lot better memory efficiency. Of course, if using
 PostgreSQL, the driver will still fetch all the rows into memory.

 A very good approach would be to finally tackle the named cursors issue.
 Then you could just do:
 {{{
 for obj in qs.iterator(cursor_size=100):
 obj.do_something()
 }}}
 and be done with it. The problem with the named cursor approach is that
 some databases have more or less hard to overcome limitations of what can
 be done with the cursor, how transactions work and so on.

 If you really want batches of object, then we probably need to use the
 pointer approach. Otherwise iterating through a large queryset will end up
 doing queries like `select * from the_query offset 10 limit 100` which
 is very inefficient, and concurrent modifications could end up introducing
 the same object in multiple batches.

 I'm mildly in favor of adding this, as the addition to API surface isn't
 large, and there are a lot of ways to implement the batching in mildly
 wrong ways.

 If we are going for this, then I think the API should be the `for batch in
 qs.batch(size=100)` one. The queryset should be ordered in such a way that
 primary key is the only sorting criteria. We can change that later so that
 primary or some other unique key is a postfix of the order by, but that is
 a bit harder to do.

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

Re: [Django] #26540: Can't run tests without "default" connection set

2016-04-25 Thread Django

#26540: Can't run tests without "default" connection set
-+-
 Reporter:  marcinn  |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 claudep):

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


Comment:

 The fact that the `default` database is mandatory is documented in the
 DATABASES setting
 (https://docs.djangoproject.com/en/1.9/ref/settings/#databases).

 There are still places in Django core code depending on a `default`
 database (See #13528 for example). We should hopefully get rid of them at
 some point, but we aren't there yet.

 As a workaround, did you try to set a dummy backend to the `default`
 alias?

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

Re: [Django] #26333: GIS geometries classes should be deconstructibles.

2016-04-25 Thread Django

#26333: GIS geometries classes should be deconstructibles.
-+-
 Reporter:  simondrabble |Owner:  niconoe
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  makemigration gis| Triage Stage:  Accepted
  point pointfield   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by niconoe):

 Hi,

 I just realized I'm not able to reproduce the initial issue. I've tested
 against 1.8, 1.9.5 and current version.

 Should we close the issue? Or continue working to make sure `GEOSGeometry`
 is deconstructible as suggested by charettes, if that has other benefits?

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

[Django] #26541: Table 'ROLLBACK_TEST' already exists

2016-04-25 Thread Django

#26541: Table 'ROLLBACK_TEST' already exists
--+
 Reporter:  marcinn   |  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
--+
 When something goes wrong during checking database features, the state of
 db stays affected:

 {{{
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 182, in __call__
 self._pre_setup()
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 787, in _pre_setup
 self._fixture_setup()
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 986, in _fixture_setup
 if not connections_support_transactions():
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 911, in connections_support_transactions
 for conn in connections.all())
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 911, in 
 for conn in connections.all())
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/utils/functional.py",
 line 59, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/backends/base/features.py",
 line 217, in supports_transactions
 cursor.execute('CREATE TABLE ROLLBACK_TEST (X INT)')
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/backends/utils.py",
 line 64, in execute
 return self.cursor.execute(sql, params)
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/utils.py",
 line 97, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/backends/utils.py",
 line 62, in execute
 return self.cursor.execute(sql)
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/backends/mysql/base.py",
 line 124, in execute
 return self.cursor.execute(query, args)
   File "/home/marcin/myproject/eggs/MySQL_python-1.2.3-py2.7-linux-
 x86_64.egg/MySQLdb/cursors.py", line 174, in execute
 self.errorhandler(self, exc, value)
   File "/home/marcin/myproject/eggs/MySQL_python-1.2.3-py2.7-linux-
 x86_64.egg/MySQLdb/connections.py", line 36, in defaulterrorhandler
 raise errorclass, errorvalue
 OperationalError: (1050, "Table 'ROLLBACK_TEST' already exists")
 }}}

 1. Django should not create any table during startup - there may be
 readonly or sensitive databases connected
 2. Let the Django do some cleanups, if it must "dig" databases.

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

Re: [Django] #26530: Batch operations on large querysets

2016-04-25 Thread Django

#26530: Batch operations on large querysets
-+-
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 mjtamlyn):

 There are a few ways of approaching it:

 Copying roughly a paginator:
 {{{
 count = qs.count()
 pointer = 0
 while pointer < count:
 for obj in qs[pointer:pointer + batch_size]:
 do_something(obj)
 pointer += batch_size
 }}}

 Basing off e.g. a sequential id, can also apply to time series
 {{{
 pointer = 0
 while True:
 # work from oldest first so incoming objects during the run will get
 processed
 batch = qs.filter(id__gt=pointer).order_by('id')[:batch_size]
 if not batch:
  break
 for obj in batch:
 pointer = obj.id
 do_something(obj)
 }}}

 The operation should also ideally apply to a values or values_list
 queryset, this is a similar piece of code which doesn't have to worry
 about memory as much:
 {{{
 ids = qs.values_list('id', flat=True)
 while user_ids:
 batch, user_ids = user_ids[:100], user_ids[100:]
 queue_task(batch)
 }}}

 -

 My motivation for this patch is twofold - partly I'm bored of writing
 similar code when dealing with large querysets, but also I have seen many
 developers debugging issues with their code because they haven't realised
 10k+ querysets in memory are problematic. Having an easy API to use which
 is documented, with warnings about why you need this, should help people
 to be aware of the issues, and make it easy for them to fix them.

 A better API suggestion could be `for batch in qs.batch(size=100)`. This
 means quite possibly fixing your broken code is just changing one line.

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

[Django] #26540: Can't run tests without "default" connection set

2016-04-25 Thread Django

#26540: Can't run tests without "default" connection set
--+
 Reporter:  marcinn   |  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
--+
 According to use cases described in #19775 and #16752 I'm using project
 with explicit db routing and no "default" connection.

 When I'm trying to run tests with empty 'default' connection, I'm getting:

 {{{
 Traceback (most recent call last):
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 946, in setUpClass
 if not connections_support_transactions():
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 911, in connections_support_transactions
 for conn in connections.all())
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/test/testcases.py",
 line 911, in 
 for conn in connections.all())
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/utils/functional.py",
 line 59, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/backends/base/features.py",
 line 216, in supports_transactions
 with self.connection.cursor() as cursor:
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/backends/base/base.py",
 line 164, in cursor
 cursor = self.make_cursor(self._cursor())
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/backends/dummy/base.py",
 line 21, in complain
 raise ImproperlyConfigured("settings.DATABASES is improperly
 configured. "
 ImproperlyConfigured: settings.DATABASES is improperly configured. Please
 supply the ENGINE value. Check settings documentation for more details.

 }}}

 When running without "default" key configured, I'm getting an error
 probably on the first attempt to get specific connection (not the
 "default" one):

 {{{
 [...]
   File "/home/marcin/myproject/etl/analysis/etltoolkit.py", line 1098, in
 dimension_factory
 sequencer = sequencer or SurrogateKeySequencer(dwhmodel)
   File "/home/marcin/myproject/etl/analysis/etltoolkit.py", line 739, in
 __init__
 self.connection = connection or connections['etlstg']
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/utils.py",
 line 237, in __getitem__
 self.ensure_defaults(alias)
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/utils.py",
 line 168, in ensure_defaults
 conn = self.databases[alias]
   File
 
"/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/utils/functional.py",
 line 59, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File
 "/home/marcin/myproject/eggs/Django-1.8.6-py2.7.egg/django/db/utils.py",
 line 159, in databases
 raise ImproperlyConfigured("You must define a '%s' database" %
 DEFAULT_DB_ALIAS)
 django.core.exceptions.ImproperlyConfigured: You must define a 'default'
 database
 }}}

 The bug lies in `ConnectionHandler.databases()`:

 {{{
 def databases(self):
 if self._databases is None:
 self._databases = settings.DATABASES
 if self._databases == {}:
 self._databases = {
 DEFAULT_DB_ALIAS: {
 'ENGINE': 'django.db.backends.dummy',
 },
 }
 if DEFAULT_DB_ALIAS not in self._databases:
 raise ImproperlyConfigured("You must define a '%s' database" %
 DEFAULT_DB_ALIAS)
 return self._databases
 }}}

 When `ensure_defaults()` asks for specified connection (in my case -
 "etlstg" alias), the `databases()` is called as a property getter  and
 checks existence of DEFAULT_DB_ALIAS.

 Please do not force us to use DEFAULT_DB_ALIAS if you won't allow to
 rename it in settings (#26197).

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

Re: [Django] #26333: GIS geometries classes should be deconstructibles.

2016-04-25 Thread Django

#26333: GIS geometries classes should be deconstructibles.
-+-
 Reporter:  simondrabble |Owner:  niconoe
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  makemigration gis| Triage Stage:  Accepted
  point pointfield   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by niconoe):

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


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

Re: [Django] #26536: Stack overflow in template rendering when using django.template.loaders.cached.Loader

2016-04-25 Thread Django

#26536: Stack overflow in template rendering when using
django.template.loaders.cached.Loader
-+-
 Reporter:  andersroos   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.9
 Severity:  Release blocker  |   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 andersroos):

 Very fast fix, thank you everyone!

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

Re: [Django] #26052: Consider removing conditional_content_removal

2016-04-25 Thread Django

#26052: Consider removing conditional_content_removal
-+-
 Reporter:  aaugustin|Owner:  susan
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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.95d03481db13f707c1ce32e83e7ee517%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11385: DateTimeField doesn't accept ISO 8601 formatted date string

2016-04-25 Thread Django

#11385: DateTimeField doesn't accept ISO 8601 formatted date string
-+
 Reporter:  jtiai|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  datetime orm format  | 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):

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


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

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

45 matches

Mail list logo