date:20170914

Re: [Django] #28594: Value error on related user name during save of user model

2017-09-14 Thread Django

* needs_better_patch: 0 => 1
* has_patch: 0 => 1
* needs_docs: 0 => 1
* stage: Unreviewed => Accepted

Comment:

At the very least this should use `six.string_types` on 1.x branches. But
I think this is a documentation issue. If you change the type of the
username field, then you should reimplement normalize_username or prevent
it being called.
However, Django's documentation says:

:attr:`USERNAME_FIELD` now supports
:class:`~django.db.models.ForeignKey`\s. Since there is no way to
pass
model instances during the :djadmin:`createsuperuser` prompt,
expect the
user to enter the value of
:attr:`~django.db.models.ForeignKey.to_field`
value (the :attr:`~django.db.models.Field.primary_key` by default)
of an
existing instance.

The current behavior of `clean()` and `UserManager._create_user()` does
not support foreign keys as it should expect to be handed model instances
and not call `normalize_username` or as the patch suggests,
`normalize_username` should only act on 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/061.09719b1beeaf2b76f24513cd395becf6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28344: Add for_update parameter to Model.refresh_from_db()

2017-09-14 Thread Django

#28344: Add for_update parameter to Model.refresh_from_db()
-+-
 Reporter:  Patryk Zawadzki  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hugo Osvaldo Barrera):

 If the transaction is written as I did in my example, you don't need to
 call `refresh_from_db`, since you only ever keep the reference to one
 loaded instance.

 I guess that saving when exiting the context manager would solve any
 doubts.

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

[Django] #28599: Case/When seems to ungroup the results of a values().annotate() query

2017-09-14 Thread Django

#28599: Case/When seems to ungroup the results of a values().annotate() query
-+-
   Reporter:  epalm  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I've been reading
 https://docs.djangoproject.com/en/1.11/topics/db/aggregation/ and
 https://docs.djangoproject.com/en/1.11/ref/models/conditional-expressions/
 and I can't tell if this is a bug, or if I'm just using annotate()
 incorrectly, but I've asked on
 [https://stackoverflow.com/questions/45802068 StackOverflow],
 [https://groups.google.com/forum/#!topic/django-users/Q276DNBY5vc django-
 users] and #django on freenode, and so far no one seems to have any
 suggestions.

 Let's say I have an Order model, and I want a payment breakdown grouped by
 user.

 Here's the Order model:

 {{{
 class Order(models.Model):
 CASH = 'c'
 CARD = 'a'
 PAYMENT_TYPES = (
 (CASH, 'Cash'),
 (CARD, 'Card'),
 )
 user = models.ForeignKey(User, on_delete=models.PROTECT,
 null=True, blank=True)
 payment_type = models.CharField(max_length=1,
 choices=PAYMENT_TYPES)
 grand_total = models.DecimalField(max_digits=8, decimal_places=2)
 }}}

 Here's a values() + annotate() query showing me the total per user:

 {{{
 query = Order.objects.values(
 'user'
 ).annotate(
 total=Sum('grand_total'),
 )
 }}}

 The result, so far so good:

 {{{
 User Total
 --
 User 1   300
 User 2   250
 }}}

 However, when I add Case/When conditions to the query:

 {{{
 query = Order.objects.values(
 'user'
 ).annotate(
 cash=Case(When(payment_type=Order.CASH, then=Sum('grand_total')),
 default=Value(0)),
 card=Case(When(payment_type=Order.CARD, then=Sum('grand_total')),
 default=Value(0)),
 total=Sum('grand_total'),
 )
 }}}

 I get this result, which is not what I want:

 {{{
 User Cash  Card  Total
 --
 User 1   300   0 300
 User 2   200   0 200
 User 2   0 5050
 }}}

 Of course, this is what I want:

 {{{
 User Cash  Card  Total
 --
 User 1   300   0 300
 User 2   200   50250
 }}}

 Is the Case/When undoing the GROUP BY that values() is giving me?

 Note: The Order model doesn't have default ordering, but just in case,
 upon reading https://docs.djangoproject.com/en/1.11/topics/db/aggregation
 /#interaction-with-default-ordering-or-order-by when using values(), I've
 tried adding `.order_by()` and `.order_by('user')` to my query, which did
 not change the result.

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

Re: [Django] #20205: PositiveIntegerfield does not handle empty values well

2017-09-14 Thread Django

#20205: PositiveIntegerfield does not handle empty values well
-+-
 Reporter:  anonymous|Owner:  Amine
 |  Zyad
 Type:  Bug  |   Status:  assigned
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 Zach):

 * cc: Zach (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.023e8311a868587ff3778ac601e1edca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28598: Django ignores BCC in console and filebased EmailBackend

2017-09-14 Thread Django

we noticed during development that the bcc header line is not printed in
the console (and filebased since it inherits from console) EmailBackend
({{{django.core.mail.backends.{console|filebased}.EmailBackend}}}). It
seems like this issue has been reported before, e.g. in #18582, however
there was no specific solution. It looks like a design decision, however
there is no documentation (that I found) about it.

In my opinion, it would be nice to have the BCC line printed in those
backends. As the documentation says, those backends are not intended for
use in production, which makes it an ideal tool for development and
testing. However that requires that the backend behaves just as a regular
(smtp) backend would and display the email message exactly as it would
have been sent.

If you decide not to fix this, please add a note to the documentation to
help developers avoid a sleepless night because they really can't get BCC
to work in their mail function ;)

Best,
zngr

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

Re: [Django] #7777: DecimalField validation ignores infinity and nan

2017-09-14 Thread Django

#: DecimalField validation ignores infinity and nan
---+
 Reporter:  Farhan Ahmad   |Owner:  Farhan Ahmad
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Other)   |  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
---+

Comment (by Tim Graham):

 Please open a new ticket with steps to reproduce. The tests from the
 original fix are still present (see
 `tests/field_tests/test_decimalfield.py`) so it's most likely a different
 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/068.3e7b8addce20fc8ddafd3ac604a3ac85%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28597: Model.Meta.indexes : model has no field named 'id'

2017-09-14 Thread Django

#28597: Model.Meta.indexes : model has no field named 'id'
-+-
   Reporter:  Дилян  |  Owner:  nobody
  Палаузов   |
   Type:  Bug| Status:  new
  Component: |Version:  1.11
  Uncategorized  |
   Severity:  Normal |   Keywords:  Model.Meta.indexes
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This works:
 {{{
 class Z(models.Model)
   a = models.BooleanField()
   class Meta:
index_together = ['a', 'id']`
 }}}

 but this does not:
 {{{
   class Meta:
 indexes = [ models.Index(fields=['a', 'id']) ]
 }}}

 {{{

  File "d/models.py", line 589, in 
 class Z(models.Model):
   File "django/lib/python3.5/site-packages/django/db/models/base.py", line
 314, in __new__
 index.set_name_with_model(new_class)
   File "django/lib/python3.5/site-packages/django/db/models/indexes.py",
 line 105, in set_name_with_model
 column_names = [model._meta.get_field(field_name).column for
 field_name, order in self.fields_orders]
   File "django/lib/python3.5/site-packages/django/db/models/indexes.py",
 line 105, in 
 column_names = [model._meta.get_field(field_name).column for
 field_name, order in self.fields_orders]
   File "django/lib/python3.5/site-packages/django/db/models/options.py",
 line 611, in get_field
 "be available yet." % (self.object_name, field_name)
 django.core.exceptions.FieldDoesNotExist: Z has no field named 'id'. The
 app cache isn't ready yet, so if this is an auto-created related field, it
 won't be available yet.

 }}}

 Using 'pk' instead does not help.

 Providing, that "The newer indexes option provides more functionality than
 index_together. index_together may be deprecated in the future", how shall
 I deal with indexes=  including the 'id' ?

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

Re: [Django] #7777: DecimalField validation ignores infinity and nan

2017-09-14 Thread Django

#: DecimalField validation ignores infinity and nan
---+
 Reporter:  Farhan Ahmad   |Owner:  Farhan Ahmad
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Other)   |  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 Fabio Bonelli):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Looks like this is back in master:


 {{{
   File "/usr/local/lib/python3.5/dist-packages/django/db/models/base.py",
 line 1226, in full_clean
 self.clean_fields(exclude=exclude)
   File "/usr/local/lib/python3.5/dist-packages/django/db/models/base.py",
 line 1268, in clean_fields
 setattr(self, f.attname, f.clean(raw_value, self))
   File "/usr/local/lib/python3.5/dist-
 packages/django/db/models/fields/__init__.py", line 603, in clean
 self.run_validators(value)
   File "/usr/local/lib/python3.5/dist-
 packages/django/db/models/fields/__init__.py", line 555, in run_validators
 v(value)
   File "/usr/local/lib/python3.5/dist-packages/django/core/validators.py",
 line 421, in __call__
 decimals = abs(exponent)
 TypeError: bad operand type for abs(): 'str'
 }}}

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

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

Re: [Django] #28594: Value error on related user name during save of user model

2017-09-14 Thread Django

#28594: Value error on related user name during save of user model
-+-
 Reporter:  Axel Rau |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  Value error, user| Triage Stage:
  model, normalize_username  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Axel Rau):

 The attached trivial patch 28594.diff works for me with Django 1.11.4 on
 Python 3.5.3

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

Re: [Django] #28594: Value error on related user name during save of user model

2017-09-14 Thread Django

#28594: Value error on related user name during save of user model
-+-
 Reporter:  Axel Rau |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  Value error, user| Triage Stage:
  model, normalize_username  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Axel Rau):

 * Attachment "28594.diff" added.

 patch based on git 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/061.5c73be1f7daabe15291f3b79c5ed3455%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28596: Oracle 11.2 + large search related = boom in instance.delete()

2017-09-14 Thread Django

#28596: Oracle 11.2 + large search related = boom in instance.delete()
-+-
 Reporter:  Markus Stenberg  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  felixxm  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Markus Stenberg):

 Unfortunately I do not have test setup with Oracle 12 and that codebase
 (it takes awhile to reproduce as well).

 Django 2.0 code in affected parts is same, but maybe Oracle has fixed the
 bug; however, 500+kb single SQL query sounds like a bug to me to start
 with.

 (it leads to SELECT .. WHERE id IN .. list of 100k ids .. in the related
 gathering part of deletion.py.)

 This isn't technically regression as the Oracle 11.2 (at least) in
 question been broken always (we have encountered it now with both Django
 1.8 and Django 1.11.).

 I wrote ugly few-line monkeypatch that fixes the issue but I guess I have
 to live with that until we get to Oracle 12 (and hopefully fixed bug and
 Django 2.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.e73de2ec8346eeea3df5778066f36108%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28596: Oracle 11.2 + large search related = boom in instance.delete()

2017-09-14 Thread Django

#28596: Oracle 11.2 + large search related = boom in instance.delete()
-+-
 Reporter:  Markus Stenberg  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  felixxm  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * keywords:   => felixxm


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

Re: [Django] #28596: Oracle 11.2 + large search related = boom in instance.delete()

2017-09-14 Thread Django

#28596: Oracle 11.2 + large search related = boom in instance.delete()
-+-
 Reporter:  Markus Stenberg  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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
-+-

Old description:

> Given model B, which has foreign key to model A (and delete=CASCADE).
>
> If deleting A instance with 100k references from different B instances,
> Oracle closes connection and the Oracle worker dies to ORA-0600.
>
> Reason:
>  Django does search_related with id__in of 100k different ids. Oracle (at
> least 11.2) cannot handle it and blows up. (This is known by Oracle IIRC
> but not fixed at least not in 11.)
>
> Workaround:
>   provide bulk_batch_size with e.g. 5000 maximum number of items in a
> query.

New description:

 Given model B, which has foreign key to model A (and delete=CASCADE).

 If deleting A instance with 100k references from different B instances,
 Oracle closes connection and the Oracle worker dies to ORA-0600.

 Reason: Django does search_related with `id__in` of 100k different ids.
 Oracle (at least 11.2) cannot handle it and blows up. (This is known by
 Oracle IIRC but not fixed at least not in 11.)

 Workaround: provide `bulk_batch_size` with e.g. 5000 maximum number of
 items in a query.

--

Comment (by Tim Graham):

 Can you confirm if the issue affects the Django master branch with Oracle
 12? Django 2.0 (the master branch) drops support for Oracle 11.2. Unless
 this is a regression from previous Django releases, we won't fix the issue
 in Django 1.11.

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

[Django] #28596: Oracle 11.2 + large search related = boom in instance.delete()

2017-09-14 Thread Django

#28596: Oracle 11.2 + large search related = boom in instance.delete()
-+-
   Reporter:  Markus |  Owner:  nobody
  Stenberg   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Given model B, which has foreign key to model A (and delete=CASCADE).

 If deleting A instance with 100k references from different B instances,
 Oracle closes connection and the Oracle worker dies to ORA-0600.

 Reason:
  Django does search_related with id__in of 100k different ids. Oracle (at
 least 11.2) cannot handle it and blows up. (This is known by Oracle IIRC
 but not fixed at least not in 11.)

 Workaround:
   provide bulk_batch_size with e.g. 5000 maximum number of items in a
 query.

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

Re: [Django] #28587: All Generic Views are loosing args when you pass args and kwargs into urlpattern

2017-09-14 Thread Django

Comment (by Tim Graham):

Based on the documentation, I'm not sure if this is a bug. There's
[https://docs.djangoproject.com/en/dev/topics/http/urls/#the-matching-
grouping-algorithm a note] that says, "Here’s the algorithm the URLconf
parser follows, with respect to named groups vs. non-named groups in a
regular expression: If there are any named arguments, it will use those,
ignoring non-named arguments." which seems to be what's happening here.
The behavior isn't specific to generic views. If you use a function-based
view, you'll see the same thing.

I'm not sure the reason for that behavior and if changing it is feasible,
but it does seem unintuitive. On the other hand, is there a reason you
must mix args and kwargs in the URL pattern? Do you want to look into
writing a patch?

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

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

Re: [Django] #28587: All Generic Views are loosing args when you pass args and kwargs into urlpattern (was: ListView cleaning args when you pass args and kwargs into urlpattern)

2017-09-14 Thread Django

#28587: All Generic Views are loosing args when you pass args and kwargs into
urlpattern
-+-
 Reporter:  Adrian   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  ListView, CBV,   | Triage Stage:
  generic,   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adrian):

 * cc: Adrian (added)


Old description:

> When I have in my urlpatterns args and kwargs the ListView is loosing
> args (it's returning empty tuple)
>

> {{{
> url(r"^(\w+)/test1/(?P[0-9]+)/list/$", SamplesListView.as_view(),
> name='list_view'),
> }}}
>
> Simple code for my view:
>

> {{{
> class SamplesListView(ListView):
> model = Sample
> template_name = 'samples/samples_list.html'
>
> def get(self, request, project_name, *args, **kwargs):
> print("project_name", project_name)
> return super().get(self, request, project_name, *args, **kwargs)
> }}}
>

> It works ok when I pass only args or kwargs into url.

New description:

 When I have in my urlpatterns args and kwargs the ListView is loosing args
 (it's returning empty tuple)


 {{{
 url(r"^(\w+)/test1/(?P[0-9]+)/list/$", SamplesListView.as_view(),
 name='list_view'),
 }}}

 Simple code for my view:


 {{{
 class SamplesListView(ListView):
 model = Sample
 template_name = 'samples/samples_list.html'

 def get(self, request, project_name, *args, **kwargs):
 print("project_name", project_name)
 return super().get(self, request, project_name, *args, **kwargs)
 }}}


 It works ok when I pass only args or kwargs into url.

 THE PROBLEM occurs in ALL generic view (CreateView, UpdateView,
 DeleteVIew, ListView)

--

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

Re: [Django] #28594: Value error on related user name during save of user model

Re: [Django] #28344: Add for_update parameter to Model.refresh_from_db()

[Django] #28599: Case/When seems to ungroup the results of a values().annotate() query

Re: [Django] #20205: PositiveIntegerfield does not handle empty values well

[Django] #28598: Django ignores BCC in console and filebased EmailBackend

Re: [Django] #7777: DecimalField validation ignores infinity and nan

[Django] #28597: Model.Meta.indexes : model has no field named 'id'

Re: [Django] #7777: DecimalField validation ignores infinity and nan

Re: [Django] #28594: Value error on related user name during save of user model

Re: [Django] #28594: Value error on related user name during save of user model

Re: [Django] #28596: Oracle 11.2 + large search related = boom in instance.delete()

Re: [Django] #28596: Oracle 11.2 + large search related = boom in instance.delete()

Re: [Django] #28596: Oracle 11.2 + large search related = boom in instance.delete()

[Django] #28596: Oracle 11.2 + large search related = boom in instance.delete()

Re: [Django] #28587: All Generic Views are loosing args when you pass args and kwargs into urlpattern

Re: [Django] #28587: All Generic Views are loosing args when you pass args and kwargs into urlpattern (was: ListView cleaning args when you pass args and kwargs into urlpattern)

16 matches

Site Navigation

Mail list logo

Footer information