date:20150505

Re: [Django] #24497: Truncation of microseconds in DateTimeField leads to lookup trouble

2015-05-05 Thread Django

#24497: Truncation of microseconds in DateTimeField leads to lookup trouble
-+-
 Reporter:  riklaunim|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  microseconds | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

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

Re: [Django] #24648: Model fields that reference settings that differ between dev and prod trigger the autodetector

2015-05-05 Thread Django

#24648: Model fields that reference settings that differ between dev and prod
trigger the autodetector
--+
 Reporter:  Xof   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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
--+

Comment (by timgraham):

 [https://github.com/django/django/pull/4605 PR] has been proposed to allow
 the `FileField` `storage` argument to take a callable in order to work
 around this issue. It doesn't seem ideal 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/061.936381460c43ff9ca846d978bd09dea5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24755: makemigrations --merge output is confusing when one head depends on another app

2015-05-05 Thread Django

#24755: makemigrations --merge output is confusing when one head depends on 
another
app
+
 Reporter:  carljm  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by timgraham):

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

Re: [Django] #24754: Implementation of global permissions

2015-05-05 Thread Django

#24754: Implementation of global permissions
--+
 Reporter:  autrilla  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * version:  1.8 => master
 * 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.e66bfd65d7dac1cf0fa8452d3b35160c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24755: makemigrations --merge output is confusing when one head depends on another app (was: makemigrations --merge output is confusing when one head has a dependency to another app)

2015-05-05 Thread Django

#24755: makemigrations --merge output is confusing when one head depends on 
another
app
+--
 Reporter:  carljm  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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
+--

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

[Django] #24755: makemigrations --merge output is confusing when one head has a dependency to another app

2015-05-05 Thread Django

#24755: makemigrations --merge output is confusing when one head has a
dependency
to another app
--+
Reporter: carljm | Owner: nobody
Type: Bug | Status: new
Component: Migrations |Version: 1.8
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
--+
When you run `makemigrations --merge`, for every app with multiple 'head'
migrations, `makemigrations` lists each head and the operations present
only in its branch. So for instance, if we have an app X which has
migrations `X.0003_a` and `X.0003_b`, both of which depend on `X.0002`,
then `makemigrations --merge` will list the operations present in each of
the two migrations `X.0003_a` and `X.0003_b` so we can verify that they
don't conflict. So far, so good.

However, let's say we have another app Y, with migrations up to `Y.0004`,
and it so happens that `X.0003_b` depends on `Y.0004` (in addition to
depending on `X.0002`).

In this situation, `makemigrations --merge` includes every operation in
every migration of app `Y` in its list of operations that are part of the
`X.0003_b` branch. This is very confusing, as it makes that branch appear
much bigger than it actually is. Despite the dependency, the migrations in
app `Y` are not relevant to determining whether the merge is safe, because
in general it is an assumption of the migrations framework that migrations
in different apps do not conflict with one another (which is we allow one
"head" migration per app, not per project).

I think that `makemigrations --merge` should restrict its search for
operations in each branch to the current app only, and not display
operations from a different app.

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

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

Re: [Django] #24754: Implementation of global permissions

2015-05-05 Thread Django

#24754: Implementation of global permissions
--+--
 Reporter:  autrilla  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.8
 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 aaugustin):

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


Comment:

 Permissions were designed for the admin. It shows. I agree that it's an
 unfortunate design and we should try to do better. I've faced this issue
 repeatedly myself. In applications, not every concept is built upon a
 Django model!

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

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

[Django] #24754: Implementation of global permissions

2015-05-05 Thread Django

#24754: Implementation of global permissions
--+
Reporter: autrilla | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth |Version: 1.8
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+
Right now, there are two ways of creating Permissions, either through a
Model's Meta class, or using the Permission.objects.create method. The
problem is, both of this ways require having the permission attached to a
model, even when sometimes it does not really make sense. There are ways
to work around this, of course, such as creating a dummy model just to
hold permissions that don't really fit anywhere or overriding the default
User model and fitting them there. Possible solutions I can think of are
either removing the mandatory ContentType specification on the Permission
model or providing a 'global' ContentType.

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

Re: [Django] #24708: forms.GenericIPAddressField.to_python behaves differently to other CharField subclasses.

2015-05-05 Thread Django

#24708: forms.GenericIPAddressField.to_python behaves differently to other
CharField subclasses.
---+-
 Reporter:  kezabelle  |Owner:  Pradeek
 Type:  Bug|   Status:  assigned
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Ready for checkin
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by timgraham):

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


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

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

Re: [Django] #24207: Change ogrinspect multi_geom default to True

2015-05-05 Thread Django

#24207: Change ogrinspect multi_geom default to True
-+-
 Reporter:  mdiener21|Owner:  mdiener21
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  GIS  |  Version:  1.8alpha1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  gis, multi_geom  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Do you have an example of such a "deficient" layer? It would be nice to
 make a test case for 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.459f13345d04de260257e45ed3aafc34%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24156: inherited manytomany.all() empty when 2 or more inherited model from abstract one

2015-05-05 Thread Django

#24156: inherited manytomany.all() empty when 2 or more inherited model from
abstract one
-+-
 Reporter:  Pawamoy  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  inherit asbtract | Triage Stage:  Accepted
  manytomanys|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by coldmind):

 * version:  1.7 => master


Comment:

 I faced with this issue too.

 My example:



 {{{
 class ModelA(models.Model):
 field1 = models.TextField(blank=True)


 class AbstrMdl(models.Model):
 class Meta:
 abstract = True

 field1 = models.ManyToManyField('ModelA', related_name='+')


 class ModelB(AbstrMdl):
 field2 = models.TextField(blank=True)


 class ModelC(AbstrMdl):
 field2 = models.TextField(blank=True)


 ---


 In [1]: from myapp.models import ModelA, ModelB

 In [2]: a = ModelA.objects.create(field1='bla bla')

 In [3]: b = ModelB.objects.create()

 In [4]: b.field1.all()
 Out[4]: []

 In [5]: b.field1.add(a)

 In [6]: b.field1.all()
 Out[6]: []

 }}}

 Data is saving to database, but queryset is empty because it is filtered
 by something like `+__in=`.

 Investigation showed me that problem is near
 `django.db.models.fields.related.RelatedField#related_query_name`.
 For example this diff fixed my issue, but some tests are failing, so I
 will investigate deeper.

 {{{
 diff --git a/django/db/models/fields/related.py
 b/django/db/models/fields/related.py
 index 4569037..345a83c 100644
 --- a/django/db/models/fields/related.py
 +++ b/django/db/models/fields/related.py
 @@ -371,7 +371,10 @@ class RelatedField(Field):
  Define the name that can be used to identify this related object
 in a
  table-spanning query.
  """
 -return self.remote_field.related_query_name or
 self.remote_field.related_name or self.opts.model_name
 +if self.remote_field.is_hidden():
 +return self.remote_field.related_query_name or
 self.opts.model_name
 +else:
 +return self.remote_field.related_query_name or
 self.remote_field.related_name or self.opts.model_name

 }}}

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

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

Re: [Django] #24156: inherited manytomany.all() empty when 2 or more inherited model from abstract one

2015-05-05 Thread Django

#24156: inherited manytomany.all() empty when 2 or more inherited model from
abstract one
-+-
 Reporter:  Pawamoy  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  inherit asbtract | Triage Stage:  Accepted
  manytomanys|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by coldmind):

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

Re: [Django] #21803: Support post-commit hooks

2015-05-05 Thread Django

#21803: Support post-commit hooks
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #21357: Test client session does not behave as stated in the django documentation.

2015-05-05 Thread Django

#21357: Test client session does not behave as stated in the django 
documentation.
---+
 Reporter:  aaronmerriam@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"d42cbde0c602dad97bb452280baa4a4c7a056bf4" d42cbde0]:
 {{{
 #!CommitTicketReference repository=""
 revision="d42cbde0c602dad97bb452280baa4a4c7a056bf4"
 [1.7.x] Refs #21357 -- Added a working session example to the docs.
 }}}

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

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

Re: [Django] #24564: Can't use AbstractBaseUser without installing django.contrib.auth

2015-05-05 Thread Django

#24564: Can't use AbstractBaseUser without installing django.contrib.auth
-+-
 Reporter:  dcwatson |Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  new => closed
 * owner:   => Tim Graham 
 * resolution:   => fixed


Comment:

 In [changeset:"fe914341c83b37fd6aa8fd85620cf49dd2328ab0" fe914341]:
 {{{
 #!CommitTicketReference repository=""
 revision="fe914341c83b37fd6aa8fd85620cf49dd2328ab0"
 Fixed #24564 -- Moved AbstractBaseUser and BaseUserManager so they can be
 used without auth in INSTALLED_APPS
 }}}

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

Re: [Django] #24752: Reusing a Case/Where object in a query causes a crash

2015-05-05 Thread Django

#24752: Reusing a Case/Where object in a query causes a crash
-+-
 Reporter:  mssnlayam|Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
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:"5b5858575c96719d928b0df03e6aff272f849e44" 5b585857]:
 {{{
 #!CommitTicketReference repository=""
 revision="5b5858575c96719d928b0df03e6aff272f849e44"
 [1.8.x] Fixed #24752 -- query crash when reusing Case expressions

 Case expressions weren't copied deep enough (self.cases list was
 reused resulting in an error).

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

Re: [Django] #24752: Reusing a Case/Where object in a query causes a crash

2015-05-05 Thread Django

#24752: Reusing a Case/Where object in a query causes a crash
-+-
 Reporter:  mssnlayam|Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"7b05d2fdaed582662d8f79130932f600f4f966a0" 7b05d2fd]:
 {{{
 #!CommitTicketReference repository=""
 revision="7b05d2fdaed582662d8f79130932f600f4f966a0"
 Fixed #24752 -- query crash when reusing Case expressions

 Case expressions weren't copied deep enough (self.cases list was
 reused resulting in an error).
 }}}

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

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

Re: [Django] #24751: hstore isnull lookup fails

2015-05-05 Thread Django

#24751: hstore isnull lookup fails
--+
 Reporter:  mrAdm |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.8
 Severity:  Release blocker   |   Resolution:
 Keywords:  hstore| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by jarshwah):

 Is there any reason these hstore lookups couldn't always be wrapped in
 brackets (assuming this fixes the isnull problem)? We do a similar thing
 with F-combinables already:
 
https://github.com/django/django/blob/9096e2b5f75abf8e8882937bd3c3d47ccdc24e25/django/db/models/expressions.py#L391-L392

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

Re: [Django] #24744: hstore lookup fails inside subquery

2015-05-05 Thread Django

Comment (by jarshwah):

> Any ideas how we could automate testing of expression-likes so that we
automatically check relabeled_clone() support?

I've had similar thoughts about when we introduce a new field. What are
all the tests that should be written? I've got two ideas. The first would
be a test code generator. The better idea would be a test case builder.
I'm not sure how feasible either would be though.

So far the "gold standard" for expression tests is in expressions_case. If
we can generalise the tests there enough (or copy elsewhere then
generalise), we might be able to create a list of expressions, and pass
each one into the generalised test case to run through common failure
scenarios. Not sure if this is practical though, considering the inputs
and outputs to each expression can be wildly different.

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

Re: [Django] #24120: Backend-agnostic debug information on template loading failures

2015-05-05 Thread Django

#24120: Backend-agnostic debug information on template loading failures
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  multiple-template-   | Triage Stage:  Ready for
  engines|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24119: Backend-agnostic tracebacks on template rendering errors

2015-05-05 Thread Django

#24119: Backend-agnostic tracebacks on template rendering errors
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  multiple-template-   | Triage Stage:  Ready for
  engines|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

Re: [Django] #24733: Pass exceptions to error handlers

2015-05-05 Thread Django

#24733: Pass exceptions to error handlers
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  master
 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 timgraham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24736: Document how to customize the 50000 item limit in sitemaps

2015-05-05 Thread Django

#24736: Document how to customize the 5 item limit in sitemaps
--+
 Reporter:  Miserlou  |Owner:  abhaga
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  sitemap   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"eb00b427fc9d12c8ba53ce3875d7e481cd825e38" eb00b427]:
 {{{
 #!CommitTicketReference repository=""
 revision="eb00b427fc9d12c8ba53ce3875d7e481cd825e38"
 [1.8.x] Fixed #24736 -- Documented the Sitemap.limit attribute

 Backport of 9096e2b5f75abf8e8882937bd3c3d47ccdc24e25 from master
 }}}

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

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

Re: [Django] #24736: Document how to customize the 50000 item limit in sitemaps

2015-05-05 Thread Django

#24736: Document how to customize the 5 item limit in sitemaps
--+
 Reporter:  Miserlou  |Owner:  abhaga
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  sitemap   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"9096e2b5f75abf8e8882937bd3c3d47ccdc24e25" 9096e2b]:
 {{{
 #!CommitTicketReference repository=""
 revision="9096e2b5f75abf8e8882937bd3c3d47ccdc24e25"
 Fixed #24736 -- Documented the Sitemap.limit attribute
 }}}

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

Re: [Django] #24748: GROUP BY clause incorrect with foreign key to self in MySQL

2015-05-05 Thread Django

#24748: GROUP BY clause incorrect with foreign key to self in MySQL
-+-
 Reporter:  sparkyb  |Owner:  akaariai
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  annotate mysql   | 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 charettes):

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


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

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

Re: [Django] #24564: Can't use AbstractBaseUser without installing django.contrib.auth

2015-05-05 Thread Django

#24564: Can't use AbstractBaseUser without installing django.contrib.auth
--+
 Reporter:  dcwatson  |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_docs:  1 => 0


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

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

Re: [Django] #24739: Undocumented i18n behavior change in 1.8 (or a regression)

2015-05-05 Thread Django

#24739: Undocumented i18n behavior change in 1.8 (or a regression)
--+
 Reporter:  drakkan   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.8
 Severity:  Release blocker   |   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 drakkan):

 New behaviour:

 - if a string is not translated for a locale django use the translated
 string (if any) from the default locale

 Old behaviour:

 - if a string is not translated for a locale django use the untranslated
 string for the some locale

 what is most correct is an opinion, I like the old behaviour since all
 untraslated string should be the same,

 your opinion could be that an untranslated string should show the value
 for the default locale and not the untranslated one

 however is easy enouth to use a tool like poedit to copy all the
 translations from the original string, so if you like more the new
 behaviour is just a matter to document 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/065.6071b7402deb733a904a063b17477a16%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22948: Django 1.6, Python3.4, apache2.4, mod_wsgi not working

2015-05-05 Thread Django

#22948: Django 1.6, Python3.4, apache2.4, mod_wsgi not working
-+-
 Reporter:  tom@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Python 3 |  Version:  1.6
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  python3, apache2,| Triage Stage:
  mod_wsgi   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by JanMalte):

 Replying to [comment:1 anonymous]:
 > I just fixed this issue:
 >
 > adding
 >
 > {{{
 > WSGIApplicationGroup %{GLOBAL}
 > }}}
 >
 > to the apache2 configuration fixed it.
 >
 I have to decline. This doesn't fixed it for me. Only upgrading the wsgi
 package or performing an release upgrade seemed to fix 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/074.dbc8576f1e57c77b6118e72b99f9931a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22948: Django 1.6, Python3.4, apache2.4, mod_wsgi not working

2015-05-05 Thread Django

#22948: Django 1.6, Python3.4, apache2.4, mod_wsgi not working
-+-
 Reporter:  tom@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Python 3 |  Version:  1.6
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  python3, apache2,| Triage Stage:
  mod_wsgi   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by JanMalte):

 Further information:
 http://askubuntu.com/a/569551
 https://bugs.launchpad.net/ubuntu/+source/mod-wsgi/+bug/1451807

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

Re: [Django] #24753: Reverse FK conditions filter queryset when used in case statements in some cases

2015-05-05 Thread Django

#24753: Reverse FK conditions filter queryset when used in case statements in 
some
cases
-+-
 Reporter:  mdentremont  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * severity:  Normal => Release blocker
 * 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/069.52d2ca970f3590a4ecc01013ebdf6fcb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24745: Django 1.8+ Migrations Hold Onto Way More Memory

2015-05-05 Thread Django

#24745: Django 1.8+ Migrations Hold Onto Way More Memory
--+
 Reporter:  jpulec|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * type:  Bug => Cleanup/optimization
 * 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/064.d53ef89992f7b66eea75b32128b5cbc5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24749: contribute_to_class(virtual_field=True) is ignored

2015-05-05 Thread Django

#24749: contribute_to_class(virtual_field=True) is ignored
-+-
 Reporter:  hampsterx|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

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

Re: [Django] #24751: hstore isnull lookup fails

2015-05-05 Thread Django

#24751: hstore isnull lookup fails
--+
 Reporter:  mrAdm |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.8
 Severity:  Release blocker   |   Resolution:
 Keywords:  hstore| 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):

 * Attachment "24751-test.diff" added.


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

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

Re: [Django] #24751: hstore isnull lookup fails

2015-05-05 Thread Django

#24751: hstore isnull lookup fails
--+
 Reporter:  mrAdm |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.8
 Severity:  Release blocker   |   Resolution:
 Keywords:  hstore| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Attaching a failing test.

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

Re: [Django] #24753: Reverse FK conditions filter queryset when used in case statements in some cases

2015-05-05 Thread Django

#24753: Reverse FK conditions filter queryset when used in case statements in 
some
cases
-+-
 Reporter:  mdentremont  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 I have a guess what could be happening here.  The ORM generates joins as
 INNER JOINs when using build_filter(). We should manually promote those
 joins to OUTER JOINs afterwards. Can't work on this today, so I'll check
 this tomorrow.

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

Re: [Django] #24753: Reverse FK conditions filter queryset when used in case statements in some cases

2015-05-05 Thread Django

#24753: Reverse FK conditions filter queryset when used in case statements in 
some
cases
-+-
 Reporter:  mdentremont  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mdentremont):

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


Comment:

 I've added a unit test which demonstrates the issue here:
 https://github.com/django/django/pull/4613

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

[Django] #24753: Reverse FK conditions filter queryset when used in case statements in some cases

2015-05-05 Thread Django

#24753: Reverse FK conditions filter queryset when used in case statements in
some
cases
--+
Reporter: mdentremont | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) |Version: 1.8
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+
I'm running into some odd behaviour with the new conditional support added
in 1.8.

My use case is the following:

- Annotate a queryset with the count of reverse FKs, matching a condition

This works fine given a many-to-one relationship, however not with many-
to-one/none.

With the many-to-one/none, it appears an INNER JOIN is made, which removes
objects from my queryset which an empty reverse FK set.

To summarize:

Expected:
Annotate all objects with the a count of reverse FKs matching a condition

Actual:
Annotate only objects objects with 1 or more associated reverse FKs, with
a count of the reverse FKs matching a condition

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

Re: [Django] #24752: Reusing a Case/Where object in a query causes a crash

2015-05-05 Thread Django

#24752: Reusing a Case/Where object in a query causes a crash
-+-
 Reporter:  mssnlayam|Owner:  akaariai
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Accepted => Ready for checkin


Comment:

 Shameless self-review.

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

Re: [Django] #24207: Change ogrinspect multi_geom default to True

2015-05-05 Thread Django

Comment (by mdiener21):

Replying to [comment:5 claudep]:
> I'm not convinced to force multi geometries by default. If you obtain
errors when importing data from a shapefile because of a missing multi
field, you can always improve your model and force the multi geometries in
a later time. And if you don't want to risk the potential errors, there is
the `multi_geom` parameter you can set yourself.
>
> Feel free to add more arguments if you think I missed the point.

Please check out my comment :) cheers

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

Re: [Django] #24207: Change ogrinspect multi_geom default to True

2015-05-05 Thread Django

#24207: Change ogrinspect multi_geom default to True
-+-
 Reporter:  mdiener21|Owner:  mdiener21
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  GIS  |  Version:  1.8alpha1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  gis, multi_geom  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mdiener21):

 Hi the problem is this code if multi_geom and gtype.num in (1, 2, 3):
 LINE 213   gtype.num in (1,2,3)   does NOT always return TRUE for
 multi_geom because GDAL does not always guess correct.  Therefore if I set
 multi_geom to True it still fails because GDAL guesses wrong.  Another
 solution is to simply remove the GDAL check ?   any thoughts

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

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

Re: [Django] #24752: Reusing a Case/Where object in a query causes a crash

2015-05-05 Thread Django

#24752: Reusing a Case/Where object in a query causes a crash
-+-
 Reporter:  mssnlayam|Owner:  akaariai
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => akaariai
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #24750: Doc url in init geos

2015-05-05 Thread Django

#24750: Doc url in __init__ geos
--+
 Reporter:  felixxm   |Owner:  niconoe
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  GIS   |  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:  1 |UI/UX:  0
--+

Comment (by claudep):

 Note there is another one in django/contrib/gis/utils/layermapping.py

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

[Django] #24752: Reusing a Case/Where object in a query causes a crash

2015-05-05 Thread Django

#24752: Reusing a Case/Where object in a query causes a crash
--+
 Reporter:  mssnlayam |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Reusing a conditional expression `Case / When` that has already been used
 causes a crash. Here is a simple example:

 {{{#!python
 import django
 django.setup()

 from django.contrib.auth.models import User
 from django.db.models import When, Case, CharField, Value

 SOME_CASE = Case(
 When(pk=0, then=Value('0')),
 default=Value('1'),
 output_field=CharField(),
 )

 print User.objects.annotate(somecase=SOME_CASE)
 print User.objects.annotate(somecase=SOME_CASE)
 }}}

 You can safely execute this program in your environment. The second
 queryset crashes because it reuses the `SOME_CASE` object.

 This probably related to #24420. This problem exists in both 1.8 and
 1.8.1.

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

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

Re: [Django] #24750: Doc url in init geos

2015-05-05 Thread Django

#24750: Doc url in __init__ geos
--+
 Reporter:  felixxm   |Owner:  niconoe
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  GIS   |  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:  1 |UI/UX:  0
--+
Changes (by niconoe):

 * owner:  nobody => niconoe
 * cc: nicolas@… (added)
 * 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/065.16a8feb94709c57b01c8bdd69873ab60%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24751: hstore isnull lookup fails

2015-05-05 Thread Django

#24751: hstore isnull lookup fails
--+
 Reporter:  mrAdm |  Owner:
 Type:  Bug   | Status:  new
Component:  contrib.postgres  |Version:  1.8
 Severity:  Release blocker   |   Keywords:  hstore
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 {{{
 from django.db import models
 from django.contrib.postgres.fields import HStoreField


 class HStoreModel(Model):
 hstore_field = HStoreField()
 }}}
 Execute the query:
 {{{
 HStoreModel.objects.create(hstore_field={'a': None})
 HStoreModel.objects.filter(hstore_field__a__isnull=True)
 # or non existing key
 HStoreModel.objects.filter(hstore_field__b__isnull=True)
 }}}
 Exception:
 {{{
 Traceback (most recent call last):
   File "/vagrant/manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/management/__init__.py", line 338, in
 execute_from_command_line
 utility.execute()
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/management/__init__.py", line 312, in execute
 django.setup()
   File "/usr/local/lib/python2.7/dist-packages/django/__init__.py", line
 18, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/usr/local/lib/python2.7/dist-packages/django/apps/registry.py",
 line 115, in populate
 app_config.ready()
   File "/vagrant/st/apps.py", line 12, in ready
 print HStoreModel.objects.filter(hstore_field__a__isnull=True)
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
 line 138, in __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
 line 162, in __iter__
 self._fetch_all()
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
 line 965, in _fetch_all
 self._result_cache = list(self.iterator())
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
 line 238, in iterator
 results = compiler.execute_sql()
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/sql/compiler.py", line 829, in execute_sql
 cursor.execute(sql, params)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/backends/utils.py", line 79, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line
 97, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: operator does not exist: hstore ->
 boolean
 LINE 1: ...storemodel" WHERE "st_hstoremodel"."hstore_field" -> 'a' IS ...
  ^
 HINT:  No operator matches the given name and argument type(s). You might
 need to add explicit type casts.
 }}}
 Wrong SQL syntax?:
 {{{
 WHERE "st_hstoremodel"."hstore_field" -> 'b' IS NULL
 }}}
 Maybe you need this:
 {{{
 WHERE ("st_hstoremodel"."hstore_field" -> 'b') IS NULL
 }}}

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

Re: [Django] #24733: Pass exceptions to error handlers

2015-05-05 Thread Django

#24733: Pass exceptions to error handlers
---+
 Reporter:  claudep|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  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 Claude Paroz ):

 In [changeset:"69125ce90453f94c92432be1ab67768db514c82d" 69125ce9]:
 {{{
 #!CommitTicketReference repository=""
 revision="69125ce90453f94c92432be1ab67768db514c82d"
 Extended variable name in handlers/base.py

 Refs #24733.
 }}}

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

Re: [Django] #21357: Test client session does not behave as stated in the django documentation.

2015-05-05 Thread Django

#21357: Test client session does not behave as stated in the django 
documentation.
---+
 Reporter:  aaronmerriam@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by sbaechler):

 The fix has only been added to the 1.8 branch. In Django 1.7 the behavior
 is still not the same as stated in the documentation.
 https://docs.djangoproject.com/en/1.7/topics/testing/tools/#persistent-
 state

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

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

47 matches

Mail list logo