date:20160613

Re: [Django] #16893: negation of Q object returns the same thing

2016-06-13 Thread Django

#16893: negation of Q object returns the same thing
-+-
 Reporter:  morgy.wahl@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by morganwahl):

 To elaborate:

 In django.db.models or someplace like it:
 {{{
 Nope = Q(pk__isnull=True)
 }}}

 Then in other code:
 {{{
 from django.db.models import Nope
 qs.filter(Nope) == qs.none()
 qs.exclude(Nope) == qs.all()
 }}}

 That still uses my `pk__isnull=True` hack, but that might be fine.
 Alternatively, the `Q` class itself could add some kind of explicit
 support for this.

 I think these expressions should all be true: `Nope | Q() == Q()`, `Nope &
 Q() == Nope`, `~Nope == Q()`

 `Nope` isn't a great name, but it was the best I could do; `Null` is
 confusing with the SQL concept, `None` is taken, of course, and `Nothing`
 sounds like what `filter(Nope)` would ''return'', not what it's passed. Is
 there a better word for unmatchable criteria?

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

Re: [Django] #16893: negation of Q object returns the same thing

2016-06-13 Thread Django

#16893: negation of Q object returns the same thing
-+-
 Reporter:  morgy.wahl@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by morganwahl):

 Ah, I see. `filter()` == `all()` == `exclude()`, all of which != `none()`.
 Keeping `filter(~Q(...))` == `exclude(Q(...)))` certainly makes sense (if
 that's possible).

 Maybe define a special singleton instance of `Q` that matches nothing?

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

Re: [Django] #26754: Document django.template.context_processors.tz

2016-06-13 Thread Django

#26754: Document django.template.context_processors.tz
--+
 Reporter:  scop  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by scop):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #26223: Squashing migrations with preserve_default=False keeps the default

2016-06-13 Thread Django

Comment (by vytisb):

Here's an alternative approach.

`AddField.field` could be changed to mean the actual field that goes into
model state. The transient database default value would be a separate
attribute on the operation.
This would make code a bit cleaner because `default` handling would only
occur in `database_forwards` (where it already occurs).
For backwards compatibility, constructor would still accept
`preserve_default` and modify the field if needed.
`makemigrations` and `squashmigrations` would emit the operation with the
new signature.
If `preserve_default` is deprecated, we can suggest users to modify
existing migrations by hand or simply squash them.

Same goes for `AlterField`.

If this approach is worth considering, I could make another PR to see how
it looks.

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

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

Re: [Django] #26643: AlterModelManagers migration is generated for all Models with custom Managers pointing to the default Django Manager

2016-06-13 Thread Django

#26643: AlterModelManagers migration is generated for all Models with custom
Managers pointing to the default Django Manager
-+-
 Reporter:  cybojenix|Owner:  schinckel
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * keywords:  1.10 =>
 * version:  master => 1.10


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

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

Re: [Django] #26745: Add the ability to customize user creation in the createsuperuser command

2016-06-13 Thread Django

#26745: Add the ability to customize user creation in the createsuperuser 
command
--+--
 Reporter:  Lyra2108  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--

Comment (by Lyra2108):

 The main use case is to add permissions for the super user. Without the
 permissions the user isn't set up correctly and shouldn't be created.

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

Re: [Django] #26752: RenameModel requires camel case model names

2016-06-13 Thread Django

#26752: RenameModel requires camel case model names
+--
 Reporter:  npars   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.9
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by timgraham):

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


Comment:

 Probably the same cause as #23916.

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

Re: [Django] #23916: makemigrations does not detect/like model name case changes

2016-06-13 Thread Django

#23916: makemigrations does not detect/like model name case changes
+
 Reporter:  scoenye |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by timgraham):

 #26752 seems to be another symptom (closed as duplicate, but reopen if
 not).

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

Re: [Django] #26223: Squashing migrations with preserve_default=False keeps the default

2016-06-13 Thread Django

#26223: Squashing migrations with preserve_default=False keeps the default
+
 Reporter:  bartekwojcicki  |Owner:  vytisb
 Type:  Bug |   Status:  assigned
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
+
Changes (by vytisb):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/6772 PR]

 Went with `actual_field` instead of `real_field`.

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

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

Re: [Django] #26754: Document django.template.context_processors.tz

2016-06-13 Thread Django

#26754: Document django.template.context_processors.tz
--+
 Reporter:  scop  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

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

Re: [Django] #26644: SuspiciousFileOperation when creating a File from a NamedTemporaryFile

2016-06-13 Thread Django

#26644: SuspiciousFileOperation when creating a File from a NamedTemporaryFile
-+-
 Reporter:  hobarrera|Owner:  hobarrera
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  1.10
  uploads/storage|
 Severity:  Release blocker  |   Resolution:
 Keywords:  File,| Triage Stage:  Accepted
  SuspiciousFileOperation,   |
  NamedTemporaryFile, regression |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


Comment:

 [https://github.com/django/django/pull/6771 Updated PR]

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

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

Re: [Django] #26754: Document django.template.context_processors.tz

2016-06-13 Thread Django

#26754: Document django.template.context_processors.tz
---+--
 Reporter:  scop   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  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 scop):

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


Old description:



New description:

 PR: https://github.com/django/django/pull/6770

--

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

[Django] #26754: Document django.template.context_processors.tz

2016-06-13 Thread Django

#26754: Document django.template.context_processors.tz
---+
 Reporter:  scop   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
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/047.dc10e1515e4cc29dcd653b16b05a3d62%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26753: Make GDAL a hard dependency

2016-06-13 Thread Django

#26753: Make GDAL a hard dependency
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by timgraham):

 To ease running the test suite by casual contributors, I think it's worth
 continuing to allow running the Django test suite without GDAL installed.
 In that case, we could skip all `gis_tests` instead of selectively
 skipping tests in that package.

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

[Django] #26753: Make GDAL a hard dependency

2016-06-13 Thread Django

#26753: Make GDAL a hard dependency
+
   Reporter:  claudep   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  GIS   |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Read https://groups.google.com/forum/#!topic/geodjango/gD0-1SMOBqU

 This will allow us to simplify code in several places.

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

[Django] #26752: RenameModel requires camel case model names

2016-06-13 Thread Django

#26752: RenameModel requires camel case model names
+
 Reporter:  npars   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.9
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 The `migrations.RenameModel` class appears to accept all lowercase model
 names but when the `makemigrations` command is run afterwards it will
 generate an `AlterField` migration every time. This occurs when there
 exists a model that has a `ForeignKey` that relies on the renamed model.

 When the model names are changed to camel case the `makemigrations`
 command works as expected and no longer generates `AlterField` migrations.

 Migration that will cause the error case:
 {{{
 migrations.RenameModel(
 old_name='originalmodel',  # Note: Not using CamelCase!
 new_name='renamedmodel',
 ),
 }}}

 The generated migration in the error case:
 {{{
 migrations.AlterField(
 model_name='anothermodel',
 name='foreign_key_field',
 field=models.ForeignKey(on_delete=django.db.models.deletion.CASCADE,
 to='an_app.RenamedModel'),
 ),
 }}}

 This behaviour can be seen in this demo project: https://github.com/npars
 /django-bad-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/048.3366275b45ea7465be701d5eee98c1af%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16970: calling as_view of CBV in URLConf needs better documentation and examples

2016-06-13 Thread Django

#16970: calling as_view of CBV in URLConf needs better documentation and 
examples
---+
 Reporter:  pydanny|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  fixed
 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 bmispelon):

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


Comment:

 I believe this issue has been fixed. I tried the following:

 {{{#!python
 # models.py
 from django.db import models


 class CustomManager(models.Manager):
 def some_things(self):
 return self.all()[:3]


 class Thing(models.Model):
 objects = CustomManager()

 # urls.py
 from django.conf.urls import url
 from django.views.generic import ListView

 from .models import Thing

 urlpatterns = [
 url(
 regex=r'^$',
 view=ListView.as_view(
 queryset=Thing.objects.some_things(),
 template_name='things/some_things.html',
 ),
 name='some_things',
 ),
 ]

 # tests.py
 from django.test import TestCase, override_settings

 from .models import Thing

 @override_settings(ROOT_URLCONF='things.urls')
 class ListViewTests(TestCase):

 @classmethod
 def setUpTestData(cls):
 for _ in range(5):
 Thing.objects.create()

 def test_items(self):
 res = self.client.get('/')
 self.assertEqual(res.status_code, 200)
 self.assertTemplateUsed(res, 'things/some_things.html')
 self.assertEqual(len(res.context['object_list']), 3)
 }}}

 As noted in comment 4, there could be an issue that declaring the
 `queryset` at the module-level could make the object reused between
 successive calls to the view, but as noted in the documentation [1], the
 default implementation of `get_queryset` prevents that by systematically
 cloning the queryset object.


 I'm therefore closing this.

 [1] https://docs.djangoproject.com/en/1.9/ref/class-based-views/mixins-
 multiple-object/#django.views.generic.list.MultipleObjectMixin.queryset

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

Re: [Django] #26751: Make dbshell exit with the shell's error code

2016-06-13 Thread Django

#26751: Make dbshell exit with the shell's error code
-+-
 Reporter:  bersace  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bersace):

 You're rigth, it's quite hard to test execvp because by definition, this
 function never returns.

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

Re: [Django] #26751: Make dbshell exit with the shell's error code

2016-06-13 Thread Django

#26751: Make dbshell exit with the shell's error code
-+-
 Reporter:  bersace  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bersace):

 @timgraham, thanks for triaging :)

 I applied the fix to other backends. That's actually not a problem of
 backends but how runshell manage subprocess.

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

Re: [Django] #26657: MySQL 5.7 GIS test failures: InterfaceError: (-1, 'error totally whack')

2016-06-13 Thread Django

#26657: MySQL 5.7 GIS test failures: InterfaceError: (-1, 'error totally whack')
---+
 Reporter:  timgraham  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  Version:  1.9
 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 claudep):

 Sorry, no clue :-(

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

Re: [Django] #26751: Make dbshell exit with the shell's error code (was: dbshell error handling)

2016-06-13 Thread Django

#26751: Make dbshell exit with the shell's error code
-+-
 Reporter:  bersace  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell  | 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:   => 1
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Old description:

> Hi,
>
> The Django project made great improvements in batch mode for dbshell with
> password managment. That's a nice contribution !
>
> For scripting, commands should return a non zero exit-code on error. But
> `runshell` seems to miss to manage exit code. Here is how to reproduce:
>
> {{{
> #!console
> (venv) $ echo 'auieaui;' | django-admin dbshell
> ERROR:  syntax error at or near "auieaui"
> LINE 1: auieaui;
> ^
> (venv) $ echo $?
> 0
> }}}
>
> I suggested a fix in https://github.com/django/django/pull/6768 .
> @charettes asked me to open a ticket for discussion. Here your are :)
>
> Regards,
> Étienne

New description:

 For scripting, commands should return a non zero exit-code on error. But
 `dbshell` seems to ignore the exit code. Here is how to reproduce:

 {{{
 #!console
 (venv) $ echo 'auieaui;' | django-admin dbshell
 ERROR:  syntax error at or near "auieaui"
 LINE 1: auieaui;
 ^
 (venv) $ echo $?
 0
 }}}

 I suggested a fix in https://github.com/django/django/pull/6768 .
 @charettes asked me to open a ticket for discussion. Here your are :)

 Regards,
 Étienne

--

Comment:

 Is a similar fix applicable for the other database backends? Not sure if
 tests are feasible.

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

[Django] #26751: dbshell error handling

2016-06-13 Thread Django

#26751: dbshell error handling
+-
 Reporter:  bersace |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Core (Management commands)  |Version:  master
 Severity:  Normal  |   Keywords:  dbshell
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+-
 Hi,

 The Django project made great improvements in batch mode for dbshell with
 password managment. That's a nice contribution !

 For scripting, commands should return a non zero exit-code on error. But
 `runshell` seems to miss to manage exit code. Here is how to reproduce:

 {{{
 #!console
 (venv) $ echo 'auieaui;' | django-admin dbshell
 ERROR:  syntax error at or near "auieaui"
 LINE 1: auieaui;
 ^
 (venv) $ echo $?
 0
 }}}

 I suggested a fix in https://github.com/django/django/pull/6768 .
 @charettes asked me to open a ticket for discussion. Here your are :)

 Regards,
 Étienne

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

Re: [Django] #16893: negation of Q object returns the same thing

2016-06-13 Thread Django

#16893: negation of Q object returns the same thing
-+-
 Reporter:  morgy.wahl@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bmispelon):

 For reference, it seems that the current behavior is tested (if not
 documented):
 https://github.com/django/django/blob/master/tests/queries/tests.py#L1692-L1694

 Come to think of it, I'm not really sure how empty `Q` objects should be
 treated: what's the expected result of `filter(Q())`, `filter(~Q())`,
 `exclude(Q())`, or `exclude(~Q())`?

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

Re: [Django] #25645: Drop support for SpatiaLite < 4.0

2016-06-13 Thread Django

#25645: Drop support for SpatiaLite < 4.0
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  1.11 | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"cee534228cddd6d38a5773f32ad53cc8ec4b504d" cee5342]:
 {{{
 #!CommitTicketReference repository=""
 revision="cee534228cddd6d38a5773f32ad53cc8ec4b504d"
 Refs #25645 -- Removed SpatiaLite 3.x compatibility in
 gis.db.models.functions.Translate.

 Complements 47f22e828618581ecd4203d369a939fdfcff3a8b.
 }}}

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

Re: [Django] #26657: MySQL 5.7 GIS test failures: InterfaceError: (-1, 'error totally whack')

2016-06-13 Thread Django

#26657: MySQL 5.7 GIS test failures: InterfaceError: (-1, 'error totally whack')
---+
 Reporter:  timgraham  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  Version:  1.9
 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):

 * cc: claudep (added)


Comment:

 From the
 [https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-7.html#mysqld-5-7-7
 -spatial-support MySQL 5.7 release notes]:

  The `ST_Buffer()`, `ST_Difference()`, `ST_Distance()`,
 `ST_Intersection()`, `ST_IsSimple()`, `ST_SymDifference()`, and
 `ST_Union()` functions have been reimplemented to use the functionality
 available in `Boost.Geometry`. The functions may raise an exception for
 invalid geometry argument values when the previous implementation may not
 have.

 An example failing query from
 `gis_tests.geoapp.test_functions.GISFunctionsTests.test_union`:
 {{{ #!sql
 SELECT geoapp_city.id, geoapp_city.name,
 AsText(geoapp_city.point),
 AsText(ST_Union(geoapp_city.point, GeomFromText('POINT
 (-95.36315120 29.76337389)', 4326))) AS union
 FROM geoapp_city
 WHERE geoapp_city.name = 'Dallas'
 }}}

 A minimal query to reproduce is:
 {{{ #!sql
 SELECT ST_Union(geoapp_city.point, ST_GeomFromText('POINT (-95.3631510
 29.763373999)', 4326)) FROM geoapp_city
 }}}
 Any advice, Claude?

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

Re: [Django] #26750: Add new Field type for postgis POINTZ

2016-06-13 Thread Django

#26750: Add new Field type for postgis POINTZ
-+-
 Reporter:  saintbyte|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  inspectdb,gis,postgis  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * needs_docs:   => 0
 * needs_better_patch:   => 1
 * version:  1.9 => master
 * needs_tests:   => 1
 * stage:  Unreviewed => Accepted


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

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

[Django] #26750: Add new Field type for postgis POINTZ

2016-06-13 Thread Django

#26750: Add new Field type for postgis POINTZ
---+---
 Reporter:  saintbyte  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  GIS|Version:  1.9
 Severity:  Normal |   Keywords:  inspectdb,gis,postgis
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+---
 I create on RoR , models with type  "t.geography "location",
 limit: {:srid=>4326, :type=>"point", :has_z=>true, :geographic=>true}".
 And try make inspectdb in my django project , but ./manage.py inspectdb
 fails. It database its seem like "location geography(PointZ,4326)" .

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

Re: [Django] #26729: TabularInline not respecting form's custom label and help text if set in form's init method

2016-06-13 Thread Django

#26729: TabularInline not respecting form's custom label and help text if set in
form's __init__ method
---+
 Reporter:  nrogers64  |Owner:  czpython
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.9
 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 czpython):

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

Re: [Django] #26729: TabularInline not respecting form's custom label and help text if set in form's init method

2016-06-13 Thread Django

#26729: TabularInline not respecting form's custom label and help text if set in
form's __init__ method
---+
 Reporter:  nrogers64  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 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 czpython):

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

Re: [Django] #4136: Save empty, nullable CharField's as null rather than as an empty string

2016-06-13 Thread Django

#4136: Save empty, nullable CharField's as null rather than as an empty string
-+-
 Reporter:  David Cramer |Owner:  Tim
  |  Graham 
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"267dc4a2882182f71a7f285a06b1d4b15af0" 267dc4ad]:
 {{{
 #!CommitTicketReference repository=""
 revision="267dc4a2882182f71a7f285a06b1d4b15af0"
 Fixed #4136 -- Made ModelForm save empty values for nullable CharFields as
 NULL.

 Previously, empty values were saved as strings.
 }}}

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

Re: [Django] #4136: Save empty, nullable CharField's as null rather than as an empty string (was: Add a way to save null CharField's as null rather than an empty string)

2016-06-13 Thread Django

#4136: Save empty, nullable CharField's as null rather than as an empty string
-+-
 Reporter:  David Cramer |Owner:
  |
 Type:  New feature  |   Status:  new
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:  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/090.adaa15441d8275165b571c02b10fa7e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26729: TabularInline not respecting form's custom label and help text if set in form's init method

2016-06-13 Thread Django

#26729: TabularInline not respecting form's custom label and help text if set in
form's __init__ method
---+
 Reporter:  nrogers64  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 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 czpython):

 Looking at this a bit more, I saw we have access to the empty form
 instance using {{{formset.empty_form}}}.
 I feel much better about using that. Attached is the revised patch.

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

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

Re: [Django] #26656: Add timedelta support to DjangoJSONEncoder

2016-06-13 Thread Django

#26656: Add timedelta support to DjangoJSONEncoder
--+
 Reporter:  willhardy |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #26749: Different manager for _base_manager and related descriptors

2016-06-13 Thread Django

#26749: Different manager for _base_manager and related descriptors
-+-
 Reporter:  spectras |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  manager  | 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):

 * cc: loic (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

Re: [Django] #26748: Ease customizing the JSONField widget (was: Custom widget on JSONField in contrib.postgres: simplification)

2016-06-13 Thread Django

#26748: Ease customizing the JSONField widget
-+-
 Reporter:  meshy|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  contrib.postgres |  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:  1|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/063.e71d7543b113b2fa46d8afd7d2c0afdc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26748: Custom widget on JSONField in contrib.postgres: simplification

2016-06-13 Thread Django

#26748: Custom widget on JSONField in contrib.postgres: simplification
-+-
 Reporter:  meshy|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  contrib.postgres |  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:  1|UI/UX:  0
-+-

Comment (by timgraham):

 This will be in 1.11, see our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy] for details on the
 backport policy.

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

Re: [Django] #26748: Custom widget on JSONField in contrib.postgres: simplification

2016-06-13 Thread Django

#26748: Custom widget on JSONField in contrib.postgres: simplification
-+-
 Reporter:  meshy|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  contrib.postgres |  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:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f2c0eb19e961f5864573251e70bdcdecd0250aed" f2c0eb19]:
 {{{
 #!CommitTicketReference repository=""
 revision="f2c0eb19e961f5864573251e70bdcdecd0250aed"
 Fixed #26748 -- Allowed overriding JSONField's widget with an 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/063.042be5a35e7ebf935079b730f80c6f20%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26746: Accept-Language header parsing incorrectly transforms q=0 into q=1

2016-06-13 Thread Django

#26746: Accept-Language header parsing incorrectly transforms q=0 into q=1
--+
 Reporter:  vytisb|Owner:  vytisb
 Type:  Bug   |   Status:  closed
Component:  Internationalization  |  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:"57eb17b8c7d106c9a3264aa35b8dabb179a1e17b" 57eb17b]:
 {{{
 #!CommitTicketReference repository=""
 revision="57eb17b8c7d106c9a3264aa35b8dabb179a1e17b"
 Fixed #26746 -- Fixed handling of zero priority in Accept-Language header
 parsing.
 }}}

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

Re: [Django] #26729: TabularInline not respecting form's custom label and help text if set in form's init method

2016-06-13 Thread Django

#26729: TabularInline not respecting form's custom label and help text if set in
form's __init__ method
---+
 Reporter:  nrogers64  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 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 czpython):

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

Re: [Django] #26729: TabularInline not respecting form's custom label and help text if set in form's init method

2016-06-13 Thread Django

#26729: TabularInline not respecting form's custom label and help text if set in
form's __init__ method
---+
 Reporter:  nrogers64  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 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 czpython):

 Replying to [comment:3 timgraham]:
 > I'd agree with that analysis. Did you look into why it works for
 `StackedInline`.
 Yes, {{{StackedInline}}} does not need to get the field names prior to
 rendering the forms.
 Instead, it just renders each form instance individually and thus uses a
 {{{BoundField}}} instance when rendering each field and label.

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

[Django] #26749: Different manager for _base_manager and related descriptors

2016-06-13 Thread Django

#26749: Different manager for _base_manager and related descriptors
--+-
Reporter: spectras | Owner: nobody
Type: Uncategorized | Status: new
Component: Database layer (models, ORM) |Version: 1.10
Severity: Normal| Keywords: manager
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+-
I am in the process of testing Django 1.10 and upgrading the third-party
package I maintain, django-hvad.

This ticket is related to the two following commits:
* '''Streamlined manager inheritance.:'''

https://github.com/django/django/commit/3a47d42fa33012b2156bf04058d933df6b3082d2
* '''Introduced new APIs to specify models' default and base managers:'''

https://github.com/django/django/commit/ed0ff913c648b16c4471fc9a9441d1ee48cb5420

The issue I have with the way inheritance and customization now works is
it is very hard to have a different manager as the `base_manager` and the
one used for related field descriptors.

''Why the need?''

Django-hvad is one of the modules that change the default querysets. It
does it by replacing the default manager with one that brings extra
features. Namely, automatic joining onto a translations model.

Having those features available on related fields is essential to provide
a consistent interface, and after years of having it, it is now essential
to backward compatibility as well.

It does not break the basic rule of “a base manager must not hide
objects”, as it merely adds automatic `select_related()` rules and
`iterator()` encapsulation.

Yet, those extra features cannot be on the `base_manager`, due to the way
ORM internals use it (for instance, triggering additional joins on a
delete would not work).

''Why the ticket?''

Up to Django 1.9, this was possible using `use_for_related_fields = True`,
and fixing the `_base_manager` in the `class_prepared` hook. Not clean but
workable.

With the new API though, all the manager machinery uses property
descriptors on the `Options` class, making it difficult and fragile to
override. And at the same time, using `use_for_related_fields` got
deprecated, which means there is no option to use '''a different manager
as the base manager and as the related field descriptor's manager'''
anymore.

Unless there is another way to do 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/051.71fd66bb2f8e063f3e2e179180fd8e55%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

41 matches

Mail list logo