Re: [Django] #24768: KeyError: u"Problem installing fixture '.json': u'manager'"

[Django]

#24768: KeyError: u"Problem installing fixture '.json': u'manager'"
-+-
 Reporter:  brian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by brian):

 Ok, this is getting a tad confusing. For some reason the following code

 {{{
 group.project
 }}}

 returns a RelatedManager instead of a Project (did I miss something in the
 release notes about this?). As in, the following code:

 {{{
 print("==", type(group), type(group.project))
 }}}

 displays:

 {{{
 ('==', , )
 }}}

 Group.project is a reverse relationship from a Project:

 {{{
 from mptt.models import MPTTModel
 class Project(MPTTModel):
 ...
 group = models.OneToOneField(Group)
 ...
 }}}

 So I believe group.project is suppose to return a Project, not a
 RelatedManager. I then pass the "project" to the Django function:

 {{{
 query = query.filter(machine_category__projectquota__project=project)
 }}}

 Which gets confused because it has the wrong type.

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

Re: [Django] #24768: KeyError: u"Problem installing fixture '.json': u'manager'"

[Django]

#24768: KeyError: u"Problem installing fixture '.json': u'manager'"
-+-
 Reporter:  brian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by brian):

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


Comment:

 I think the message is somewhat confusing; this isn't a problem with
 test_karaage.json, rather it an exception generated in response to a
 signal.

 Here is the relevant function call that generates the exception:

 {{{
 File
 "/home/brian/tree/django/karaage/karaage/karaage/datastores/__init__.py",
 line 472, in add_accounts_to_project
 query = query.filter(machine_category__projectquota__project=project)
 }}}

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

[Django] #24768: KeyError: u"Problem installing fixture '.json': u'manager'"

[Django]

#24768: KeyError: u"Problem installing fixture '.json': u'manager'"
--+
 Reporter:  brian |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Since upgrading to Django 1.8, my tests are failing to load the test data,
 and I don't see anything about this in the release notes:

 {{{
 ==
 ERROR: setUpClass (karaage.tests.test_people.PersonTestCase)
 --
 Traceback (most recent call last):
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/test/testcases.py", line 952, in setUpClass
 'database': db_name,
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 120, in call_command
 return command.execute(*args, **defaults)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 441, in execute
 output = self.handle(*args, **options)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/core/management/commands/loaddata.py", line 60, in handle
 self.loaddata(fixture_labels)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/core/management/commands/loaddata.py", line 90, in
 loaddata
 self.load_label(fixture_label)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/core/management/commands/loaddata.py", line 147, in
 load_label
 obj.save(using=self.using)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/core/serializers/base.py", line 173, in save
 models.Model.save_base(self.object, using=using, raw=True)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 747, in save_base
 update_fields=update_fields, raw=raw, using=using)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/dispatch/dispatcher.py", line 201, in send
 response = receiver(signal=self, sender=sender, **named)
   File "/home/brian/tree/django/karaage/karaage/karaage/people/models.py",
 line 508, in _project_membership_changed
 projectmembership__project=project,
   File "/home/brian/tree/django/karaage/karaage/karaage/people/models.py",
 line 644, in sync_members
 *[tmp_person_id for tmp_person_id in add_member_ids])
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py", line 973, in add
 self._add_items(self.source_field_name, self.target_field_name, *objs)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py", line 1105, in _add_items
 model=self.model, pk_set=new_ids, using=db)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/dispatch/dispatcher.py", line 201, in send
 response = receiver(signal=self, sender=sender, **named)
   File "/home/brian/tree/django/karaage/karaage/karaage/people/models.py",
 line 708, in _members_changed
 _add_person_to_group(person, group)
   File "/home/brian/tree/django/karaage/karaage/karaage/people/models.py",
 line 673, in _add_person_to_group
 add_accounts_to_project(a_list, group.project)
   File
 "/home/brian/tree/django/karaage/karaage/karaage/datastores/__init__.py",
 line 472, in add_accounts_to_project
 query = query.filter(machine_category__projectquota__project=project)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 679, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 697, in _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/db/models/sql/query.py", line 1301, in add_q
 clause, require_inner = self._add_q(where_part, self.used_aliases)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/db/models/sql/query.py", line 1328, in _add_q
 current_negated=current_negated, connector=connector,
 allow_joins=allow_joins)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/db/models/sql/query.py", line 1150, in build_filter
 value, lookups, used_joins = self.prepare_lookup_value(value, lookups,
 can_reuse, allow_joins)
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/db/models/sql/query.py", line 997, in prepare_lookup_value
 value = value()
   File "/tmp/python/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py", line 691, in __call__
 manager = getattr(self.model, kwargs.pop('manager'))
 

Re: [Django] #24760: Custom Aggregate: Return string (even if aggregate field is other type)

[Django]

#24760: Custom Aggregate: Return string (even if aggregate field is other type)
-+-
 Reporter:  psyonara |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (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 psyonara):

 Fantastic! I will use the new API then. Thanks, guys!

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

Re: [Django] #24767: Add GREATEST and LEAST Query Expressions

[Django]

#24767: Add GREATEST and LEAST Query Expressions
-+-
 Reporter:  Ian-Foote|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jarshwah):

 The postgres behaviour is the more useful IMO but it's also the odd one
 out. But that's why I suggested wrapping everything in a coalesce while
 providing opt outs.

 I don't think we'd be able to emulate other backend behaviour with
 postgres anyway without quite complex case expressions.

 So as far as I'm concerned, if you can provide an expression that works
 for postgres and emulates postgres on other backends (with an opt out),
 it'd be accepted into core. Happy to help if needed.

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

Re: [Django] #24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions

[Django]

#24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions
---+
 Reporter:  sephii |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by davidkrisch):

 I've attempted a fix for this and submitted a pull request:
 https://github.com/django/django/pull/4624
 This is my first attempt working with the docs, please be gentle. :-)

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

Re: [Django] #24767: Add GREATEST and LEAST Query Expressions

[Django]

#24767: Add GREATEST and LEAST Query Expressions
-+-
 Reporter:  Ian-Foote|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ian-Foote):

 For what it's worth, in my (current) use case the postgres handling of
 `null` is ideal. I don't know how typical it is though.

 My use case is annotating a model with a `last_updated` datetime. This is
 calculated from the `created` datetime of two related models:

 {{{
 queryset.annotate(
 last_update=Greatest(
 Max('comments__created'),
 Max('documents__created'),
 ),
 )
 }}}

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

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

Re: [Django] #24767: Add GREATEST and LEAST Query Expressions

[Django]

#24767: Add GREATEST and LEAST Query Expressions
-+-
 Reporter:  Ian-Foote|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

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


Comment:

 This is appropriate for core.

 Oracle supports GREATEST and LEAST, any null results in null.
 Sqlite has MAX(a, b, ..) and MIN(a, b, ..), any null results in null.
 Mysql has GREATEST and LEAST, any null results in null if version >=
 5.0.13 (django only supports >= 5.5 so no need to support both
 behaviours).

 I'm not certain how we should handle nulls. Should we allow backend
 specific behaviour (probably not, historically) or try to decide which way
 is "better" for Django.

 As a rough idea we could require a "if_null=" kwarg that would produce
 GREATEST( [COALESCE(arg, if_null) for args..] ).That'd produce the same
 value on all backends, I think, at the cost of extraneous sql. There
 should be an opt-out to get backend specific behaviour though.

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

Re: [Django] #24766: annotation with Q object filters results

[Django]

#24766: annotation with Q object filters results
-+-
 Reporter:  karyon   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

 * cc: josh.smeaton@… (added)
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #24760: Custom Aggregate: Return string (even if aggregate field is other type)

[Django]

#24760: Custom Aggregate: Return string (even if aggregate field is other type)
-+-
 Reporter:  psyonara |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (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 jarshwah):

 To provide a little more information - new aggregates allow you to set the
 output_field, so you get to decide the python type that comes back
 (CharField or TextField in your case).

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

[Django] #24767: Add GREATEST and LEAST Query Expressions

[Django]

#24767: Add GREATEST and LEAST Query Expressions
--+
 Reporter:  Ian-Foote |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Postgres supports [http://www.postgresql.org/docs/current/static
 /functions-conditional.html#FUNCTIONS-GREATEST-LEAST GREATEST and LEAST]
 query expressions. These could easily be implemented in django by
 subclassing the
 
[https://github.com/django/django/blob/master/django/db/models/functions.py#L8-L29
 Coalesce] query expression and changing the `function` attribute to
 `'GREATEST'` or `'LEAST'` respectively.

 I'm not sure which other databases support this, so perhaps this can only
 be added to `contrib.postgres`.

 If this isn't appropriate for core, I'm happy to create a small PyPI
 package instead.

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

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

Re: [Django] #24762: Proxy models with children which inherit from the proxy cannot select_related said children

[Django]

#24762: Proxy models with children which inherit from the proxy cannot
select_related said children
-+-
 Reporter:  kezabelle|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Unreviewed => Accepted


Comment:

 Managed to reproduce with the following models:

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

 class Concrete(models.Model):
pass

 class Proxy(Concrete):
 class Meta:
 proxy = True

 class Child(Concrete):
 pass
 }}}

 {{{#!python
 >>> Concrete.objects.select_related('child')
 []
 >>> Proxy.objects.select_related('child')
 FieldError: Invalid field name(s) given in select_related: 'child'.
 Choices are: (none)>
 }}}

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

Re: [Django] #24742: Can't runserver on a read-only database due to migrations

[Django]

#24742: Can't runserver on a read-only database due to migrations
-+
 Reporter:  delgiudices  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by akulakov):

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

Re: [Django] #24742: Can't runserver on a read-only database due to migrations

[Django]

#24742: Can't runserver on a read-only database due to migrations
-+
 Reporter:  delgiudices  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by akulakov):

 Adding a router that redirects migrations to a different db is exactly
 what I did for a recent project, - it works just fine.

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

[Django] #24766: annotation with Q object filters results

[Django]

#24766: annotation with Q object filters results
--+
 Reporter:  karyon|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I tried to annotate a query of UserProfiles with a boolean indicating
 whether each user is in a specific group or not. Besides the fact that i
 didn't find any obvious or easy to find solution for that, i encountered
 the following oddity:

 Any of these:


 {{{
 UserProfile.objects.annotate(is_member=Case(When(groups__name="Group
 name", then=Value(True)), default=Value(False),
 output_field=BooleanField()))
 }}}
 {{{
 UserProfile.objects.annotate(is_member=ExpressionWrapper(Q(groups__name="Group
 name"), output_field=BooleanField()))
 }}}

 returns only users that are in some group. Users without groups are not in
 the result. This was unexpected since i didn't request any filtering.

 The issue might be that both queries use inner joins. here's the sql:
 {{{
 'SELECT , CASE WHEN "auth_group"."name" = Group name THEN True ELSE
 False END AS "is_member" FROM "evaluation_userprofile" INNER JOIN
 "evaluation_userprofile_groups" ON ( "evaluation_userprofile"."id" =
 "evaluation_userprofile_groups"."userprofile_id" ) INNER JOIN "auth_group"
 ON ( "evaluation_userprofile_groups"."group_id" = "auth_group"."id" )'
 }}}
 {{{
 'SELECT , "auth_group"."name" = Group name AS "is_member" FROM
 "evaluation_userprofile" INNER JOIN "evaluation_userprofile_groups" ON (
 "evaluation_userprofile"."id" =
 "evaluation_userprofile_groups"."userprofile_id" ) INNER JOIN "auth_group"
 O
 N ( "evaluation_userprofile_groups"."group_id" = "auth_group"."id" )'
 }}}

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

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

Re: [Django] #24766: annotation with Q object filters results

[Django]

#24766: annotation with Q object filters results
-+-
 Reporter:  karyon   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by karyon):

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


Old description:

> I tried to annotate a query of UserProfiles with a boolean indicating
> whether each user is in a specific group or not. Besides the fact that i
> didn't find any obvious or easy to find solution for that, i encountered
> the following oddity:
>
> Any of these:
>

> {{{
> UserProfile.objects.annotate(is_member=Case(When(groups__name="Group
> name", then=Value(True)), default=Value(False),
> output_field=BooleanField()))
> }}}
> {{{
> UserProfile.objects.annotate(is_member=ExpressionWrapper(Q(groups__name="Group
> name"), output_field=BooleanField()))
> }}}
>
> returns only users that are in some group. Users without groups are not
> in the result. This was unexpected since i didn't request any filtering.
>
> The issue might be that both queries use inner joins. here's the sql:
> {{{
> 'SELECT , CASE WHEN "auth_group"."name" = Group name THEN True ELSE
> False END AS "is_member" FROM "evaluation_userprofile" INNER JOIN
> "evaluation_userprofile_groups" ON ( "evaluation_userprofile"."id" =
> "evaluation_userprofile_groups"."userprofile_id" ) INNER JOIN
> "auth_group" ON ( "evaluation_userprofile_groups"."group_id" =
> "auth_group"."id" )'
> }}}
> {{{
> 'SELECT , "auth_group"."name" = Group name AS "is_member" FROM
> "evaluation_userprofile" INNER JOIN "evaluation_userprofile_groups" ON (
> "evaluation_userprofile"."id" =
> "evaluation_userprofile_groups"."userprofile_id" ) INNER JOIN
> "auth_group" O
> N ( "evaluation_userprofile_groups"."group_id" = "auth_group"."id" )'
> }}}

New description:

 I tried to annotate a query of UserProfiles with a boolean indicating
 whether each user is in a specific group or not. Besides the fact that i
 didn't find any obvious or easy to find solution for that, i encountered
 the following oddity:

 Any of these:


 {{{
 UserProfile.objects.annotate(is_member=Case(When(groups__name="Group
 name", then=Value(True)), default=Value(False),
 output_field=BooleanField()))
 }}}
 {{{
 UserProfile.objects.annotate(is_member=ExpressionWrapper(Q(groups__name="Group
 name"), output_field=BooleanField()))
 }}}

 returns only users that are in some group. Users without groups are not in
 the result. This was unexpected since i didn't request any filtering.

 The issue might be that both queries use inner joins. here's the sql:
 {{{
 'SELECT , CASE WHEN "auth_group"."name" = Group name THEN True ELSE
 False END AS "is_member" FROM "evaluation_userprofile" INNER JOIN
 "evaluation_userprofile_groups" ON ( "evaluation_userprofile"."id" =
 "evaluation_userprofile_groups"."userprofile_id" ) INNER JOIN "auth_group"
 ON ( "evaluation_userprofile_groups"."group_id" = "auth_group"."id" )'
 }}}
 {{{
 'SELECT , "auth_group"."name" = Group name AS "is_member" FROM
 "evaluation_userprofile" INNER JOIN "evaluation_userprofile_groups" ON (
 "evaluation_userprofile"."id" =
 "evaluation_userprofile_groups"."userprofile_id" ) INNER JOIN "auth_group"
 ON ( "evaluation_userprofile_groups"."group_id" = "auth_group"."id" )'
 }}}

--

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

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

[Django] #24765: Calling flatten on a Context object fails in some cases

[Django]

#24765: Calling flatten on a Context object fails in some cases
-+
 Reporter:  poirier  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.8
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 For example, if one of the "dicts" in the Context object is actually a
 RequestContext.  Here's the `flatten` method in Django 1.8.1 (from
 django/template/context.py, line 101):

 {{{
 def flatten(self):
 """
 Returns self.dicts as one dictionary
 """
 flat = {}
 for d in self.dicts:
 flat.update(d)
 return flat
 }}}

 The line `flat.update(d)` fails because a RequestContext doesn't provide
 enough of a dictionary's interface to be used in an `update`, and you get
 errors like:

 {{{
 File ".../lib/python2.7/site-packages/django/template/context.py",
 line 107, in flatten
flat.update(d)
 ValueError: dictionary update sequence element #0 has length 6; 2 is
 required
 }}}

 It might be a little tricky to come up with a case where a Context ends up
 with a RequestContext in it. I believe in my case it's happening when a
 template uses an `inclusion_tag` type template tag that returns its
 `context` argument, possibly modified, e.g.:

 {{{
 @register.inclusion_tag('template_fragment.html',
 takes_context=True)
 def some_tag(context):
 context['thingy'] = 12
 return context
 }}}

 The return value gets pushed onto the Context. During testing, the Context
 ends up being returned in the list of Context objects in Response.context,
 which is where I was trying to call flatten on it.

 I don't know if the right fix is to make a RequestContext behave more like
 a dictionary, or to avoid pushing RequestContext objects onto a Context,
 or something else.  I will probably work around for now by forcing the
 return values from my inclusion_tags to be simple dictionaries.

 Context.flatten:
 
https://docs.djangoproject.com/en/1.8/ref/templates/api/#django.template.Context.flatten

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

Re: [Django] #24764: Using 'startswith' field lookup with F objects causes AttributeError

[Django]

#24764: Using 'startswith' field lookup with F objects causes AttributeError
-+-
 Reporter:  Ernest0x |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ernest0x):

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


Comment:

 Strangely, the following (using 'endswith' instead of 'startswith' field
 lookup) also works:

 {{{
 >>> objects = MyObject.objects.filter(name__endswith=F('description'))
 >>> objects
 [...]
 }}}

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

[Django] #24764: Using 'startswith' field lookup with F objects causes AttributeError

[Django]

#24764: Using 'startswith' field lookup with F objects causes AttributeError
--+
 Reporter:  Ernest0x  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 In Django 1.7.8, when using "startswith"  field lookup with F objects in
 the same query, the following AttributeError exception is raised:

 {{{
 >>> objects = MyObject.objects.filter(name__startswith=F('description'))
 >>> objects
 Traceback (most recent call last):
   File "", line 1, in 
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/query.py", line 116, in __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/query.py", line 141, in __iter__
 self._fetch_all()
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/query.py", line 966, in _fetch_all
 self._result_cache = list(self.iterator())
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/query.py", line 265, in iterator
 for row in compiler.results_iter():
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/sql/compiler.py", line 701, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/sql/compiler.py", line 776, in execute_sql
 sql, params = self.as_sql()
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/sql/compiler.py", line 110, in as_sql
 where, w_params = self.compile(self.query.where)
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/sql/compiler.py", line 81, in compile
 return node.as_sql(self, self.connection)
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/sql/where.py", line 106, in as_sql
 sql, params = qn.compile(child)
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/sql/compiler.py", line 81, in compile
 return node.as_sql(self, self.connection)
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/lookups.py", line 152, in as_sql
 rhs_sql = self.get_rhs_op(connection, rhs_sql)
   File "/path/to/virtualenv/lib/python3.4/site-
 packages/django/db/models/lookups.py", line 258, in get_rhs_op
 return connection.pattern_ops[self.lookup_name] % rhs
 AttributeError: 'DatabaseWrapper' object has no attribute 'pattern_ops'
 }}}

 The following (without the 'startswith' field lookup), however, works:
 {{{
 >>> objects = MyObject.objects.filter(name=F('description'))
 >>> objects
 [...]
 }}}

 Interestingly,  Django 1.8 does not have this bug.

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

Re: [Django] #24756: Unexpected behavior of ModelForm.save for fields with blank=False and overridden required attribute

[Django]

#24756: Unexpected behavior of ModelForm.save for fields with blank=False and
overridden required attribute
-+-
 Reporter:  bboogaard|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:  forms models save| Triage Stage:
  blank required |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bboogaard):

 All right, if it was an unintended effect of previous versions, I'll
 simply change my model field declarations and code logic. I thought the
 override was supposed to work the way I described (i.e. in principle
 required, but for some form classes not 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/067.83b0c648a6a014c54ecd719c10f5590d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24761: Cannot `pip install` the zip of master

[Django]

#24761: Cannot `pip install` the zip of master
-+-
 Reporter:  kezabelle|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Packaging|  Version:  master
 Severity:  Normal   |   Resolution:
 |  worksforme
 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 timgraham):

 [https://github.com/django/djangoproject.com/pull/465 PR] to update the
 download page.

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

Re: [Django] #24758: Incorrect docstring in Options.get_fields() (was: Options.get_fields() returns reverse fields)

[Django]

#24758: Incorrect docstring in Options.get_fields()
--+
 Reporter:  ezarowny  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Documentation |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:  _meta, documentation  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

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

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

Re: [Django] #24760: Custom Aggregate: Return string (even if aggregate field is other type)

[Django]

#24760: Custom Aggregate: Return string (even if aggregate field is other type)
-+-
 Reporter:  psyonara |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (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
 * needs_better_patch:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I'm not sure if there's a bug there, however, there is a new
 [https://docs.djangoproject.com/en/1.8/ref/models/expressions/ expressions
 API] in Django 1.8, and the code you referenced
 (`django.db.models.sql.aggregates`) is deprecated, so even if there is a
 bug there, it won't be fixed.

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

Re: [Django] #24758: Options.get_fields() returns reverse fields

[Django]

#24758: Options.get_fields() returns reverse fields
--+
 Reporter:  ezarowny  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Documentation |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:  _meta, documentation  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * component:  Database layer (models, ORM) => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Proposed update of the docstring:
 {{{
 #!diff
 diff --git a/django/db/models/options.py b/django/db/models/options.py
 index a76b934..eb09269 100644
 --- a/django/db/models/options.py
 +++ b/django/db/models/options.py
 @@ -755,9 +755,10 @@ class Options(object):

  def get_fields(self, include_parents=True, include_hidden=False):
  """
 -Returns a list of fields associated to the model. By default will
 only
 -return forward fields. This can be changed by enabling or
 disabling
 -field types using the parameters:
 +Returns a list of fields associated to the model. By default will
 +include forward and reverse fields, fields derived from
 inheritance,
 +but not hidden fields. The returned fields can be changed by
 using the
 +parameters:

  - include_parents: include fields derived from inheritance
  - include_hidden:  include fields that have a related_name that
 }}}

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

Re: [Django] #18392: Use utf8mb4 encoding with MySQL 5.5

[Django]

#18392: Use utf8mb4 encoding with MySQL 5.5
-+-
 Reporter:  EmilStenstrom|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  utf8mb4 mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aigarius):

 https://mathiasbynens.be/notes/mysql-utf8mb4 has more information on this.
 Ideally it would be wonderful if Django users could set an option and have
 Django migration backend generate all the code for the migration to the
 full utf8mb4 encoding for all databases, tables, columns and corresponding
 changes to all indexes as well. And then on next major version this option
 could become the new 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/071.2c043ab73222cdc223ccf36da69cd79d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

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

[Django]

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

Comment (by jpulec):

 For reference, I finally managed to run my tests against master. They
 pass, but I think the margin is pretty slim. The VM I do all my testing in
 has 2GB of RAM. On 1.8 and 1.8.1 my running test holds onto ~47% of my ram
 according to top. On master that number comes down closer to 37% so it
 runs for my use case.

 However, it still shows that running all those migrations on creation of a
 test database gobbles up all that ram and doesn't seem to release it right
 away.

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

Re: [Django] #24761: Cannot `pip install` the zip of master

[Django]

#24761: Cannot `pip install` the zip of master
-+-
 Reporter:  kezabelle|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Packaging|  Version:  master
 Severity:  Normal   |   Resolution:
 |  worksforme
 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 kezabelle):

 Based on the response on pip's ticket, it remains to be seen whether it
 '''can''' be fixed correctly. Additionally when I originally posited the
 question in `#pypa-dev`, the response given was that it was likely
 intentional that it only handle ASCII paths.

 Final addendum: if the zip is no longer a ''"safe"'' choice (across tools,
 O/Ses, locales, whatever) then the
 [https://www.djangoproject.com/download/ download page] probably ought to
 stop linking to the zipball.

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

Re: [Django] #24761: Cannot `pip install` the zip of master

[Django]

#24761: Cannot `pip install` the zip of master
-+-
 Reporter:  kezabelle|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Packaging|  Version:  master
 Severity:  Normal   |   Resolution:
 |  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 jezdez):

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


Comment:

 You can use the gzip'ed tarball that doesn't have the underlying problem
 while it's being fixed in pip:

 {{{
 pip install https://github.com/django/django/archive/master.tar.gz
 }}}

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

Re: [Django] #24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions

[Django]

#24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions
---+
 Reporter:  sephii |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by bmispelon):

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


Comment:

 Hi,

 I agree, we can probably improve on that.

 Thanks.

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

[Django] #24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions

[Django]

#24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions
---+
 Reporter:  sephii |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The docs are unclear about the DoesNotExist exception, which is only
 available as an attribute of model classes. Only ObjectDoesNotExist is in
 django.core.exceptions.

 
https://docs.djangoproject.com/en/1.8/ref/exceptions/#django.core.exceptions.DoesNotExist

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

Re: [Django] #24762: Proxy models with children which inherit from the proxy cannot select_related said children

[Django]

#24762: Proxy models with children which inherit from the proxy cannot
select_related said children
-+-
 Reporter:  kezabelle|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kezabelle):

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


Comment:

 I should add, changing the `InheritanceProxyChild` to inherit directly
 from `InheritanceProxyConcrete` rather than the `InheritanceProxy` doesn't
 seem to affect the issue.

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

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

[Django] #24762: Proxy models with children which inherit from the proxy cannot select_related said children

[Django]

#24762: Proxy models with children which inherit from the proxy cannot
select_related said children
--+
 Reporter:  kezabelle |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 This has only been briefly checked on `1.7`, `1.8` and
 `django-1.9.dev20150506223347` (`master`), and appears to silently pass on
 1.6 (because `select_related` previously didn't raise errors)

 Given the following models:
 {{{
 class InheritanceProxyConcrete(models.Model):
 pass

 class InheritanceProxy(InheritanceProxyConcrete):
 class Meta:
 proxy = True

 class InheritanceProxyChild(InheritanceProxy):
 pass
 }}}
 I would expect to be able to do the following:
 {{{
 >>> InheritanceProxy.objects.select_related('inheritanceproxychild')
 []
 # equating to something like
 SELECT "tests_inheritanceproxyconcrete"."id",
 "tests_inheritanceproxychild"."inheritanceproxyconcrete_ptr_id" FROM
 "tests_inheritanceproxyconcrete" LEFT OUTER JOIN
 "tests_inheritanceproxychild" ON ( "tests_inheritanceproxyconcrete"."id" =
 "tests_inheritanceproxychild"."inheritanceproxyconcrete_ptr_id" )
 }}}
 however, it transpires that it doesn't work:
 {{{
 >>>
 InheritanceProxyConcrete.objects.select_related('inheritanceproxychild')
 []
 >>> InheritanceProxy.objects.select_related('inheritanceproxychild')
 FieldError: Invalid field name(s) given in select_related:
 'inheritanceproxychild'. Choices are: (none)
 >>> InheritanceProxy.objects.select_related('inheritanceproxychild_ptr')
 FieldError: Invalid field name(s) given in select_related:
 'inheritanceproxychild_ptr'. Choices are: (none)
 }}}

 Furthering the quirkiness of the problem:
 {{{
 >>> dir(InheritanceProxy)
 ['DoesNotExist', 'MultipleObjectsReturned', '__class__', ...
 'inheritanceproxychild', ...]
 >>> InheritanceProxy.inheritanceproxychild
 
 }}}
 I've not worked with proxies much, and certainly not recently, so there's
 a good probability I'm making assumptions about what functionality should
 be provided based on an incomplete understanding of their use cases.

 I've not tested explicit `OneToOnes`, `ForeignKeys`, `ManyToManys` or
 `prefetch_related`, so the possibility remains that it is only implicit
 parentage `OneToOnes` which are affected.

 This stems from a ticket downstream in [https://github.com/carljm/django-
 model-utils/issues/168 django-model-utils] regarding using a Proxy model
 as the parent for auto-downcasting model instances (using it's
 `InheritanceManager`)

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

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

[Django] #24761: Cannot `pip install` the zip of master

[Django]

#24761: Cannot `pip install` the zip of master
--+
 Reporter:  kezabelle |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Packaging |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I'm pretty certain I used to be able to do this, though I'm not sure how
 long ago it was:
 {{{
 pip install https://github.com/django/django/archive/master.zip
 }}}
 which is ostensibly the quickest way to get a copy of `master` (currently
 targetting `1.9.x`) without doing a `git clone`, which takes a bunch of
 time. It's also the easiest way of setting up continuous integration
 against `master` (eg: I think one of the ways in which I previously used
 this was to have travis-ci build using it to check for upcoming failues)

 This no longer works, giving the following traceback:
 {{{
 Exception:
   Traceback (most recent call last):
 File "lib/python2.7/site-packages/pip/basecommand.py", line 246, in
 main
   status = self.run(options, args)
 File "lib/python2.7/site-packages/pip/commands/install.py", line 342,
 in run
   requirement_set.prepare_files(finder)
 File "lib/python2.7/site-packages/pip/req/req_set.py", line 345, in
 prepare_files
   functools.partial(self._prepare_file, finder))
 File "lib/python2.7/site-packages/pip/req/req_set.py", line 290, in
 _walk_req_to_install
   more_reqs = handler(req_to_install)
 File "lib/python2.7/site-packages/pip/req/req_set.py", line 487, in
 _prepare_file
   download_dir, do_download, session=self.session,
 File "lib/python2.7/site-packages/pip/download.py", line 827, in
 unpack_url
   session,
 File "lib/python2.7/site-packages/pip/download.py", line 677, in
 unpack_http_url
   unpack_file(from_path, location, content_type, link)
 File "lib/python2.7/site-packages/pip/utils/__init__.py", line 630, in
 unpack_file
   flatten=not filename.endswith('.whl')
 File "lib/python2.7/site-packages/pip/utils/__init__.py", line 510, in
 unzip_file
   leading = has_leading_dir(zip.namelist()) and flatten
 File "lib/python2.7/site-packages/pip/utils/__init__.py", line 224, in
 has_leading_dir
   prefix, rest = split_leading_dir(path)
 File "lib/python2.7/site-packages/pip/utils/__init__.py", line 208, in
 split_leading_dir
   path = str(path)
   UnicodeEncodeError: 'ascii' codec can't encode character u'\u2297' in
 position 60: ordinal not in range(128)
 }}}
 the `path` at the point of error is:
 {{{
 path = u'django-
 master/tests/staticfiles_tests/apps/test/static/test/\u2297.txt'
 }}}
 I raised a bug against [https://github.com/pypa/pip/issues/2729 pip
 itself] assuming that the lack of unicode handling was a problem in pip,
 but a response suggests that there is no safe fix for their end (because
 of how zip works?) and that Django ought to create & destroy such test
 files as part of the test case, rather than statically embedded on a known
 path, which seems sensible enough, if it's feasible in the test cases
 which touch such files.

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

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