[Django] #26571: Documentation about usage of fromtimestamp (wrt timezones) is confusing

[Django]

#26571: Documentation about usage of fromtimestamp (wrt timezones) is confusing
--+
 Reporter:  bronger   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 On , it says:

 For instance, use utcfromtimestamp() instead of fromtimestamp()
 – and don’t forget to set tzinfo to utc.

 But isn't the straightfoward way for getting a timezone-aware UTC object
 {{{
 fromtimestamp(time.time(), utc)
 }}}
 ?

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

[Django] #26570: Test runner imports module package with Python 3.5+

[Django]

#26570: Test runner imports module package with Python 3.5+
---+
 Reporter:  bronger|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Since Python 3.5, unittest's runner searches for tests also in all
 `__init__.py` modules.  The release notes say:

 Found packages are now checked for load_tests regardless of
 whether their path matches pattern, because it is impossible for
 a package name to match the default pattern.

 If you organise your models in a package rather than a single `models.py`
 (the `__init__.py` file contains commands like `from submodule import *`
 to collect all model classes in the package), this leads to an error in a
 bogus test saying that the app is not ready yet.  This happens because the
 model classes are executed, and this occurs too early (it should not occur
 at all).

 A workaround is to say

 {{{
 manage.py test myapp/tests
 }}}

 instead of

 {{{
 manage.py test myapp
 }}}

 if your tests live in `tests/` and only 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/050.c0768a86824466edddf0bc1bbec0efa8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26570: Test runner imports models package with Python 3.5+ (was: Test runner imports module package with Python 3.5+)

[Django]

#26570: Test runner imports models package with Python 3.5+
---+--
 Reporter:  bronger|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 bronger):

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

Re: [Django] #26341: Weird comments in PO files (.html.py filenames)

[Django]

#26341: Weird comments in PO files (.html.py filenames)
-+-
 Reporter:  sylvain-garancher|Owner:  veranika-
 |  sab
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.9
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"9c12eb55ceb2dff6e31399f5e258e4355e883930" 9c12eb5]:
 {{{
 #!CommitTicketReference repository=""
 revision="9c12eb55ceb2dff6e31399f5e258e4355e883930"
 [1.9.x] Fixed #26341 (again) -- Addressed multiple occurrences per line
 use case

 Backport of 4731e9d8 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/075.0b27163d5a607827a8ef5e2180c04472%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26341: Weird comments in PO files (.html.py filenames)

[Django]

#26341: Weird comments in PO files (.html.py filenames)
-+-
 Reporter:  sylvain-garancher|Owner:  veranika-
 |  sab
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.9
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"4731e9d82ea72b6d793fb06713d11d228eb89ace" 4731e9d]:
 {{{
 #!CommitTicketReference repository=""
 revision="4731e9d82ea72b6d793fb06713d11d228eb89ace"
 Fixed #26341 (again) -- Addressed multiple occurrences per line use case
 }}}

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

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

Re: [Django] #26423: Make EmailValidator use HTML5 validation rather than more complicated regular expressions

[Django]

#26423: Make EmailValidator use HTML5 validation rather than more complicated
regular expressions
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by sergei-maertens):

 We should also assert that non-ascii characters are allowed in the local
 part of the e-mail address, see #25986 for background on this 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/067.9612d545e8a50efc553b28f0fd4e4026%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25986: Django crashes on unicode characters in the local part of an e-mail address

[Django]

#25986: Django crashes on unicode characters in the local part of an e-mail 
address
-+-
 Reporter:  sergei-maertens  |Owner:  sergei-
 |  maertens
 Type:  Bug  |   Status:  assigned
Component:  Core (Mail)  |  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 sergei-maertens):

 * needs_better_patch:  1 => 0


Comment:

 Remarks were processed, up for review again (if the build succeeds).

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

Re: [Django] #26565: Allow Prefetch query to use .values()

[Django]

#26565: Allow Prefetch query to use .values()
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, values | 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):

 * has_patch:  0 => 1


Comment:

 Submitted a [https://github.com/django/django/pull/6545 PR] for the
 ''bug'' part. This should be converted to a feature request once it's
 merged.

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

Re: [Django] #26565: Allow Prefetch query to use .values()

[Django]

#26565: Allow Prefetch query to use .values()
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, values | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 I'd say there is a bug and a new feature. We should error nicely on values
 queries, and of course, ability to prefetch values queries would be a nice
 feature for aggregations specifically.

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

Re: [Django] #11964: Add the ability to use database-level CHECK CONSTRAINTS

[Django]

#11964: Add the ability to use database-level CHECK CONSTRAINTS
-+-
 Reporter:  schinckel|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  check contsraint | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by rrauenza):

 Could/should this feature request also handle this case of constraint I
 brought up in this thread?

 https://code.djangoproject.com/ticket/11964

 Basically unique_together doesn't consider a null value unique per SQL
 spec -- which makes perfect sense in single column indexes and is extended
 to multi column indexes.

 So if someone wanted (A, B, NULL) to be a unique row there would need to
 be an index built on the first two columns "where  is null"

 These SO articles give a better overview:

 http://stackoverflow.com/questions/17510261/django-unique-together-
 constraint-failure
 http://dba.stackexchange.com/questions/9759/postgresql-multi-column-
 unique-constraint-and-null-values

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

Re: [Django] #26569: OSM.Mapnik is an obsolete constructor

[Django]

#26569: OSM.Mapnik is an obsolete constructor
-+-
 Reporter:  claudep  |Owner:  claudep
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  GIS  |  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 Claude Paroz ):

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


Comment:

 In [changeset:"4e2ee8662753ca6a2619039b903f11c60709f398" 4e2ee866]:
 {{{
 #!CommitTicketReference repository=""
 revision="4e2ee8662753ca6a2619039b903f11c60709f398"
 Fixed #26569 -- Updated OSM Mapnik constructor
 }}}

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

Re: [Django] #26569: OSM.Mapnik is an obsolete constructor

[Django]

#26569: OSM.Mapnik is an obsolete constructor
-+-
 Reporter:  claudep  |Owner:  claudep
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * type:  Bug => Cleanup/optimization


Comment:

 The initial patch reporter said that the Mapnik constructor did not work.
 In fact, it does work, but requires the `OpenStreetMap.js` file be present
 (which is included in OSMWidget). That's the reason why I don't plan to
 backport the fix.

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

Re: [Django] #26569: OSM.Mapnik is an obsolete constructor

[Django]

#26569: OSM.Mapnik is an obsolete constructor
-+-
 Reporter:  claudep  |Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


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

[Django] #26569: OSM.Mapnik is an obsolete constructor

[Django]

#26569: OSM.Mapnik is an obsolete constructor
-+
   Reporter:  claudep|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  GIS|Version:  1.9
   Severity:  Normal |   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  |
-+
 OpenLayers.Layer.OSM.Mapnik can simply be replaced by
 OpenLayers.Layer.OSM(), as was done in [1ec25c4fb7df0fdb].

 [https://github.com/django/django/pull/6358 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/050.7052c3ba9380dbed02a9f1d4a6af113c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26565: Allow Prefetch query to use .values()

[Django]

#26565: Allow Prefetch query to use .values()
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, values | 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):

 * stage:  Unreviewed => Accepted


Comment:

 I'm not sure if this should be considered a ''New Feature'' or a ''Bug''.

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

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

Re: [Django] #26565: Allow Prefetch query to use .values()

[Django]

#26565: Allow Prefetch query to use .values()
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, values | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mlorant):

 Yes, same error & traceback using `PayrollLine.objects.values('code')`
 only.

 The error seems obvious: the prefetch mechanism tries to access to
 attributes for some reason, but it got a dict from the query, not model
 instances...

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

Re: [Django] #26565: Allow Prefetch query to use .values() (was: Allow Prefetch query to returns aggregations)

[Django]

#26565: Allow Prefetch query to use .values()
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, values | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * needs_better_patch:   => 0
 * version:  1.9 => master
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I doubt this is related to the linked PR or aggregation. I believe
 `Prefetch.queryset` cannot be used with `values()` queryset.

 Please confirm you get a similar crash with the following queryset:

 {{{#!python
 queryset = PayrollLine.objects.values('code')
 Order.objects.prefetch_related(
 Prefetch('pay_lines', queryset=queryset, to_attr='pay_lines_values')
 )
 }}}

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

Re: [Django] #26567: Update references to the HTTP spec

[Django]

#26567: Update references to the HTTP spec
--+
 Reporter:  vfaronov  |Owner:  vfaronov
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  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):

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

Re: [Django] #26568: in_bulk when run on a query set should not need a list of IDs

[Django]

#26568: in_bulk when run on a query set should not need a list of IDs
-+-
 Reporter:  brillgen |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
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
 * needs_better_patch:   => 0
 * component:  Uncategorized => Database layer (models, ORM)
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization


Comment:

 Duplicate of #8065 (fixed in Django 1.10).

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

[Django] #26568: in_bulk when run on a query set should not need a list of IDs

[Django]

#26568: in_bulk when run on a query set should not need a list of IDs
---+
 Reporter:  brillgen   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 in_bulk provides a great shortcut for getting a primary key dictionary for
 accessing objects randomly without hitting the database repeatedly.
 However, for some use case it has been designed as a manager function
 which takes a list of PKs. But when it is run on a query set, by default
 it should just return that very query set in a dictionary form (sort of
 obvious isn't it?)

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

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

[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:"eab5df12b664b154b2e280330aa43d8c0621b94a" eab5df1]:
 {{{
 #!CommitTicketReference repository=""
 revision="eab5df12b664b154b2e280330aa43d8c0621b94a"
 Refs #22936 -- Moved more of Field.get_db_prep_lookup() to lookups.
 }}}

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

Re: [Django] #26567: Update references to the HTTP spec

[Django]

#26567: Update references to the HTTP spec
-+-
 Reporter:  vfaronov |Owner:  vfaronov
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 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 vfaronov):

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


Comment:

 Fixed it on my [https://github.com/vfaronov/django/tree/ticket_26567
 vfaronov:ticket_26567] branch. Didn’t touch comments where it was not
 obvious that the code adhered to the newer standard.

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

Re: [Django] #26567: Update references to the HTTP spec (was: Update references to the HTTP spec in the docs)

[Django]

#26567: Update references to the HTTP spec
-+-
 Reporter:  vfaronov |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 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 vfaronov):

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


Old description:

> In multiple places, the docs reference
> [https://tools.ietf.org/html/rfc2616 RFC 2616], which has been obsoleted
> by RFCs [https://tools.ietf.org/html/rfc7230 7230] through
> [https://tools.ietf.org/html/rfc7235 7235].

New description:

 In multiple places, the docs and code comments reference
 [https://tools.ietf.org/html/rfc2616 RFC 2616], which has been obsoleted
 by RFCs [https://tools.ietf.org/html/rfc7230 7230] through
 [https://tools.ietf.org/html/rfc7235 7235].

--

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

[Django] #26567: Update references to the HTTP spec in the docs

[Django]

#26567: Update references to the HTTP spec in the docs
--+
 Reporter:  vfaronov  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 In multiple places, the docs reference
 [https://tools.ietf.org/html/rfc2616 RFC 2616], which has been obsoleted
 by RFCs [https://tools.ietf.org/html/rfc7230 7230] through
 [https://tools.ietf.org/html/rfc7235 7235].

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

Re: [Django] #26566: Wrong example of Cache-Control in the docs

[Django]

#26566: Wrong example of Cache-Control in the docs
---+--
 Reporter:  vfaronov   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 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 vfaronov):

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


Comment:

 I can’t come up with a correct example that would also be convincing.
 Maybe it’s best to remove the example and just mention that you can
 directly set `Cache-Control` with that decorator.

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

[Django] #26566: Wrong example of Cache-Control in the docs

[Django]

#26566: Wrong example of Cache-Control in the docs
---+
 Reporter:  vfaronov   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Django’s [https://docs.djangoproject.com/en/dev/topics/cache/ caching
 docs] provide the following example of setting the Cache-Control header:

 In this example, `cache_control` tells caches to revalidate the cache
 on every access and to store cached versions for, at most, 3,600 seconds:

 {{{
 from django.views.decorators.cache import cache_control

 @cache_control(must_revalidate=True, max_age=3600)
 def my_view(request):
 # ...
 }}}

 This is wrong. What it really tells caches is:

 * [https://tools.ietf.org/html/rfc7234#section-5.2.2.8 max-age]=3600: the
 response is “fresh,” and can be served directly from cache (without
 revalidation), for 3600 seconds;
 * [https://tools.ietf.org/html/rfc7234#section-5.2.2.1 must-revalidate]:
 after these 3600 seconds, when the response becomes “stale,” it cannot be
 served from cache (without revalidation) even if otherwise that would be
 allowed, such as when the cache is disconnected from the network.

 In my tests, with these directives, both Chrome and Firefox serve the page
 from cache after the first access.

 The right directive for “revalidate on every access” is
 [https://tools.ietf.org/html/rfc7234#section-5.2.2.2 no-cache]. And as far
 as I know, there is no directive to limit the time for which a response is
 stored; only the [https://tools.ietf.org/html/rfc7234#section-5.2.2.3 no-
 store] directive that forbids storage entirely.

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

Re: [Django] #26564: Migration for renaming M2M field intermediate model causes exception

[Django]

#26564: Migration for renaming M2M field intermediate model causes exception
+--
 Reporter:  MJafarMashhadi  |Owner:  nobody
 Type:  Bug |   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
+--

Comment (by MJafarMashhadi):

 I checked  {{{ type(old_field.remote_field.through) }}} and it is a
 string.
 That's because in models i used class name as a string not pointer to
 class name. I mean i defined through filed like this:
 {{{ services = models.ManyToManyField('Service',
 through='ServiceActivation') }}}
 not like this:
 {{{ services = models.ManyToManyField('Service',
 through=ServiceActivation) }}}

 The code checks {{{ _meta }}} on {{{ old_field.remote_field.through }}}
 field, since it's still a string and is not resolved to corresponding
 class it raises exception above ({{{ AttributeError: 'str' object has no
 attribute '_meta' }}}).

 Since this is a no-op migration i can just remove the migration without
 breaking my website as a workaround, But i think this definitely is a bug
 in migrations not something that just happened to me.

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

[Django] #26565: Allow Prefetch query to returns aggregations

[Django]

#26565: Allow Prefetch query to returns aggregations
--+
 Reporter:  mlorant   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:  prefetch,
  |  values
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I came across a use case that does not seems to be possible using the
 Django ORM on Django 1.9.

 Let's says I want to get all objects from a `Order` model and prefetch for
 each order all pay lines, grouped per code, to get a list similar to:
 `[{'code': 'A', 'number': 3, 'amount': 1000}, {'code': 'B', 'number': 1,
 'amount': 5000}]` if the order has four PayRollLine associated, with 3
 where code=A and 1 where code=B.

 {{{
 # Query that will be used inside the `Prefetch` object later
 # Let's assume quantity and unit_amount can't be null in the query
 # to avoid extra Coalesce...
 prefetch_qs = (
 PayrollLine.objects.values('code').annotate(
 number=ExpressionWrapper(
 Sum(F('quantity')), output_field=DecimalField()
 ),
 amount=ExpressionWrapper(
 Sum(F('unit_amount') * F('quantity')),
 output_field=DecimalField()
 ),
 )
 )
 print(
 Order.objects.all()
 .prefetch_related(
 Prefetch('pay_lines', queryset=prefetch_qs,
 to_attr='pay_lines_grouped')
 )
 )
 }}}

 The first query works fine alone, outside the prefetch object. But, when
 executing the second query, Django raises an exception:

 {{{
 Traceback (most recent call last):
   [...]
   File "/data/.virtualenvs/ORFEO/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 234, in __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File "/data/.virtualenvs/ORFEO/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 258, in __iter__
 self._fetch_all()
   File "/data/.virtualenvs/ORFEO/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 1076, in _fetch_all
 self._prefetch_related_objects()
   File "/data/.virtualenvs/ORFEO/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 656, in
 _prefetch_related_objects
 prefetch_related_objects(self._result_cache,
 self._prefetch_related_lookups)
   File "/data/.virtualenvs/ORFEO/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 1457, in
 prefetch_related_objects
 obj_list, additional_lookups = prefetch_one_level(obj_list,
 prefetcher, lookup, level)
   File "/data/.virtualenvs/ORFEO/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 1556, in prefetch_one_level
 prefetcher.get_prefetch_queryset(instances,
 lookup.get_current_queryset(level)))
   File "/data/.virtualenvs/ORFEO/local/lib/python2.7/site-
 packages/django/db/models/fields/related_descriptors.py", line 544, in
 get_prefetch_queryset
 instance = instances_dict[rel_obj_attr(rel_obj)]
   File "/data/.virtualenvs/ORFEO/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py", line 597, in
 get_local_related_value
 return self.get_instance_value_for_fields(instance,
 self.local_related_fields)
   File "/data/.virtualenvs/ORFEO/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py", line 605, in
 get_instance_value_for_fields
 opts = instance._meta
 AttributeError: 'dict' object has no attribute '_meta'
 }}}

 Looks like Django can't work with dict in prefetch_related... On IRC,
 someone point me to [this PR](https://github.com/django/django/pull/6478)
 that could resolve my problem but I think it should be verified with unit
 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/050.275dd503dcd42166eb62ebea25af54a9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.