date:20160323

Re: [Django] #16508: Provide real support for virtual fields

2016-03-23 Thread Django

#16508: Provide real support for virtual fields
-+-
 Reporter:  vzima|Owner:  pirosb3
 Type:  New feature  |   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 akaariai):

 Big +1 to introducing these changes in smaller chunks.

 For composite fields we are going to have a design problem for mutable
 composite values. For example, assume User.full_name is a FullName
 instance. What should happen in the following cases, and how to implement
 the wanted behavior?
 {{{
 u = User()
 u.full_name = FullName('Anssi', 'Kääriäinen')
 u.full_name.first_name = 'Matti'
 u.first_name == u.full_name.first_name
 OUT: ???

 u1 = User()
 u2 = User()
 u1.full_name = FullName('Anssi', 'Kääriäinen')
 u2.full_name = u1.full_name
 u2.full_name.first_name = 'Matti'
 u1.first_name == u2.first_name
 OUT: ???
 }}}

 This is a nasty issue, and I think we should avoid it by saying that for
 now Django doesn't support mutable composite field values (that is, the
 composite field's value should be a tuple). Later on we can then decide
 how to tackle this issue properly.

--
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.f84091ca9f4d38dcc0102ce1f93c89c1%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

2016-03-23 Thread Django

#26401: Allow auth machinery to be used without installing auth app
--+
 Reporter:  satchamo  |Owner:  satchamo
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  auth  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by apollo13):

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

Re: [Django] #16508: Provide real support for virtual fields

2016-03-23 Thread Django

* cc: michal.petrucha@… (added)

Comment:

I have recently started to dust off my old code from GSoC 2013, where my
first step was pretty much this. Let me summarize my take on this. (I'm
sorry, this is going to be a bit long, but I'm trying to organize my
thoughts on how to approach this entire thing.)

My implementation from a few years ago matches the description from
comment:5 (as far as the conceptual handling of `ForeignKey` goes), and
also comment:7 (when it comes to the actual class hierarchy). And yeah,
comment:9 is also mostly spot-on, except for the last sentence – the ORM
or migrations certainly can't ignore `ForeignKey` once it becomes virtual;
instead, migrations will have to hide any auto-generated auxiliary
concrete fields to make migrations backwards-compatible.

I think that before we start working on `ForeignKey` and break the entire
ORM, it would be kind of nice to just get the more general `VirtualField`
in. The code for just the VirtualField class without any changes to
`ForeignKey` and friends can be seen in

[[https://github.com/konk/django/compare/1116df0751cc0d5862590b08adfffe7bacd6bf43...konk:349796f37998e02e34a2b47ab5f3e763ae60140f|this
Github comparison]]. After that I implemented the virtual `ForeignKey`
change, but up to that point, it was pretty isolated and self-contained.

Key observations from my implementation: `GenericForeignKey` and
`GenericRelation` are handled specially in
1. model instance initialization (using the `pre_init` signal),
2. they are kind of special cased in deletion cascading, and
3. they are cloned in every model subclass.

Number 1 was fixed by making `Model.__init__` consider virtual fields when
processing keyword arguments. This made it possible to remove the usage of
`pre_init` from `GenericForeignKey`.

Number 2 I'm not entirely certain about right now; I haven't yet found the
time to fully understand how this is handled after Daniel's `_meta`
refactor, but there used to be a few caches of arbitrary collections of
relationship objects. I handled this by including `GenericRelation` in
those collections, which meant it was no longer necessary to special-case
`_meta.virtual_fields` just to reach `GenericRelation`s. I guess these
days this could be achieved by making sure `GenericRelation` appears in
`_meta.related_objects`, but I'd need to study this a bit further to be
certain. (Daniel, do you have any insight here? Can we even to that now
without breaking backwards compatibility?)

Number 3 is a peculiarity of `GenericRelation`. The problem here is that
it needs a reference to the current model in order to use the correct
content type, which means it really does need to be cloned in every
subclass, even in concrete model inheritance (otherwise it would use the
parent's content type).

Right now, all virtual fields are cloned in concrete inheritance, but that
doesn't make any sense for other virtual fields, like `ForeignKey`, or
`CompositeField`, or whatever. Those should be handled just like any other
field, as far as inheritance is concerned. This doesn't really have
anything to do with `GenericRelation` being a virtual field, instead, a
more fitting name for this particular concept would be something like
“private” field (or “local private”, as I named it in my 2013's branch).
After all, we already do have support for other virtual fields that do not
land in `_meta.virtual_fields`. (`ForeignObject`, although AFAIK it is not
a public API, but still.)

With all that being said, I would like to get the ball rolling by offering
[[https://github.com/django/django/pull/6329|PR 6329]] which implements
number 3 above, the rename of `_meta.virtual_fields` to
`_meta.private_fields`.

In the meantime I'll go investigate what to do about the rest of the
changes in that range of commits I linked above.

--
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

Re: [Django] #16286: Models virtual fields and ModelForms

2016-03-23 Thread Django

#16286: Models virtual fields and ModelForms
-+-
 Reporter:  loic84   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 jpic):

 > Currently the only virtual field in Django is GenericForeignKey and it
 doesn't need this feature because each local field it relies on is
 responsible for its own data.

 How can the object_id field be validated without the knowledge of its
 GFK's content_type field ?

 I'd like to re-open this: some apps have been providing working widgets
 for GFK for years now, so there's got to be a way.

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

Re: [Django] #11909: Django 'eating up' method errors in templates

2016-03-23 Thread Django

Comment (by PetrDlouhy):

There is hacky way with assigning handler object to the
`string_if_invalid` variable, which work quite well in my oppinion:
http://stackoverflow.com/questions/4300442/show-undefined-variable-errors-
in-django-templates

The main problem is, that there is not enough information for complete
error report. So I suggest adding an official invalid string handler,
which would have at least the `request`, template path and the faulty
string as parameters.

It could be taken even further, and set of default handlers could be
implemented in Django with levels like `silent`, `warning` and
`exception`, where the `silent` handler would be the default.

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

Re: [Django] #18607: ModelForms do not recognize DateTimeFields with auto_now=True

2016-03-23 Thread Django

#18607: ModelForms do not recognize DateTimeFields with auto_now=True
+--
 Reporter:  Adys|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  1.4
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by rschwiebert):

 The datetime field I'm using has `editable=True` and the ModelForm fails
 for the same reason. For insurance I also put auto_add=False and
 auto_now_add =False. Same problem.

 Maybe the above comments explain the problem, but it doesn't explain how
 to overcome 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/062.391ca357da491acaced0151e7e45f978%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26393: Unable to filter against annotations in Manager with use_for_related_fields

2016-03-23 Thread Django

#26393: Unable to filter against annotations in Manager with 
use_for_related_fields
-+-
 Reporter:  rpkilby  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by rpkilby):

 Yep - I completely misunderstood how that worked. I assumed that when
 filtering across relationships, the sql from the related manager was
 somehow used by the primary model's manager.

--
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.8abb9ca99b61bab2fafbcc609e906494%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

2016-03-23 Thread Django

#26401: Allow auth machinery to be used without installing auth app
--+--
 Reporter:  satchamo  |Owner:  satchamo
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  auth  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by satchamo):

 * owner:  nobody => satchamo
 * status:  new => assigned
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

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

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

2016-03-23 Thread Django

#26401: Allow auth machinery to be used without installing auth app
--+
 Reporter:  satchamo  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.9
 Severity:  Normal|   Keywords:  auth
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Django projects should be able to use the auth machinery (like
 django.contrib.auth.middleware.AuthenticationMiddleware and
 django.contrib.auth.context_processors.auth) without having
 django.contrib.auth in INSTALLED_APPS

 See

 https://groups.google.com/forum/#!topic/django-developers/2DzLBbk8w-w

 This ticket is for resolving the current issue in 1.9. I also want to
 write a test or two to prevent this issue from happening in the future.

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

Re: [Django] #26400: QuerySet bulk_create method to handle generators to prevent loading all objects in memory at once

2016-03-23 Thread Django

Comment (by charettes):

Replying to [comment:2 likeon]:
> It's not the first time I need that opportunity. I mean sure I can write
that split thing one more time as I did in other projects, but I don't see
any reason why the feature couldn't be a part of Django.

We'd have to alter both the signature and the return type of `bulk_create`
in order to pass a flag enabling this feature and make sure not to return
a list of the created objects. At this point I think this should be
handled by another method/function.

I personally don't believe this use case is common enough to warrant an
inclusion in Django but as Tim pointed out you could try leveraging
support from the community on the developer mailing list.

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

Re: [Django] #26400: QuerySet bulk_create method to handle generators to prevent loading all objects in memory at once

2016-03-23 Thread Django

#26400: QuerySet bulk_create method to handle generators to prevent loading all
objects in memory at once
-+-
 Reporter:  likeon   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_create  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 My first inclination was the same as Simon's but if you want to show what
 the changes to `bulk_create()` (or a new method) would look like, we can
 run it by the DevelopersMailingList to get some other opinions.

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

Re: [Django] #26383: Incomplete/incorrect documentation about using wsgi with Apache when project using virtualenv

2016-03-23 Thread Django

#26383: Incomplete/incorrect documentation about using wsgi with Apache when
project using virtualenv
-+-
 Reporter:  zshimanchik  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  wsgi, virtualenv,| Triage Stage:
  apache, documentation, modwsgi |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by zshimanchik):

 * resolution:  needsinfo => invalid


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

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

Re: [Django] #26400: QuerySet bulk_create method to handle generators to prevent loading all objects in memory at once

2016-03-23 Thread Django

#26400: QuerySet bulk_create method to handle generators to prevent loading all
objects in memory at once
-+-
 Reporter:  likeon   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_create  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by likeon):

 It's not the first time I need that. I mean sure I can write that split
 thing one more time as I did in other projects, but I don't see any reason
 why the feature couldn't be a part of Django.

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

Re: [Django] #26397: Use custom managers on Foreign Key

2016-03-23 Thread Django

#26397: Use custom managers on Foreign Key
-+-
 Reporter:  vladlep  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 This is also proposed in comment 27/28 of #14891.

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

Re: [Django] #26393: Unable to filter against annotations in Manager with use_for_related_fields (was: Unable to filter annotations across relationships.)

2016-03-23 Thread Django

#26393: Unable to filter against annotations in Manager with 
use_for_related_fields
-+-
 Reporter:  rpkilby  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Old description:

> Per the title, it seems like it would make sense to be able to filter
> annotations across relationships. Given the following,
> {{{
> from django.db import models
> from django.db.models import Value as V
> from django.db.models.functions import Concat
>

> class PersonManager(models.Manager):
> use_for_related_fields = True
>
> def get_queryset(self):
> queryset = super(PersonManager, self).get_queryset()
> queryset = queryset.annotate(full_name=Concat(
> 'first_name', V(' '), 'last_name',
> output_field=models.CharField()
> ))
> return queryset
>

> class Person(models.Model):
> first_name = SubCharField(max_length=100)
> last_name = SubSubCharField(max_length=100)
>
> objects = UserManager()
>

> class Article(models.Model):
> published = models.DateTimeField()
> author = models.ForeignKey(User, null=True, on_delete=models.CASCADE)
>
> }}}
>
> Running this:
> {{{
> Article.objects.filter(author__full_name="Bob, just Bob")
> }}}
>
> Produced the following traceback (snipped)
> {{{
>   ...
>   File "site-packages/django/db/models/query.py", line 790, in filter
> return self._filter_or_exclude(False, *args, **kwargs)
>   File "site-packages/django/db/models/query.py", line 808, in
> _filter_or_exclude
> clone.query.add_q(Q(*args, **kwargs))
>   File "site-packages/django/db/models/sql/query.py", line 1243, in add_q
> clause, _ = self._add_q(q_object, self.used_aliases)
>   File "site-packages/django/db/models/sql/query.py", line 1269, in
> _add_q
> allow_joins=allow_joins, split_subq=split_subq,
>   File "site-packages/django/db/models/sql/query.py", line 1192, in
> build_filter
> raise FieldError('Related Field got invalid lookup:
> {}'.format(lookups[0]))
> FieldError: Related Field got invalid lookup: full_name
> }}}

New description:

 Per the title, it seems like it would make sense to be able to filter
 annotations across relationships. Given the following,
 {{{
 from django.db import models
 from django.db.models import Value as V
 from django.db.models.functions import Concat


 class PersonManager(models.Manager):
 use_for_related_fields = True

 def get_queryset(self):
 queryset = super(PersonManager, self).get_queryset()
 queryset = queryset.annotate(full_name=Concat(
 'first_name', V(' '), 'last_name',
 output_field=models.CharField()
 ))
 return queryset


 class Person(models.Model):
 first_name = models.CharField(max_length=100)
 last_name = models.CharField(max_length=100)

 objects = PersonManager()


 class Article(models.Model):
 published = models.DateTimeField()
 author = models.ForeignKey(Person, null=True,
 on_delete=models.CASCADE)

 }}}

 Running this:
 {{{
 Article.objects.filter(author__full_name="Bob, just Bob")
 }}}

 Produced the following traceback (snipped)
 {{{
   ...
   File "site-packages/django/db/models/query.py", line 790, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File "site-packages/django/db/models/query.py", line 808, in
 _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File "site-packages/django/db/models/sql/query.py", line 1243, in add_q
 clause, _ = self._add_q(q_object, self.used_aliases)
   File "site-packages/django/db/models/sql/query.py", line 1269, in _add_q
 allow_joins=allow_joins, split_subq=split_subq,
   File "site-packages/django/db/models/sql/query.py", line 1192, in
 build_filter
 raise FieldError('Related Field got invalid lookup:
 {}'.format(lookups[0]))
 FieldError: Related Field got invalid lookup: full_name
 }}}

--

Comment:

 I think you have a misunderstanding of how `use_for_related_fields` works.
 The queryset in the custom manager isn't used in a query like
 `Article.objects.filter(...)` is it? If I'm missing something obvious and
 you have a patch demonstrating how your proposal works, then please reopen
 the ticket with

Re: [Django] #26400: QuerySet bulk_create method to handle generators to prevent loading all objects in memory at once

2016-03-23 Thread Django

#26400: QuerySet bulk_create method to handle generators to prevent loading all
objects in memory at once
-+-
 Reporter:  likeon   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_create  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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


Comment:

 I'm not sure this is worth including into Django, is there a reason you
 can't split your `bulk_create` calls into batches that fit into memory?

 {{{#!python
 from itertools import islice, chain

 # Taken from https://code.activestate.com/recipes/303279-getting-items-in-
 batches/
 def split(iterable, size):
 sourceiter = iter(iterable)
 while True:
 batchiter = islice(sourceiter, size)
 yield chain([batchiter.next()], batchiter)

 for batch in split(large_generator, 1):  # Adjust size to fit in
 memory
 MyModel.objects.bulk_create(batch)
 }}}

 You could even make this a manager method if required.

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

Re: [Django] #26399: Refactor SchemaEditor to facilitate Firebird handlings of column defaults

2016-03-23 Thread Django

#26399: Refactor SchemaEditor to facilitate Firebird handlings of column 
defaults
--+
 Reporter:  maxirobaina   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by timgraham):

 I don't know but the ticket description is too vague about what exactly
 should be done. I don't think anyone except a maintainer of or contributor
 to a third-party backend is in a good position to complete this task.

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

Re: [Django] #26351: Recommend enabling MySQL's STRICT_TRANS_TABLES to prevent silent truncation

2016-03-23 Thread Django

#26351: Recommend enabling MySQL's STRICT_TRANS_TABLES to prevent silent 
truncation
-+-
 Reporter:  zhebrak  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  get_or_create,   | Triage Stage:  Accepted
  max_length |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 I think having the check is a good mean to warn users that their MySQL
 configuration (being for an old MySQL or a MySQL with custom config) might
 interfere with their Django project running properly. Then, if the choice
 is deliberate, they can safely disable the warning.

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

[Django] #26400: QuerySet bulk_create method to handle generators to prevent loading all objects in memory at once

2016-03-23 Thread Django

#26400: QuerySet bulk_create method to handle generators to prevent loading all
objects in memory at once
--+-
Reporter: likeon| Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Database layer (models, ORM) |Version: master
Severity: Normal| Keywords: bulk_create
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+-
In my case I need to create huge amount of objects using bulk create
method with batch_size parameter.

The problem is I don't have enough memory to store all objects in a list.
Even if I transmit generator it would be converted to list anyway
(https://github.com/django/django/blob/1.9.4/django/db/models/query.py#L438).

I want to implement a feature to handle generators properly without
loading all objects in memory, but bulk_create method returns list of
objects as a result. That is unacceptable on large amounts of data.

How can I properly implement the method: create a new one or add a
parameter to actual method?

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

Re: [Django] #26399: Refactor SchemaEditor to facilitate Firebird handlings of column defaults

2016-03-23 Thread Django

Comment (by maxirobaina):

Hi timgraham,
Thanks for response, but is firebird the only one third-party backend
with this problem?
I don't think so, you can check in ![1] the need to override some privante
methods.
I named alter_column_default as an example but change nullability into
_alter_field method is a use case too.

![1] https://bitbucket.org/Manfre/django-

mssql/src/24ef16a3c7d0e157ebd26f96b561e812c5ebc07b/sqlserver_ado/schema.py?at=master
=file-view-default#schema.py-153

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

Re: [Django] #26391: JSONField empty_values

2016-03-23 Thread Django

#26391: JSONField empty_values
-+-
 Reporter:  sim1234  |Owner:
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  JSON JSONField   | Triage Stage:
  postgres forms |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

Re: [Django] #26399: Refactor SchemaEditor to facilitate Firebird handlings of column defaults (was: Migration refactoring - to facilitate third-party backend integration)

2016-03-23 Thread Django

#26399: Refactor SchemaEditor to facilitate Firebird handlings of column 
defaults
--+
 Reporter:  maxirobaina   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Old description:

> I humbly think that django migration api need a some refactoring to
> facilitate third-party backend integration.
>
> For instance, add_field method ![1], if I try to delete a default value
> on a column that does not have a previous default value definition I get
> an error on firebird, for which reason, I need to check if that field has
> got defined a default value before. Then I need to rewrite the whole
> add_field method too.
>
> Maybe a possible approach would be to have sql templates
> (sql_alter_column_default, sql_alter_column_no_default, etc) as methods,
> instead of class attributes.
>
> A disscusion about this en google groups
> https://groups.google.com/forum/#!topicsearchin/django-
> developers/migrations$20firebird/django-developers/yZ0IWGT2qZQ
>
> ![1]
> https://github.com/django/django/blob/master/django/db/backends/base/schema.py#L373

New description:

 I humbly think that django migration api need a some refactoring to
 facilitate third-party backend integration.

 For instance, the
 
[https://github.com/django/django/blob/14e6823d090a077d27f9f7caff2d505db31e55a7/django/db/backends/base/schema.py#L373
 SchemaEditor.add_field()] method, if I try to delete a default value on a
 column that does not have a previous default value definition I get an
 error on firebird, for which reason, I need to check if that field has got
 defined a default value before. Then I need to rewrite the whole add_field
 method too.

 Maybe a possible approach would be to have sql templates
 (`sql_alter_column_default`, `sql_alter_column_no_default`, etc.) as
 methods, instead of class attributes.

 [https://groups.google.com/d/topic/django-
 developers/yZ0IWGT2qZQ/discussion A discussion about this on django-
 developers].

--

Comment:

 It will be easiest to move forward with this if you can submit a pull
 request with a proposal.

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

Re: [Django] #26351: Recommend enabling MySQL's STRICT_TRANS_TABLES to prevent silent truncation

2016-03-23 Thread Django

#26351: Recommend enabling MySQL's STRICT_TRANS_TABLES to prevent silent 
truncation
-+-
 Reporter:  zhebrak  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  get_or_create,   | Triage Stage:  Accepted
  max_length |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I guess it's a good point about whether we should add the check now that
 MySQL is changing the default of `STRICT_TRANS_TABLES`. As Shai said,
 presumably going forward then, this check will only trigger for users
 configuring the database otherwise, so I wonder if it adds any value
 except for users of older versions of MySQL?

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

Re: [Django] #26058: Custom storage backend's not entirely decoupled from FileField

2016-03-23 Thread Django

#26058: Custom storage backend's not entirely decoupled from FileField
-+-
 Reporter:  Korijn   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  File |  Version:  1.9
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  custom storage   | Triage Stage:  Accepted
  filefield  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


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

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

[Django] #26399: Migration refactoring - to facilitate third-party backend integration

2016-03-23 Thread Django

#26399: Migration refactoring - to facilitate third-party backend integration
---+
Reporter: maxirobaina| Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations |Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
I humbly think that django migration api need a some refactoring to
facilitate third-party backend integration.

For instance, add_field method ![1], if I try to delete a default value on
a column that does not have a previous default value definition I get an
error on firebird, for which reason, I need to check if that field has got
defined a default value before. Then I need to rewrite the whole add_field
method too.

Maybe a possible approach would be to have sql templates
(sql_alter_column_default, sql_alter_column_no_default, etc) as methods,
instead of class attributes.

A disscusion about this en google groups
https://groups.google.com/forum/#!topicsearchin/django-
developers/migrations$20firebird/django-developers/yZ0IWGT2qZQ

![1]

https://github.com/django/django/blob/master/django/db/backends/base/schema.py#L373

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

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

Re: [Django] #25388: Allow disabling of all migrations during tests

2016-03-23 Thread Django

#25388: Allow disabling of all migrations during tests
---+
 Reporter:  MarkusH|Owner:  viciu
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"14e6823d090a077d27f9f7caff2d505db31e55a7" 14e6823]:
 {{{
 #!CommitTicketReference repository=""
 revision="14e6823d090a077d27f9f7caff2d505db31e55a7"
 Refs #25388 -- Used in-memory database in test_disable_migrations.
 }}}

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

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

Re: [Django] #26398: FieldFile open() ignores the mode, always opening the file for reading

2016-03-23 Thread Django

#26398: FieldFile open() ignores the mode, always opening the file for reading
-+-
 Reporter:  koterpillar  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  File |  Version:  1.8
  uploads/storage|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"a52a531a8b34f049fba11c3ee7b010af7534bf90" a52a531]:
 {{{
 #!CommitTicketReference repository=""
 revision="a52a531a8b34f049fba11c3ee7b010af7534bf90"
 Fixed #26398 -- Made FieldFile.open() respect its mode argument.
 }}}

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

Re: [Django] #26398: FieldFile open() ignores the mode, always opening the file for reading

2016-03-23 Thread Django

#26398: FieldFile open() ignores the mode, always opening the file for reading
-+-
 Reporter:  koterpillar  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  File |  Version:  1.8
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Ready for checkin


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

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

Re: [Django] #26293: Warnings regarding 404s logged for URLs missing trailing slashes

2016-03-23 Thread Django

#26293: Warnings regarding 404s logged for URLs missing trailing slashes
-+-
 Reporter:  jklaiho  |Owner:
 |  ieatkittens
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  CommonMiddleware | Triage Stage:  Accepted
  404 logging regression |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"ccc367fd48655b8709a01653b224e5ffa19c9dee" ccc367fd]:
 {{{
 #!CommitTicketReference repository=""
 revision="ccc367fd48655b8709a01653b224e5ffa19c9dee"
 [1.9.x] Fixed #26293 -- Fixed CommonMiddleware to process PREPEND_WWW and
 APPEND_SLASH independently.

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

Re: [Django] #26293: Warnings regarding 404s logged for URLs missing trailing slashes

2016-03-23 Thread Django

#26293: Warnings regarding 404s logged for URLs missing trailing slashes
-+-
 Reporter:  jklaiho  |Owner:
 |  ieatkittens
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  CommonMiddleware | Triage Stage:  Accepted
  404 logging regression |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"9390da7fb6e251eaa9a785692f987296cb14523f" 9390da7]:
 {{{
 #!CommitTicketReference repository=""
 revision="9390da7fb6e251eaa9a785692f987296cb14523f"
 Fixed #26293 -- Fixed CommonMiddleware to process PREPEND_WWW and
 APPEND_SLASH independently.
 }}}

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

Re: [Django] #24987: Remove test client login()'s hardcoded rejection of inactive users

2016-03-23 Thread Django

#24987: Remove test client login()'s hardcoded rejection of inactive users
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"107165c4b04f4e5a830a60b6c66b2e5d8fb1d242" 107165c]:
 {{{
 #!CommitTicketReference repository=""
 revision="107165c4b04f4e5a830a60b6c66b2e5d8fb1d242"
 Fixed #24987 -- Allowed inactive users to login with the test client.
 }}}

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

Re: [Django] #25232: Make the ModelBackend/RemoteUser authentication backends reject inactive users

2016-03-23 Thread Django

#25232: Make the ModelBackend/RemoteUser authentication backends reject inactive
users
--+
 Reporter:  OleLaursen|Owner:  sasha0
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"e0a3d937309a82b8beea8f41b17d8b6298da2a86" e0a3d937]:
 {{{
 #!CommitTicketReference repository=""
 revision="e0a3d937309a82b8beea8f41b17d8b6298da2a86"
 Fixed #25232 -- Made ModelBackend/RemoteUserBackend reject inactive users.
 }}}

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

Re: [Django] #26378: Allowed a left byte of zero in mixed IPv4/IPv6 validation

2016-03-23 Thread Django

#26378: Allowed a left byte of zero in mixed IPv4/IPv6 validation
-+-
 Reporter:  bshen|Owner:
 |  AmineYaiche
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"32c8e43ef1e859fa55af2f470a2a1120f51afabe" 32c8e43e]:
 {{{
 #!CommitTicketReference repository=""
 revision="32c8e43ef1e859fa55af2f470a2a1120f51afabe"
 Fixed #26378 -- Allowed a left byte of zero in mixed IPv4/IPv6 validation.
 }}}

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

Re: [Django] #26378: Allowed a left byte of zero in mixed IPv4/IPv6 validation (was: Incorrect behavior in GenericIPAddressField with protocol='both', unpack_ipv4=False)

2016-03-23 Thread Django

#26378: Allowed a left byte of zero in mixed IPv4/IPv6 validation
-+-
 Reporter:  bshen|Owner:
 |  AmineYaiche
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #8936: admin databrowse (read-only view-only permissions)

2016-03-23 Thread Django

#8936: admin databrowse (read-only view-only permissions)
---+--
 Reporter:  simon  |Owner:  PetrDlouhy
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by dekkers):

 * cc: jeroen@… (added)


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

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

Re: [Django] #16508: Provide real support for virtual fields

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

Re: [Django] #16508: Provide real support for virtual fields

Re: [Django] #16286: Models virtual fields and ModelForms

Re: [Django] #11909: Django 'eating up' method errors in templates

Re: [Django] #18607: ModelForms do not recognize DateTimeFields with auto_now=True

Re: [Django] #26393: Unable to filter against annotations in Manager with use_for_related_fields

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

Re: [Django] #26400: QuerySet bulk_create method to handle generators to prevent loading all objects in memory at once

Re: [Django] #26400: QuerySet bulk_create method to handle generators to prevent loading all objects in memory at once

Re: [Django] #26383: Incomplete/incorrect documentation about using wsgi with Apache when project using virtualenv

Re: [Django] #26400: QuerySet bulk_create method to handle generators to prevent loading all objects in memory at once

Re: [Django] #26397: Use custom managers on Foreign Key

Re: [Django] #26393: Unable to filter against annotations in Manager with use_for_related_fields (was: Unable to filter annotations across relationships.)

Re: [Django] #26400: QuerySet bulk_create method to handle generators to prevent loading all objects in memory at once

Re: [Django] #26399: Refactor SchemaEditor to facilitate Firebird handlings of column defaults

Re: [Django] #26351: Recommend enabling MySQL's STRICT_TRANS_TABLES to prevent silent truncation

[Django] #26400: QuerySet bulk_create method to handle generators to prevent loading all objects in memory at once

Re: [Django] #26399: Refactor SchemaEditor to facilitate Firebird handlings of column defaults

Re: [Django] #26391: JSONField empty_values

Re: [Django] #26399: Refactor SchemaEditor to facilitate Firebird handlings of column defaults (was: Migration refactoring - to facilitate third-party backend integration)

Re: [Django] #26351: Recommend enabling MySQL's STRICT_TRANS_TABLES to prevent silent truncation

Re: [Django] #26058: Custom storage backend's not entirely decoupled from FileField

[Django] #26399: Migration refactoring - to facilitate third-party backend integration

Re: [Django] #25388: Allow disabling of all migrations during tests

Re: [Django] #26398: FieldFile open() ignores the mode, always opening the file for reading

Re: [Django] #26398: FieldFile open() ignores the mode, always opening the file for reading

Re: [Django] #26293: Warnings regarding 404s logged for URLs missing trailing slashes

Re: [Django] #26293: Warnings regarding 404s logged for URLs missing trailing slashes

Re: [Django] #24987: Remove test client login()'s hardcoded rejection of inactive users

Re: [Django] #25232: Make the ModelBackend/RemoteUser authentication backends reject inactive users

Re: [Django] #26378: Allowed a left byte of zero in mixed IPv4/IPv6 validation

Re: [Django] #26378: Allowed a left byte of zero in mixed IPv4/IPv6 validation (was: Incorrect behavior in GenericIPAddressField with protocol='both', unpack_ipv4=False)

Re: [Django] #8936: admin databrowse (read-only view-only permissions)

35 matches

Site Navigation

Mail list logo

Footer information