Re: [Django] #27303: Selecting multiple admin list_filters across relations return results that don't match both filters

[Django]

#27303: Selecting multiple admin list_filters across relations return results 
that
don't match both filters
---+
 Reporter:  Yeago  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  filterspec | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Connor Osborn):

 I filed a ticket [https://code.djangoproject.com/ticket/27388], for this
 same issue because Dango Rest Framework depended on the api of chaining
 filters as an AND. As Josh Smeaton pointed out chained filters are
 logically OR'd statements. I think this is so counter to intuition that it
 is reasonable to break backwards compatibility in an upcoming release. I
 think the current api is likely to cause more pain in the future than the
 pain that would be caused by breaking existing code. If a function gets
 passed a queryset it cannot assume that it can call filter and gather the
 results, because of the nature of OR, it will include more than desired if
 another filter had been previously applied. Perhaps most importantly,
 applying multiple joins for the purpose of ORing can lead to exponentially
 slow queries, because successive joins can have multiplicative factors on
 the number of rows. This was the original reason I filed the ticket, the
 successive joins resulted in a search of 1million rows for a table with
 originally several thousand.

 > I think I understand the point you're trying to make Steve. Do the docs
 here represent the different behaviours you're trying to put across?
 https://docs.djangoproject.com/en/1.10/topics/db/queries/#spanning-multi-
 valued-relationships
 >
 > Those docs primarily refer to multi-value relationships which I'm not
 certain is the use case you're trying to resolve. But to summarise:
 >
 > `.filter(multi__value__lookup=1, multi__value__other=2)` is equivalent
 to `(MVL=1 AND MVO=2)` because the WHERE clause targets a single join.
 >
 > {{{
 > SELECT * FROM model
 > JOIN multi ON model.multi_id = multi.id
 > JOIN value on multi.value_id = value.id
 > WHERE value.MVL=1 AND value.MVO = 2
 > }}}
 >
 > Where `.filter(multi__value__lookup=1).filter(multi__value__other=2)` is
 logically equivalent to `(MVL=1 OR MVO=2)` because MVL and MVO have
 separate joins, so they can both match independently since it's a
 multivalue relationship.
 >
 > {{{
 > SELECT * FROM model
 > JOIN multi ON model.multi_id = multi.id
 > JOIN value on multi.value_id = value.id
 > JOIN multi m2 ON model.multi_id = m2.id
 > JOIN value v2 on multi.value_id = v2.id
 > WHERE value.MVL=1 AND v2.MVO = 2
 > }}}
 >
 > Does this correctly summarise the behaviour?

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

Re: [Django] #27388: Filter chaining results in unnecessary joins (and degenerate performance)

[Django]

#27388: Filter chaining results in unnecessary joins (and degenerate 
performance)
-+-
 Reporter:  Connor Osborn|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  queryset, join,  | Triage Stage:
  performance|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 > It looks like if I set the filter_is_sticky flag it gets reset to false
 in the next filter. So in order to have a chain each one must be add that
 flag, is that right?

 Exactly but relying on Django's internal APIs is risky as it might be
 replaced in future versions.

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

Re: [Django] #27388: Filter chaining results in unnecessary joins (and degenerate performance)

[Django]

#27388: Filter chaining results in unnecessary joins (and degenerate 
performance)
-+-
 Reporter:  Connor Osborn|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  queryset, join,  | Triage Stage:
  performance|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Connor Osborn):

 That's pretty surprising to me, thanks for linking me to the docs. I'm
 still interested in finding a solution for my application. It looks like
 if I set the `filter_is_sticky` flag it gets reset to false in the next
 filter. So in order to have a chain each one must be add that flag, is
 that right?

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

Re: [Django] #27388: Filter chaining results in unnecessary joins (and degenerate performance)

[Django]

#27388: Filter chaining results in unnecessary joins (and degenerate 
performance)
-+-
 Reporter:  Connor Osborn|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  queryset, join,  | Triage Stage:
  performance|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 > I think the correct way forward is to make those two queries that are
 logically equivalent produce the same sql.

 Unfortunately this would be backward incompatible as this is
 [https://docs.djangoproject.com/en/1.10/topics/db/queries/#spanning-multi-
 valued-relationships a documented feature].

 I recently suggested [https://groups.google.com/d/msg/django-
 developers/dpL5z1yOe58/msQTmGwMCAAJ adding an API] to allow alias reusing
 in a specific context. I suspect your use case is similar to the one
 reported in #27343 but related to DRF instead of the admin.

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

Re: [Django] #26988: User is_authenticated callable property is confusing to check

[Django]

#26988: User is_authenticated callable property is confusing to check
-+-
 Reporter:  Mark Tranchant   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  user | Triage Stage:  Accepted
  is_authenticated property test |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by WeizhongTu):

 I think it's better to add a remark to the code, because someone only read
 the code


 {{{
 if request.user.is_authenticated is True:  # won't work
 ...
 }}}

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

[Django] #27388: Filter chaining results in unnecessary joins (and degenerate performance)

[Django]

#27388: Filter chaining results in unnecessary joins (and degenerate 
performance)
-+-
 Reporter:  Connor Osborn|  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Database layer   |Version:  1.9
  (models, ORM)  |   Keywords:  queryset, join,
 Severity:  Normal   |  performance
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 I found that  `filter(testA).filter(testB)` produced very different sql
 than `filter(testA & testB)`.

 For my application I did a small test to reproduce this. In the example
 linked I print the sql formatted. The chained filters produce many
 unnecessary joins.
 https://gist.github.com/cdosborn/cb4bdfd0467feaf987476f4aefdf7ee5

 The joins are created in the first place because of the foreign key
 `tags__name` requires a join with a Tags table.

 The popular ''django rest framework'' library provides a search mechanism
 that uses chained filters in django. Our application used that library and
 experienced an incredible slowdown. The many unnecessary joins resulted in
 a massive table (more than 1 million rows) when the original Application
 table had only 1000 rows.

 I think the correct way forward is to make those two queries that are
 logically equivalent produce the same sql. I have done some digging in the
 code base and found a patch that fixes the sql but is **not** a proper fix
 (printed below). I'm willing to take up the work to fix this properly, but
 I will probably need some assistance.

 There is only one use case for `filter_is_sticky` (located in model code)
 and it looks like a hack. If you look at the commit that introduced it, it
 was actually trying to solve my problem: unnecessary joins. So I'm
 guessing a proper fix would remove that.

 {{{
 diff --git a/django/db/models/sql/query.py b/django/db/models/sql/query.py
 index f82eca3..b54a8e5 100644
 --- a/django/db/models/sql/query.py
 +++ b/django/db/models/sql/query.py
 @@ -314,10 +314,7 @@ class Query(object):
  obj.extra_tables = self.extra_tables
  obj.extra_order_by = self.extra_order_by
  obj.deferred_loading = copy.copy(self.deferred_loading[0]),
 self.deferred_loading[1]
 -if self.filter_is_sticky and self.used_aliases:
 -obj.used_aliases = self.used_aliases.copy()
 -else:
 -obj.used_aliases = set()
 +obj.used_aliases = self.used_aliases.copy()
  obj.filter_is_sticky = False
  if 'alias_prefix' in self.__dict__:
  obj.alias_prefix = self.alias_prefix
 }}}


 I tested code against 1.9 (because our app uses 1.9). It's possible this
 is fixed in master, though a quick glance at master made me think
 otherwise.

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

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

[Django]

#26401: Allow auth machinery to be used without installing auth app
--+-
 Reporter:  Matt Johnson  |Owner:  Andrew Konoff
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  auth 1.11 | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by Jon Dufresne):

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


Comment:

 Reopening. The revert commit was merged.

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

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

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

[Django]

#26401: Allow auth machinery to be used without installing auth app
--+-
 Reporter:  Matt Johnson  |Owner:  Andrew Konoff
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:  fixed
 Keywords:  auth 1.11 | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by Jon Dufresne ):

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


Comment:

 In [changeset:"f3ea0c4bbd5fa9bac73049839ce5de388d53371a" f3ea0c4]:
 {{{
 #!CommitTicketReference repository=""
 revision="f3ea0c4bbd5fa9bac73049839ce5de388d53371a"
 Reverted "Fixed #26401 -- Added BaseAuthConfig to use auth without
 migrations."

 This reverts commit 1ec1633cb294d8ce2a65ece6b56c258483596fba as it
 doesn't handle ContentType's auth.Permission dependency. Thus, it
 doesn't allow auth without 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/066.c670451472d35b8297c399cd8738259c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16614: Support server-side cursors for queryset iteration in database backends

[Django]

#16614: Support server-side cursors for queryset iteration in database backends
-+-
 Reporter:  Dan McGee|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  memory cursors   | Triage Stage:  Accepted
  database   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Josh Smeaton):

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

Re: [Django] #27385: Error in QuerySet.bulk_create() on PostgreSQL when objs length is a multiple plus one of batch_size

[Django]

#27385: Error in QuerySet.bulk_create() on PostgreSQL when objs length is a
multiple plus one of batch_size
-+-
 Reporter:  David Barragán   |Owner:  nobody
  Merino |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"736f7e7ed7d04cfb9032636b5b65cba26ec7d6db" 736f7e7e]:
 {{{
 #!CommitTicketReference repository=""
 revision="736f7e7ed7d04cfb9032636b5b65cba26ec7d6db"
 [1.10.x] Fixed #27385 -- Fixed QuerySet.bulk_create() on PostgreSQL when
 the number of objects is a multiple plus one of batch_size.

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

Re: [Django] #27385: Error in QuerySet.bulk_create() on PostgreSQL when objs length is a multiple plus one of batch_size

[Django]

#27385: Error in QuerySet.bulk_create() on PostgreSQL when objs length is a
multiple plus one of batch_size
-+-
 Reporter:  David Barragán   |Owner:  nobody
  Merino |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   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 ):

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


Comment:

 In [changeset:"b3bd3aa07c026239dd39d1a37498dfd0a2f09caf" b3bd3aa]:
 {{{
 #!CommitTicketReference repository=""
 revision="b3bd3aa07c026239dd39d1a37498dfd0a2f09caf"
 Fixed #27385 -- Fixed QuerySet.bulk_create() on PostgreSQL when the number
 of objects is a multiple plus one of batch_size.
 }}}

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

Re: [Django] #27385: Error in QuerySet.bulk_create() on PostgreSQL when objs length is a multiple plus one of batch_size (was: Error in bulk_create() when objs length is a multiple plus one of batch_s

[Django]

#27385: Error in QuerySet.bulk_create() on PostgreSQL when objs length is a
multiple plus one of batch_size
-+-
 Reporter:  David Barragán   |Owner:  nobody
  Merino |
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   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 Tim Graham):

 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * stage:  Unreviewed => Ready for checkin


Old description:

> With the model
>

> {{{
> from django.db import models
>
> class TestModel(models.Model):
> number = models.IntegerField()
>
> }}}
>
> using a "real" db (postgresql) if I try to do this
>
> {{{
> objs = [TestModel(number=n) for n in range(11)]
> TestModel.objects.bulk_create(objs, batch_size=10)
> }}}
>
> I get this error
>
> {{{
> /home/bameda/.virtualenvs/taiga/lib/python3.5/site-
> packages/django/db/models/manager.py in manager_method(self, *args,
> **kwargs)
>  83 def create_method(name, method):
>  84 def manager_method(self, *args, **kwargs):
> ---> 85 return getattr(self.get_queryset(), name)(*args,
> **kwargs)
>  86 manager_method.__name__ = method.__name__
>  87 manager_method.__doc__ = method.__doc__
>
> /home/bameda/.virtualenvs/taiga/lib/python3.5/site-
> packages/django/db/models/query.py in bulk_create(self, objs, batch_size)
> 450 if objs_without_pk:
> 451 fields = [f for f in fields if not
> isinstance(f, AutoField)]
> --> 452 ids = self._batched_insert(objs_without_pk,
> fields, batch_size)
> 453 if
> connection.features.can_return_ids_from_bulk_insert:
> 454 assert len(ids) == len(objs_without_pk)
>
> /home/bameda/.virtualenvs/taiga/lib/python3.5/site-
> packages/django/db/models/query.py in _batched_insert(self, objs, fields,
> batch_size)
>1062 inserted_id = self._insert(item, fields=fields,
> using=self.db, return_id=True)
>1063 if len(objs) > 1:
> -> 1064 inserted_ids.extend(inserted_id)
>1065 if len(objs) == 1:
>1066 inserted_ids.append(inserted_id)
>
> TypeError: 'int' object is not iterable
> }}}
>
> The patch https://github.com/django/django/pull/7433 solved it.
>
> It happens in master and in 1.10.x

New description:

 With the model:
 {{{
 from django.db import models

 class TestModel(models.Model):
 number = models.IntegerField()

 }}}
 If I try to do this on PostgreSQL:
 {{{
 objs = [TestModel(number=n) for n in range(11)]
 TestModel.objects.bulk_create(objs, batch_size=10)
 }}}
 I get this error:
 {{{
 /home/bameda/.virtualenvs/taiga/lib/python3.5/site-
 packages/django/db/models/manager.py in manager_method(self, *args,
 **kwargs)
  83 def create_method(name, method):
  84 def manager_method(self, *args, **kwargs):
 ---> 85 return getattr(self.get_queryset(), name)(*args,
 **kwargs)
  86 manager_method.__name__ = method.__name__
  87 manager_method.__doc__ = method.__doc__

 /home/bameda/.virtualenvs/taiga/lib/python3.5/site-
 packages/django/db/models/query.py in bulk_create(self, objs, batch_size)
 450 if objs_without_pk:
 451 fields = [f for f in fields if not
 isinstance(f, AutoField)]
 --> 452 ids = self._batched_insert(objs_without_pk,
 fields, batch_size)
 453 if
 connection.features.can_return_ids_from_bulk_insert:
 454 assert len(ids) == len(objs_without_pk)

 /home/bameda/.virtualenvs/taiga/lib/python3.5/site-
 packages/django/db/models/query.py in _batched_insert(self, objs, fields,
 batch_size)
1062 inserted_id = self._insert(item, fields=fields,
 using=self.db, return_id=True)
1063 if len(objs) > 1:
 -> 1064 inserted_ids.extend(inserted_id)
1065 if len(objs) == 1:
1066 inserted_ids.append(inserted_id)

 TypeError: 'int' object is not iterable
 }}}

 The patch https://github.com/django/django/pull/7433 solved it.

 It happens in master and in 

Re: [Django] #27386: Readonly callable field is unconditionally wrapped inside ..., which might create invalid HTML (was: Callable field is wrapped inside ...)

[Django]

#27386: Readonly callable field is unconditionally wrapped inside ..., 
which
might create invalid HTML
-+-
 Reporter:  Jacob Rief   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  callable field   | Triage Stage:  Accepted
  is_readonly |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Old description:

> (Pseudo)-Fields in classes inheriting from
> ``django.contrib.admin.ModelsAdmin`` which are callables, must be listed
> in ``readonly_fields``. This implies that in
> ``admin/includes/fieldset.html`` (line 17) and
> ``admin/edit_inline/tabular.html`` (line 55) the content of this field is
> wrapped inside a paragraph ``{{ field.contents }}``.
>
> However, a ``...`` is not suitable to accept every kind of HTML
> element. Therefore when using a "callable" field, which renders it's
> content in HTML, one might get a surprising result.
>
> Since the author of a callable field may wrap it's content into whatever
> (s)he likes, there should be a way to avoid these wrapping paragraphs.
>
> My proposal is to check if ``field.contents`` is safe text, and if so
> then leave it as-is, or otherwise wrap it  into ``..`` as we do it
> right now.

New description:

 (Pseudo)-Fields in classes inheriting from
 `django.contrib.admin.ModelsAdmin` which are callables, must be listed in
 `readonly_fields`. This implies that in `admin/includes/fieldset.html`
 (line 17) and `admin/edit_inline/tabular.html` (line 55) the content of
 this field is wrapped inside a paragraph `{{ field.contents }}`.

 However, a `...` is not suitable to accept every kind of HTML
 element. Therefore when using a "callable" field, which renders it's
 content in HTML, one might get a surprising result.

 Since the author of a callable field may wrap it's content into whatever
 (s)he likes, there should be a way to avoid these wrapping paragraphs.

 My proposal is to check if `field.contents` is safe text, and if so then
 leave it as-is, or otherwise wrap it  into `..` as we do it right
 now.

--

Comment:

 I'm not sure if the proposal is completely backwards-compatible, but the
 problem seems real.

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

Re: [Django] #27387: Rendering "required" as HTML attribute is not documented under Field.required (was: Rendering "required" as HTML attribute is not documented)

[Django]

#27387: Rendering "required" as HTML attribute is not documented under
Field.required
--+
 Reporter:  karyon|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  1.10
 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 Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 See ec6121693f112ae33b653b4364e812722d2eb567 for the change and all places
 the documentation was updated. I guess it's a matter of judgment how many
 times to repeat certain things and to add links as appropriate.

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

Re: [Django] #27387: Rendering "required" as HTML attribute is not documented

[Django]

#27387: Rendering "required" as HTML attribute is not documented
-+-
 Reporter:  karyon   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  1.10
 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 karyon):

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


Old description:

> https://docs.djangoproject.com/en/1.10/releases/1.10/#forms says
>
> {{{
> Required form fields now have the required HTML attribute. Set the new
> Form.use_required_attribute attribute to False to disable it. The
> required attribute isn’t included on forms of formsets because the
> browser validation may not be correct when adding and deleting formsets.
> }}}
> i would expect all of that (it's rendered, can be disabled, isn't
> rendered in formsets) to appear somewhere around
> https://docs.djangoproject.com/el/1.10/ref/forms/fields/#required, but it
> does not.

New description:

 https://docs.djangoproject.com/en/1.10/releases/1.10/#forms says

 {{{
 Required form fields now have the required HTML attribute. Set the new
 Form.use_required_attribute attribute to False to disable it. The required
 attribute isn’t included on forms of formsets because the browser
 validation may not be correct when adding and deleting formsets.
 }}}
 i would expect all of that (it's rendered, can be disabled, isn't rendered
 in formsets) to appear somewhere around
 https://docs.djangoproject.com/el/1.10/ref/forms/fields/#required, but it
 does not.

 ref https://code.djangoproject.com/ticket/27299. I guess this per-widget
 option should rather not be mentioned in the field documentation...?

--

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

[Django] #27387: Rendering "required" as HTML attribute is not documented

[Django]

#27387: Rendering "required" as HTML attribute is not documented
--+
 Reporter:  karyon|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Forms |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 https://docs.djangoproject.com/en/1.10/releases/1.10/#forms says

 {{{
 Required form fields now have the required HTML attribute. Set the new
 Form.use_required_attribute attribute to False to disable it. The required
 attribute isn’t included on forms of formsets because the browser
 validation may not be correct when adding and deleting formsets.
 }}}
 i would expect all of that (it's rendered, can be disabled, isn't rendered
 in formsets) to appear somewhere around
 https://docs.djangoproject.com/el/1.10/ref/forms/fields/#required, but it
 does 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/049.517ca8c3b638953e3a55761dba3bf708%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27386: Callable field is wrapped inside ...

[Django]

#27386: Callable field is wrapped inside ...
-+-
 Reporter:  Jacob Rief   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  callable field   | Triage Stage:
  is_readonly |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Rief):

 * keywords:  field is_readonly  => callable field is_readonly 


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

Re: [Django] #27386: Callable field is wrapped inside ...

[Django]

#27386: Callable field is wrapped inside ...
-+-
 Reporter:  Jacob Rief   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  field is_readonly| Triage Stage:
  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Rief):

 * keywords:  field => field is_readonly 
 * 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/063.3075c046222322e2bb53594dc802a8d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27386: Callable field is wrapped inside ...

[Django]

#27386: Callable field is wrapped inside ...
--+
 Reporter:  Jacob Rief|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.admin |Version:  master
 Severity:  Normal|   Keywords:  field
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 (Pseudo)-Fields in classes inheriting from
 ``django.contrib.admin.ModelsAdmin`` which are callables, must be listed
 in ``readonly_fields``. This implies that in
 ``admin/includes/fieldset.html`` (line 17) and
 ``admin/edit_inline/tabular.html`` (line 55) the content of this field is
 wrapped inside a paragraph ``{{ field.contents }}``.

 However, a ``...`` is not suitable to accept every kind of HTML
 element. Therefore when using a "callable" field, which renders it's
 content in HTML, one might get a surprising result.

 Since the author of a callable field may wrap it's content into whatever
 (s)he likes, there should be a way to avoid these wrapping paragraphs.

 My proposal is to check if ``field.contents`` is safe text, and if so then
 leave it as-is, or otherwise wrap it  into ``..`` as we do it right
 now.

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

Re: [Django] #27362: Omitting default_app_config in __init__.py happens too easily.

[Django]

#27362: Omitting default_app_config in __init__.py happens too easily.
-+-
 Reporter:  Thomas Güttler   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aymeric Augustin):

 Historically this ticket would have been kept open in the "design decision
 needed" stage. We started closing tickets with no clear way forwards a
 couple years ago to keep open tickets actionable.

 I believe that the documentation is clear is it stands and (unfortunately)
 not a good solution here because a programmer debugging such a problem is
 unlikely to be perusing the documentation of apps.

 Perhaps we could add a check to raise a warning if there's an AppConfig
 subclass defined in an `apps` submodule -- the conventional location? That
 seems quite prone to false positives...

 Other arguments or ideas welcome...

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

Re: [Django] #24203: Optimisation: adding multiple fields to same model should attempt to run single ALTER TABLE statement

[Django]

#24203: Optimisation: adding multiple fields to same model should attempt to run
single ALTER TABLE statement
-+-
 Reporter:  Peter Lauri  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration| Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Doug Harris):

 * cc: dharris+django@… (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/068.4c54f44435122b7fe1dc9d579938c9d2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27385: Error in bulk_create() when objs length is a multiple plus one of batch_size

[Django]

#27385: Error in bulk_create() when objs length is a multiple plus one of
batch_size
--+
 Reporter:  David Barragán Merino |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 With the model


 {{{
 from django.db import models

 class TestModel(models.Model):
 number = models.IntegerField()

 }}}

 using a "real" db (postgresql) if I try to do this

 {{{
 objs = [TestModel(number=n) for n in range(11)]
 TestModel.objects.bulk_create(objs, batch_size=10)
 }}}

 I get this error

 {{{
 /home/bameda/.virtualenvs/taiga/lib/python3.5/site-
 packages/django/db/models/manager.py in manager_method(self, *args,
 **kwargs)
  83 def create_method(name, method):
  84 def manager_method(self, *args, **kwargs):
 ---> 85 return getattr(self.get_queryset(), name)(*args,
 **kwargs)
  86 manager_method.__name__ = method.__name__
  87 manager_method.__doc__ = method.__doc__

 /home/bameda/.virtualenvs/taiga/lib/python3.5/site-
 packages/django/db/models/query.py in bulk_create(self, objs, batch_size)
 450 if objs_without_pk:
 451 fields = [f for f in fields if not
 isinstance(f, AutoField)]
 --> 452 ids = self._batched_insert(objs_without_pk,
 fields, batch_size)
 453 if
 connection.features.can_return_ids_from_bulk_insert:
 454 assert len(ids) == len(objs_without_pk)

 /home/bameda/.virtualenvs/taiga/lib/python3.5/site-
 packages/django/db/models/query.py in _batched_insert(self, objs, fields,
 batch_size)
1062 inserted_id = self._insert(item, fields=fields,
 using=self.db, return_id=True)
1063 if len(objs) > 1:
 -> 1064 inserted_ids.extend(inserted_id)
1065 if len(objs) == 1:
1066 inserted_ids.append(inserted_id)

 TypeError: 'int' object is not iterable
 }}}

 The patch https://github.com/django/django/pull/7433 solved it.

 It happens in master and in 1.10.x

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

Re: [Django] #27383: Regression: `FileField(default=None)` now never upload a file through a ModelForm

[Django]

#27383: Regression: `FileField(default=None)` now never upload a file through a
ModelForm
-+-
 Reporter:  Maxime Lorant|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.10
  uploads/storage|   Resolution:
 Severity:  Normal   |  worksforme
 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 Tim Graham):

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


Comment:

 I cannot reproduce a problem using this model and uploading through the
 default admin add/change view:
 {{{
 class FileModel(models.Model):
 file = models.FileField(default=None, null=True, blank=True)
 }}}

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

Re: [Django] #27384: Accessing request.POST in Django middlewares 1.10.x make it empty for view

[Django]

#27384: Accessing request.POST in Django middlewares 1.10.x make it empty for 
view
-+-
 Reporter:  Matheus Ashton   |Owner:  nobody
  Silva  |
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  middleware   | Triage Stage:
  request.POST   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * component:  Uncategorized => HTTP handling
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => worksforme


Old description:

> Hello,
>
> I'm creating a middleware to log every request in my API, following the
> new specification on django 1.10.x.
>
> When I access the request.POST attr it goes blank to the view
>
> {{{
> #!div style="font-size: 80%"
> Code highlighting:
>   {{{#!python
> def log_request_middleware(get_response):
> logger = logging.getLogger('requests')
>
> def middleware(request):
> request_body = request.POST.copy().dict()
> response = get_response(request)
>   }}}
> }}}
>
> The request.POST on the view now is blank, it happens even with a simple
> access a print or assignment.
>
> It also happens with request.GET

New description:

 Hello,

 I'm creating a middleware to log every request in my API, following the
 new specification on django 1.10.x.

 When I access the `request.POST` attr it goes blank to the view.

 {{{#!python
 import logging

 def log_request_middleware(get_response):
 logger = logging.getLogger('requests')

 def middleware(request):
 request_body = request.POST.copy().dict()
 response = get_response(request)
 return response
 return middleware
 }}}

 The `request.POST` on the view now is blank, it happens even with a simple
 access a print or assignment.

 It also happens with `request.GET`.

--

Comment:

 I cannot reproduce a problem with the middleware you provided (though it
 seems to have some missing lines which I added to the description). Can
 you provide a test case or a sample project to reproduce?

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

Re: [Django] #27383: Regression: `FileField(default=None)` now never upload a file through a ModelForm

[Django]

#27383: Regression: `FileField(default=None)` now never upload a file through a
ModelForm
-+-
 Reporter:  Maxime Lorant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  1.10
  uploads/storage|
 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 Maxime Lorant):

 I am using Django 1.10.2. I could give a project example when I have the
 time and if I can reproduce it from scratch :-) I am using S3 but I don't
 think the storage used is important here.

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

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

Re: [Django] #27369: Multiple form fields can share the same widget instance

[Django]

#27369: Multiple form fields can share the same widget instance
-+-
 Reporter:  Michal Petrucha  |Owner:  Michal
 |  Petrucha
 Type:  Bug  |   Status:  assigned
Component:  Forms|  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 Jaap Roes):

 Replying to [comment:1 Michal Petrucha]:
 > [https://github.com/django/django/pull/6267 PR]

 This links to the wrong PR (#6267), the correct one is this
 [https://github.com/django/django/pull/7415 PR #7415]

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

[Django] #27384: Accessing request.POST in Django middlewares 1.10.x make it empty for view

[Django]

#27384: Accessing request.POST in Django middlewares 1.10.x make it empty for 
view
--+
 Reporter:  Matheus Ashton Silva  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Uncategorized |Version:  1.10
 Severity:  Normal|   Keywords:  middleware
  |  request.POST
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hello,

 I'm creating a middleware to log every request in my API, following the
 new specification on django 1.10.x.

 When I access the request.POST attr it goes blank to the view

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
 def log_request_middleware(get_response):
 logger = logging.getLogger('requests')

 def middleware(request):
 request_body = request.POST.copy().dict()
 response = get_response(request)
   }}}
 }}}

 The request.POST on the view now is blank, it happens even with a simple
 access a print or assignment.

 It also happens with request.GET

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

Re: [Django] #27383: Regression: `FileField(default=None)` now never upload a file through a ModelForm

[Django]

#27383: Regression: `FileField(default=None)` now never upload a file through a
ModelForm
-+-
 Reporter:  Maxime Lorant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  1.10
  uploads/storage|
 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 Tim Graham):

 Just to be sure, are you using Django 1.10.2? (see #27186 for a
 `FileInput` fix for fields with a `default`). As an aside, according to
 #10244, `FileField` can't be `null` anyway.

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

Re: [Django] #27370: Django's Select widget adds a required="required" attribute, even if created with empty_label=True

[Django]

#27370: Django's Select widget adds a required="required" attribute, even if
created with empty_label=True
-+-
 Reporter:  alexpirine   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  HTML,Select,wdiget,ModelChoiceField|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jon Dufresne):

 alexpirine, I believe Claude is referring to
 
[https://github.com/django/django/blob/adc93e85990b644194c679f528225deed9fdaa85/django/forms/widgets.py#L254-L255
 Widget.use_required_attribute], not `Form.use_required_attribute`. For
 reference, this method will be documented
 [https://github.com/django/django/pull/7419 soon].

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

Re: [Django] #21412: Django message framework called with None

[Django]

#21412: Django message framework called with None
-+-
 Reporter:  merb |Owner:  Denis
 |  Cornehl
 Type:  Bug  |   Status:  closed
Component:  contrib.messages |  Version:  1.6
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  messages | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 Perhaps. Generally we prefer ducktyping over `isinstance`.

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

Re: [Django] #25192: Can't Squash Migration that uses migrations.RunPython.noop in Python 2

[Django]

#25192: Can't Squash Migration that uses migrations.RunPython.noop in Python 2
-+
 Reporter:  James Pulec  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  py2  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Shai Berger):

 * cc: Shai Berger (added)


Comment:

 I found a funny workaround: In my project, I added this `squashmigrations`
 command (that is, a file `management/commands/squashmigrations.py` in one
 of my projects' apps):
 {{{
 """
 A squashmigrations command which does some monkeypatching on the RunPython
 operation
 to allow squashing migrations which use RunPython.noop, even on Python 2
 """
 from django.core.management.commands.squashmigrations import Command as
 DjangoCommand
 from django.db.migrations import RunPython


 # A staticmethod decorator is needed (out of a class!) because we are
 going to
 # monkeypatch this function into a class and it will be introspected by
 code that
 # will think it is an unbound instance method without the decorator.
 @staticmethod
 def noop(apps, schema_editor):
 return None


 class Command(DjangoCommand):

 def handle(self, **options):
 # Monkeypatch
 RunPython.noop = noop
 # Invoke original
 return super(Command, self).handle(**options)
 }}}
 Note the oddity of the `@staticmethod` decorator on a function that isn't
 in a class.

 I suppose we could use the same idea in fixing the bug in Django as
 well...

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

Re: [Django] #27363: SessionMiddleware can return redirect(request.path) which might be an unsafe thing to do

[Django]

#27363: SessionMiddleware can return redirect(request.path) which might be an
unsafe thing to do
-+-
 Reporter:  Raphael Michel   |Owner:  Andrew
 |  Nester
 Type:  Bug  |   Status:  assigned
Component:  contrib.sessions |  Version:  1.10
 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 Raphael Michel):

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

Re: [Django] #27382: Document that ugettext_lazy() result can't be used with arbitrary Python code

[Django]

#27382: Document that ugettext_lazy() result can't be used with arbitrary Python
code
---+
 Reporter:  Mike Edmunds   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  ugettext_lazy  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Moritz Sichert):

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

Re: [Django] #27370: Django's Select widget adds a required="required" attribute, even if created with empty_label=True

[Django]

#27370: Django's Select widget adds a required="required" attribute, even if
created with empty_label=True
-+-
 Reporter:  alexpirine   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  HTML,Select,wdiget,ModelChoiceField|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by alexpirine):

 I agree with Claude.

 Also, `use_required_attribute` applies to all fields, which is not desired
 here. We only want to remove the required attribute from the Select
 widget.

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

Re: [Django] #27370: Django's Select widget adds a required="required" attribute, even if created with empty_label=True

[Django]

#27370: Django's Select widget adds a required="required" attribute, even if
created with empty_label=True
-+-
 Reporter:  alexpirine   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  HTML,Select,wdiget,ModelChoiceField|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 If Django has all needed elements to determine the value of
 `use_required_attribute` in such a situation, it should do it
 automatically and not require the user to add it explicitly.

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

Re: [Django] #27378: Add UUID serialization support to migration writer

[Django]

#27378: Add UUID serialization support to migration writer
-+-
 Reporter:  Yuriy Korobko|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  uuid choices | Triage Stage:  Accepted
  migration  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 Please create a pull request if possible and uncheck "Needs documentation"
 and "Needs tests" on the ticket so that it appears in the review queue.

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

Re: [Django] #27363: SessionMiddleware can return redirect(request.path) which might be an unsafe thing to do

[Django]

#27363: SessionMiddleware can return redirect(request.path) which might be an
unsafe thing to do
-+-
 Reporter:  Raphael Michel   |Owner:  Andrew
 |  Nester
 Type:  Bug  |   Status:  assigned
Component:  contrib.sessions |  Version:  1.10
 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 Andrew Nester):

 * status:  new => assigned
 * owner:  nobody => Andrew Nester


Comment:

 Agree that it's much better to return 400 HTTP status in case of deleted
 session.
 Proper pull request has been added to implement this

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

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

Re: [Django] #21412: Django message framework called with None

[Django]

#21412: Django message framework called with None
-+-
 Reporter:  merb |Owner:  Denis
 |  Cornehl
 Type:  Bug  |   Status:  closed
Component:  contrib.messages |  Version:  1.6
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  messages | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Raffaele Salmaso):

 Hi,
 I'm using django-rest-framework Request object, and this patch make
 impossible to use it as replacement: I must use request._request, which is
 a bit ugly.

 Would it be better as

 {{{
 def add_message(request, level, message, extra_tags='',
 fail_silently=False):
 """
 Attempts to add a message to the request using the 'messages' app.
 """
 if request and hasattr(request, '_messages'):
 return request._messages.add(level, message, extra_tags)

 if not fail_silently:
 from django.conf import settings
 if 'django.contrib.messages.middleware.MessageMiddleware' not in
 settings.MIDDLEWARE:
 raise MessageFailure(
 'You cannot add messages without installing '
 'django.contrib.messages.middleware.MessageMiddleware'
 )
 raise TypeError("add_message() argument must be an HttpRequest like
 object, "
 "not '%s'." % request.__class__.__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/062.c4ef3ef1c76d40d943b9abe8c6d75d8c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27370: Django's Select widget adds a required="required" attribute, even if created with empty_label=True

[Django]

#27370: Django's Select widget adds a required="required" attribute, even if
created with empty_label=True
-+-
 Reporter:  alexpirine   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  HTML,Select,wdiget,ModelChoiceField|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Andrew Nester):

 Agree with Claude Paroz - all we need to do is to set
 {{{use_required_attribute = False}}} in form where such field used.
 Something like this:

 {{{
 class TestForm(forms.Form):
 use_required_attribute = False

 some_field = forms.ModelChoiceField(queryset=SomeModel.objects.all(),
 empty_label=None)
 }}}

 I guess we don't need some additional changes for this, what do you think
 @alexpirine?

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

Re: [Django] #27335: Avoid object save during QuerySet.update_or_create() when there were no changes

[Django]

#27335: Avoid object save during QuerySet.update_or_create() when there were no
changes
-+-
 Reporter:  tonnzor  |Owner:  Andrew
 Type:   |  Nester
  Cleanup/optimization   |   Status:  assigned
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 Andrew Nester):

 Hi @tonnzorr
 As discussed in pull request linked to this ticket implementing this
 optimization might cause some issues not covered here previously. Some of
 them:
 1. Handling foreign key changes
 2. Regression of auto_now feature
 3. Updating models backed by tables with triggers and so on.

 My point here is that implementing this feature requires a lot of time
 comparing with profit we can gain from it, so it looks like we are trying
 to be too smart here and it's a little bit dangerous because this
 optimization looks like source of potential regression.
 I am just curious to know your opinion about it because my point here is
 that it's better to leave behavior of update_or_create as it is now.

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

Re: [Django] #27383: Regression: `FileField(default=None)` now never upload a file through a ModelForm

[Django]

#27383: Regression: `FileField(default=None)` now never upload a file through a
ModelForm
-+-
 Reporter:  Maxime Lorant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  1.10
  uploads/storage|
 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 Maxime Lorant):

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


Old description:

> We had in our code the following line (don't ask why, I don't know):
>
> {{{
> class SomeModel(models.Model):
>  foo = ...
>  bar = ...
>  file = models.FileField(null=True, blank=True, default=None)
>

> class SomeModelForm(forms.ModelForm):
>  class Meta:
>   fields = ('foo', 'bar', 'file', )
> }}}
>
> It was working until Django 1.9.x, but switching to Django 1.10,
> submission of files through a ModelForm stopped working. I found a
> solution by removing the useless `default=None`. Even though its
> usefulness can be questioned, it looks like it is a regression not
> documented in the release notes.
>
> Should we bother adding it or fix it?

New description:

 We had in our code the following line (don't ask why, I don't know):

 {{{
 class SomeModel(models.Model):
  foo = ...
  bar = ...
  file = models.FileField(null=True, blank=True, default=None)


 class SomeModelForm(forms.ModelForm):
  class Meta:
   fields = ('foo', 'bar', 'file', )
 }}}

 It was working until Django 1.9.x, but switching to Django 1.10,
 submission of files through a ModelForm stopped working. I found a
 solution by removing the useless `default=None`. Even though its
 usefulness can be questioned, it looks like it is a regression not
 documented in the release notes.

 Should we bother adding it or change back the behaviour?

--

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

[Django] #27383: Regression: `FileField(default=None)` now never upload a file through a ModelForm

[Django]

#27383: Regression: `FileField(default=None)` now never upload a file through a
ModelForm
--+
 Reporter:  Maxime Lorant |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  File uploads/storage  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 We had in our code the following line (don't ask why, I don't know):

 {{{
 class SomeModel(models.Model):
  foo = ...
  bar = ...
  file = models.FileField(null=True, blank=True, default=None)


 class SomeModelForm(forms.ModelForm):
  class Meta:
   fields = ('foo', 'bar', 'file', )
 }}}

 It was working until Django 1.9.x, but switching to Django 1.10,
 submission of files through a ModelForm stopped working. I found a
 solution by removing the useless `default=None`. Even though its
 usefulness can be questioned, it looks like it is a regression not
 documented in the release notes.

 Should we bother adding it or fix 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/050.860eb393457945500beb5e0d957bb2ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27378: Add UUID serialization support to migration writer

[Django]

#27378: Add UUID serialization support to migration writer
-+-
 Reporter:  Yuriy Korobko|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  uuid choices | Triage Stage:  Accepted
  migration  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Yuriy Korobko):

 Replying to [comment:2 Tim Graham]:
 > Tests and documentation are needed for a complete patch. See
 998894e1b9f5a8715f4cac5f6201b5e9ac80510c for a similar commit.
 Can you please take look into attached 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/069.72c14cc5734035eda237da2bb75c49b6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27378: Add UUID serialization support to migration writer

[Django]

#27378: Add UUID serialization support to migration writer
-+-
 Reporter:  Yuriy Korobko|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  uuid choices | Triage Stage:  Accepted
  migration  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Yuriy Korobko):

 * Attachment "uudserializer.patch" 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/069.f2b5584dc4fa60cba87ba4c4f8f064cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.