Re: [Django] #25839: RequestContext does not apply context processors [regression]

[Django]

#25839: RequestContext does not apply context processors [regression]
-+-
 Reporter:  direx|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  RequestContext,  | Triage Stage:  Accepted
  regression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 (In case that's not clear enough, saying "you are making this a little too
 easy for you" to a person who works in their free time guarantees their
 non-cooperation. My involvement with this issue stops here.)

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

Re: [Django] #25839: RequestContext does not apply context processors [regression]

[Django]

#25839: RequestContext does not apply context processors [regression]
-+-
 Reporter:  direx|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  RequestContext,  | Triage Stage:  Accepted
  regression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Can you submit a patch?

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

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

Re: [Django] #25839: RequestContext does not apply context processors [regression]

[Django]

#25839: RequestContext does not apply context processors [regression]
-+-
 Reporter:  direx|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  RequestContext,  | Triage Stage:  Accepted
  regression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by direx):

 By saying that this is not part of the public API or not a supported usage
 of `RequestContext` you are making this a little too easy for you.

 After looking at the Django 1.7 documentation these are facts:

 1. `RequestContext` is a special `Context` class. One of the differences
 „''is that it automatically populates the context with a few variables,
 according to your `TEMPLATE_CONTEXT_PROCESSORS` setting.''“ (quote from
 documentation)

 2. Another quote from the documentation: „''Most of the time, you’ll
 instantiate Context objects by passing in a fully-populated dictionary to
 Context(). But you can add and delete items from a Context object once
 it’s been instantiated, too, using standard dictionary syntax''“. Note the
 '''standard dictionary syntax''' here.

 So I don't see why the behavior described in this bug should not be
 considered part of the public API. The ''usage as dictionary'' is actually
 even documented and encouraged (also in 1.8, section ''Playing with
 Context objects''). So I'd still consider this a public API breakage.

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

Re: [Django] #25837: migration fails when there is initial option set on form field

[Django]

#25837: migration fails when there is initial option set on form field
---+--
 Reporter:  kaselis|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.9rc1
 Severity:  Normal |   Resolution:  invalid
 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 shaib):

 https://docs.djangoproject.com/en/1.9/releases/1.9/#urls

 Because before 1.9, urls were not imported until the first request came in
 (and thus, not at all for migrations)

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

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

Re: [Django] #25839: RequestContext does not apply context processors [regression]

[Django]

#25839: RequestContext does not apply context processors [regression]
-+-
 Reporter:  direx|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  RequestContext,  | Triage Stage:  Accepted
  regression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * severity:  Release blocker => Normal


Comment:

 Thanks Carl, you've explained the situation more clearly than I would have
 been able to. This is the intended behavior. It does '''not''' break the
 '''public''' API.

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

Re: [Django] #25734: Nodata value not excluded when computing GDALBand min/max values

[Django]

#25734: Nodata value not excluded when computing GDALBand min/max values
-+
 Reporter:  yellowcap|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal gis  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by claudep):

 We might have to resort to variants of `assertAlmostEqual` here (AFAIK,
 the default `assertAlmostEqual` doesn't work on tuples).

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

Re: [Django] #19726: Ordering on booleans works different with SQLite and Postgres

[Django]

#19726: Ordering on booleans works different with SQLite and Postgres
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felipeochoa):

 I just solved this by annotating the model as follows:

 {{{
 Transaction.objects.annotate(
 submitted_as_0_1=Case(When(submitted=True, then=Value(1)),
   default=Value(0),
   output_field=PositiveSmallIntegerField())
 ).order_by('submitted_as_0_1')
 }}}

 Maybe we can extend `order_by` to automate this translation: There could
 be a double-underscore extension like `__as_0_1` that one could use in
 `order_by` fields that would be automatically converted into this
 annotation. I haven't benchmarked the performance impact of this change,
 but since it's an opt-in feature, users can make their own decisions.

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

Re: [Django] #25734: Nodata value not excluded when computing GDALBand min/max values

[Django]

#25734: Nodata value not excluded when computing GDALBand min/max values
-+
 Reporter:  yellowcap|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal gis  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * cc: bmispelon (added)
 * has_patch:  1 => 0
 * stage:  Ready for checkin => Accepted


Comment:

 Baptiste, please provide:
 {{{
 >>> from django.contrib.gis.gdal import gdal_version
 >>> gdal_version()
 }}}

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

Re: [Django] #25734: Nodata value not excluded when computing GDALBand min/max values

[Django]

#25734: Nodata value not excluded when computing GDALBand min/max values
-+-
 Reporter:  yellowcap|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal gis  | 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 yellowcap):

 That could also be related to differences in GDAL, could you please also
 post the GDAL version you are using for me to reproduce the failure?
 Thanks.

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

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

Re: [Django] #25828: Aggregation and annotation using a postgres JSONField

[Django]

#25828: Aggregation and annotation using a postgres JSONField
-+-
 Reporter:  malefice |Owner:
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  JSONField| Triage Stage:
  aggregation annotation |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mjtamlyn):

 * status:  new => closed
 * type:  Uncategorized => Cleanup/optimization
 * resolution:   => worksforme


Comment:

 This would be about supporting generic `__` lookups in more places. It's
 not a bug, it's a known restriction of the API for `values()` and
 `annotate()`. Now that transforms are expressions, it's possible that
 something like this should work:

 `.annotate(Avg(KeyLookup('key_name', 'field_name')))`

 but I haven't tried it, so syntax might not be quite right there. I
 believe that `annotate` works and `values` does not, but I may be wrong.

 In any case, annotation first and then using that annotation later will
 generally allow more complex queries than you can use directly.

 I'm going to close this for now as the expansion of the ORM to cover
 things like this does not need another ticket. If you can't find a way to
 make the above work (or similar) let me know.

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

Re: [Django] #25823: String inconststency between "View documentation" and "Back to Views Documentation"

[Django]

#25823: String inconststency between "View documentation" and "Back to Views
Documentation"
--+
 Reporter:  gunchleoc |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admindocs |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  i18n  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"89b6856aa615bff5cccd1eeef61ab02d6e38498a" 89b6856a]:
 {{{
 #!CommitTicketReference repository=""
 revision="89b6856aa615bff5cccd1eeef61ab02d6e38498a"
 Fixed #25823 -- Made some titles consistent in admindocs.
 }}}

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

Re: [Django] #25828: Aggregation and annotation using a postgres JSONField

[Django]

#25828: Aggregation and annotation using a postgres JSONField
-+-
 Reporter:  malefice |Owner:
 Type:  Uncategorized|   Status:  new
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:
  aggregation annotation |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * cc: mjtamlyn (added)


Comment:

 Marc, any ideas about 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/066.cc73369599a04e55538a7cf6773c4d63%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25834: Better expose ORM grouping semantics

[Django]

#25834: Better expose ORM grouping semantics
-+-
 Reporter:  rtpg |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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:   => invalid


Comment:

 Closing as "invalid" since this is a high level discussion that needs
 smaller, more actionable tickets pending the outcome of the mailing list
 discussions.

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

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

Re: [Django] #25839: RequestContext does not apply context processors [regression]

[Django]

#25839: RequestContext does not apply context processors [regression]
-+-
 Reporter:  direx|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  RequestContext,  | Triage Stage:  Accepted
  regression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by carljm):

 As part of the multiple-template-engines feature, Django 1.8 refactored
 the Django template language to remove the direct coupling to global
 settings, instead making it possible to instantiate multiple
 independently-configured `Engine` instances (and configure multiple such
 instances via the new `TEMPLATES` setting). Because of this, it's no
 longer possible for `RequestContext` to automatically fetch the list of
 configured context processors from settings (the `TEMPLATES` setting can
 define multiple instances of the DTL with different lists of context
 processors, so how could `RequestContext` possibly know which list of
 context processors to use?). This was handled by adding a new context-
 manager method `RequestContext.bind_template` which temporarily binds a
 `RequestContext` to a template instance, in the process applying all the
 context processors from that template's engine configuration.

 This solution is fully backwards-compatible for the only documented usage
 of a `RequestContext`, which is to pass it into a template render and
 access its values in the template. It's true that it's not backwards-
 compatible for the usage you demonstrate, directly accessing values from
 the context as a dictionary without rendering a template, but this is not
 a documented or supported mode of use for `RequestContext`. If you need
 this usage, you must now first bind the context to a specific template:

 {{{
 from django.template import engines

 engine = engines['default']
 tpl = engine.get_template('some/template.html')
 ctx = RequestContext(request)
 with ctx.bind_template(tpl):
 print(ctx['user'])
 }}}

 It may be possible to restore the old behavior for this usage using
 `Engine.get_default()` (it would only work if there's only a single
 instance of the DTL configured in settings); personally I don't think
 that's worth doing, or that this use of `RequestContext` should be
 supported.

 Alternatively, we could add a warning to the 1.8 release notes about this,
 but this usage is so unusual that I'm not even sure that's worth doing.

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

Re: [Django] #25836: add support for MakeLine aggregate on SpatiaLite backend

[Django]

#25836: add support for MakeLine aggregate on SpatiaLite backend
-+--
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  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.cfb3308db47d0e0108ae24e7a2aa9bc6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25839: RequestContext does not apply context processors [regression]

[Django]

#25839: RequestContext does not apply context processors [regression]
-+-
 Reporter:  direx|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  RequestContext,  | Triage Stage:  Accepted
  regression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * Attachment "test_25839.py" 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/063.d2908378d20754cd8cbe180fff07d499%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25839: RequestContext does not apply context processors [regression]

[Django]

#25839: RequestContext does not apply context processors [regression]
-+-
 Reporter:  direx|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  RequestContext,  | Triage Stage:  Accepted
  regression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * cc: aaugustin (added)
 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Bisected to 37505b6397058bcc3460f23d48a7de9641cd6ef0. The test I used to
 bisect is attached.

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

[Django] #25839: RequestContext does not apply context processors [regression]

[Django]

#25839: RequestContext does not apply context processors [regression]
-+
 Reporter:  direx|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.8
 Severity:  Release blocker  |   Keywords:  RequestContext, regression
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Prior to Django 1.8 `django.template.RequestContext` always had the
 context from all of the `TEMPLATE_CONTEXT_PROCESSORS` applied. In Django
 1.8 this is no longer the case, which breaks the API. As this has neither
 been announced nor documented anywhere I'd consider this a critical
 regression.

 The following view code no longer works with the default
 `TEMPLATE_CONTEXT_PROCESSORS` setting:

 {{{
 from django.template import RequestContext

 def my_view(request):
 context = RequestContext(request)
 print context['user']
 #...
 }}}

 Actually `user` should be put there by
 `django.contrib.auth.context_processors.auth`. It is also present in
 templates rendered by `render()`, but not in `RequestContext`. Of course
 this does not only apply to the `user` context variable, but to all
 context variables set by context processors.

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

Re: [Django] #15815: Support memcached binary protocol in PyLibMCCache

[Django]

#15815: Support memcached binary protocol in PyLibMCCache
-+
 Reporter:  mtigas   |Owner:
 Type:  New feature  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  sprint2013   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by mlowicki):

 * cc: mlowicki@… (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/064.43dcc8c468249d407564ecfc8f3652cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15815: Support memcached binary protocol in PyLibMCCache

[Django]

#15815: Support memcached binary protocol in PyLibMCCache
-+
 Reporter:  mtigas   |Owner:
 Type:  New feature  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  sprint2013   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by mlowicki):

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

Re: [Django] #25835: remove backwards-compatibility alias `Adaptor`

[Django]

#25835: remove backwards-compatibility alias `Adaptor`
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"49f1cc54e6ce1147645372214c5b5a56c655da9e" 49f1cc5]:
 {{{
 #!CommitTicketReference repository=""
 revision="49f1cc54e6ce1147645372214c5b5a56c655da9e"
 Fixed #25835 -- Removed Adaptor alias from spatial operations classes.
 }}}

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

Re: [Django] #25827: DateTimeField in admin TabularInline has unsightly left margin

[Django]

#25827: DateTimeField in admin TabularInline has unsightly left margin
-+
 Reporter:  timgraham|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham ):

 In [changeset:"d9df079dd947d4c7ff495dead4ec94164b92204d" d9df079]:
 {{{
 #!CommitTicketReference repository=""
 revision="d9df079dd947d4c7ff495dead4ec94164b92204d"
 [1.9.x] Fixed #25827 -- Removed extra spacing in admin's DateTimeField.

 Backport of 2084aed20c4d350a4192a0cfaa22140d4af3396c from master
 }}}

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

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

Re: [Django] #25827: DateTimeField in admin TabularInline has unsightly left margin

[Django]

#25827: DateTimeField in admin TabularInline has unsightly left margin
-+
 Reporter:  timgraham|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"2084aed20c4d350a4192a0cfaa22140d4af3396c" 2084aed]:
 {{{
 #!CommitTicketReference repository=""
 revision="2084aed20c4d350a4192a0cfaa22140d4af3396c"
 Fixed #25827 -- Removed extra spacing in admin's DateTimeField.
 }}}

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

Re: [Django] #25833: Non-atomic migrations

[Django]

#25833: Non-atomic migrations
-+
 Reporter:  Pankrat  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Pankrat):

 If the migration doesn't apply without errors, it will not be marked as
 applied.

 It's up to the user to handle those migration errors gracefully (e.g. skip
 already migrated rows when re-running a previously failed non-atomic
 migration).

 Would it be enough to mention this behaviour in the non-atomic migration
 documentation?

 AFAIU, non-atomic migrations have the same semantics as applying
 migrations on a database that doesn't support transactional DDL.

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

Re: [Django] #25838: ./manage.py shell creates unnecessary nested exceptions

[Django]

#25838: ./manage.py shell creates unnecessary nested exceptions
-+-
 Reporter:  bmispelon|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 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 apollo13):

 I'd rather add "plain" to the list of available shells all time, so we
 just need a simple loop over all the shells (if "plain" is always added as
 last one, there should be no need for extra fallback handling etc…)

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

Re: [Django] #25838: ./manage.py shell creates unnecessary nested exceptions

[Django]

#25838: ./manage.py shell creates unnecessary nested exceptions
-+-
 Reporter:  bmispelon|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 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 bmispelon):

 Changing the logic in `core/management/shell.py` from
 {{{#!py
 try:
 if options['plain']:
 # Don't bother loading IPython, because the user wants plain
 Python.
 raise ImportError

 self.run_shell(shell=options['interface'])
 except ImportError:
 # do a bunch of stuff
 }}}

 to:
 {{{#!py
 try:
 if options['plain']:
 # Don't bother loading IPython, because the user wants plain
 Python.
 raise ImportError

 self.run_shell(shell=options['interface'])
 except ImportError:
 pass
 else:
 return
 # do a bunch of stuff
 }}}

 Seems to fix the issue for 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/067.418d73004ebf1fa4ef4451eafc9c1765%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25838: ./manage.py shell creates unnecessary nested exceptions

[Django]

#25838: ./manage.py shell creates unnecessary nested exceptions
-+-
   Reporter:  bmispelon  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Core   |Version:  master
  (Management commands)  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Steps to reproduce (using Python 3):

 * Open a python shell with ./manage.py shell
 * raise an exception with `raise Exception`

 Notice how the exception is nested with another one:
 {{{#!py
 >>> raise Exception
 Traceback (most recent call last):
   File "./django/core/management/commands/shell.py", line 67, in handle
 raise ImportError
 ImportError

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "", line 1, in 
 Exception
 }}}

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

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

Re: [Django] #25837: migration fails when there is initial option set on form field

[Django]

#25837: migration fails when there is initial option set on form field
---+--
 Reporter:  kaselis|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.9rc1
 Severity:  Normal |   Resolution:  invalid
 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 kaselis):

 Thanks, it works fine with a change. I don't understand though why it was
 working in 1.8.7 version.

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

Re: [Django] #25837: migration fails when there is initial option set on form field

[Django]

#25837: migration fails when there is initial option set on form field
---+--
 Reporter:  kaselis|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.9rc1
 Severity:  Normal |   Resolution:  invalid
 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 knbk):

 {{{
 File "/home/rapolas/temp/mysite/myapp/forms.py", line 9, in ReportForm
 initial=[item for item in Item.objects.all()])
 }}}

 Like I said, this executes a query when the form is imported. You need to
 change it to `initial=Item.objects.all()`.

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

Re: [Django] #25837: migration fails when there is initial option set on form field

[Django]

#25837: migration fails when there is initial option set on form field
---+--
 Reporter:  kaselis|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.9rc1
 Severity:  Normal |   Resolution:  invalid
 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 kaselis):

 {{{
 #!div style="font-size: 80%"
 {{{
 (venv)➜  mysite $  python manage.py migrate
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 350, in
 execute_from_command_line
 utility.execute()
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 342, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 348, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 398, in execute
 self.check()
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 426, in check
 include_deployment_checks=include_deployment_checks,
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/core/checks/registry.py", line 75, in run_checks
 new_errors = check(app_configs=app_configs)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/core/checks/urls.py", line 10, in check_url_config
 return check_resolver(resolver)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/core/checks/urls.py", line 19, in check_resolver
 for pattern in resolver.url_patterns:
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/utils/functional.py", line 33, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/core/urlresolvers.py", line 417, in url_patterns
 patterns = getattr(self.urlconf_module, "urlpatterns",
 self.urlconf_module)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/utils/functional.py", line 33, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/core/urlresolvers.py", line 410, in urlconf_module
 return import_module(self.urlconf_name)
   File "/usr/lib/python2.7/importlib/__init__.py", line 37, in
 import_module
 __import__(name)
   File "/home/rapolas/temp/mysite/mysite/urls.py", line 20, in 
 from myapp import views
   File "/home/rapolas/temp/mysite/myapp/views.py", line 4, in 
 from .forms import ReportForm
   File "/home/rapolas/temp/mysite/myapp/forms.py", line 5, in 
 class ReportForm(forms.Form):
   File "/home/rapolas/temp/mysite/myapp/forms.py", line 9, in ReportForm
 initial=[item for item in Item.objects.all()])
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 258, in __iter__
 self._fetch_all()
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 1074, in _fetch_all
 self._result_cache = list(self.iterator())
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 52, in __iter__
 results = compiler.execute_sql()
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 852, in execute_sql
 cursor.execute(sql, params)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 79, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/db/utils.py", line 95, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/rapolas/temp/mysite/venv/local/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return 

Re: [Django] #25837: migration fails when there is initial option set on form field

[Django]

#25837: migration fails when there is initial option set on form field
---+--
 Reporter:  kaselis|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.9rc1
 Severity:  Normal |   Resolution:  invalid
 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 shaib):

 I took a look through your code, and could not find a reason for your
 forms to be imported in the migration.

 Could you save us the trouble of running it, and just paste your fill
 traceback?

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

Re: [Django] #25837: migration fails when there is initial option set on form field

[Django]

#25837: migration fails when there is initial option set on form field
---+--
 Reporter:  kaselis|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.9rc1
 Severity:  Normal |   Resolution:  invalid
 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 kaselis):

 Have you tried the attached project? It doesn't have any DB inside, and
 migrations work fine with 1.8 django, but fails with 1.9rc2. So in order
 to reproduce - download the project, install django 1.8, run ./manage
 migrate. Works fine. Remove db.sqlite3, install django 1.9rc2, run
 ./manage migrate. Migrations fail.

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

Re: [Django] #25837: migration fails when there is initial option set on form field

[Django]

#25837: migration fails when there is initial option set on form field
---+--
 Reporter:  kaselis|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.9rc1
 Severity:  Normal |   Resolution:  invalid
 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 knbk):

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


Comment:

 You cannot query the database when a file is imported. When you use
 `initial=Item.objects.all()`, the query will be lazy, and it won't result
 in an error. If you need to evaluate the queryset before passing it to
 initial, you need to do so in the `__init__` method of your form.

 This probably works fine on 1.8 because you have an existing database in
 your 1.8 setup. It won't work if you deploy in a new 1.8 environment
 without an existing database.

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

Re: [Django] #25765: makemigrations and app_label are incompatible

[Django]

#25765: makemigrations and app_label are incompatible
-+-
 Reporter:  ograycode|Owner:  tgmiller5
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by tgmiller5):

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


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

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

Re: [Django] #25836: add support for MakeLine aggregate on SpatiaLite backend

[Django]

#25836: add support for MakeLine aggregate on SpatiaLite backend
-+--
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 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 sir-sigurd):

 * has_patch:  0 => 1


Comment:

 PR -- https://github.com/django/django/pull/5747

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

[Django] #25837: migration fails when there is initial option set on form field

[Django]

#25837: migration fails when there is initial option set on form field
---+
 Reporter:  kaselis|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9rc1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 It requires some setup to reproduce it, but essentially: create a new
 project, create a new app, create a simple form, for example:

 {{{
 #!div style="font-size: 80%"
 {{{
 from .models import Item

 class ReportForm(forms.Form):
 items = forms.ModelMultipleChoiceField(
 queryset=Item.objects.all(),
 widget=forms.CheckboxSelectMultiple,
 initial=[item for item in Item.objects.all()])
 }}}
 }}}

 Import that form in the view and that view in urls and migration starts to
 fail, complaining about missing table (django.db.utils.OperationalError:
 no such table: myapp_item). It does work fine in django 1.8. Attaching
 sample project. Tested on django 1.9rc2 (dropdown doesn't have that
 version to select)

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

Re: [Django] #25837: migration fails when there is initial option set on form field

[Django]

#25837: migration fails when there is initial option set on form field
---+
 Reporter:  kaselis|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9rc1
 Severity:  Normal | Resolution:
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by kaselis):

 * Attachment "mysite.tar.gz" added.

 Sample project

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

Re: [Django] #25836: add support for MakeLine aggregate on SpatiaLite backend

[Django]

#25836: add support for MakeLine aggregate on SpatiaLite backend
-+--
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  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 sir-sigurd):

 * owner:  nobody => sir-sigurd
 * needs_docs:   => 0
 * status:  new => assigned
 * needs_tests:   => 0
 * needs_better_patch:   => 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/068.f0cd55ae1e0a8c18c9bc388ee0a9ae68%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25836: add support for MakeLine aggregate on SpatiaLite backend

[Django]

#25836: add support for MakeLine aggregate on SpatiaLite backend
-+
 Reporter:  sir-sigurd   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  GIS  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+


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

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

Re: [Django] #25824: Assertions in libmemcached when multiple django.core.cache.backends.memcached.PyLibMCCache backends used

[Django]

#25824: Assertions in libmemcached when multiple
django.core.cache.backends.memcached.PyLibMCCache backends used
---+--
 Reporter:  mlowicki   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:  invalid
 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 apollo13):

 * resolution:  needsinfo => invalid


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

Re: [Django] #25824: Assertions in libmemcached when multiple django.core.cache.backends.memcached.PyLibMCCache backends used

[Django]

#25824: Assertions in libmemcached when multiple
django.core.cache.backends.memcached.PyLibMCCache backends used
---+--
 Reporter:  mlowicki   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:  needsinfo
 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 apollo13):

 Jupp, that certainly does cause such behavior.

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

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

Re: [Django] #25824: Assertions in libmemcached when multiple django.core.cache.backends.memcached.PyLibMCCache backends used

[Django]

#25824: Assertions in libmemcached when multiple
django.core.cache.backends.memcached.PyLibMCCache backends used
---+--
 Reporter:  mlowicki   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.8
 Severity:  Normal |   Resolution:  needsinfo
 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 mlowicki):

 It turned out we were assigning cache backend to variable at the top of
 the module so all threads were using the same instance.

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

Re: [Django] #25835: remove backwards-compatibility alias `Adaptor`

[Django]

#25835: remove backwards-compatibility alias `Adaptor`
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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 sir-sigurd):

 * has_patch:  0 => 1


Comment:

 PR -- https://github.com/django/django/pull/5746

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