Re: [Django] #15367: Improved Auth Password Hashing

[Django]

#15367: Improved Auth Password Hashing
-+-
 Reporter:  poswald  |Owner:  PaulM
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:
 Severity:  Release blocker  |   Resolution:
 Keywords:  password, hash,  | Triage Stage:  Accepted
  hashing, bcrypt, scrypt, pbkdf2,   |  Needs documentation:  1
  sha2, sha1 |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by poswald):

 * cc: poswald (added)


Comment:

 There has been some focus on closing down 1.4 and releasing an alpha. As a
 user, I absolutely want this code to go into that release. Is this ready
 for testing? If so, I'm willing to apply it and give it a shot on
 upgrading some data dumps of my projects. I note one thing I think we are
 missing is a description of how to use this and information about backward
 compatibility for the release notes.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11850: Intermediate model order not applied to related model

[Django]

#11850: Intermediate model order not applied to related model
-+-
 Reporter:  pielgrzym|Owner:  bastih
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  model ordering,  |  Needs documentation:  0
  many to many, through  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by FunkyBob):

 * cc: FunkyBob (added)
 * keywords:  model orderin, many to many => model ordering, many to many,
 through
 * ui_ux:   => 0
 * easy:   => 0


Comment:

 It would be nice if the Many-to-Many field were ordered by the through
 model's odering [if set].  Comment 4 above only gets you the intermediate
 model, whereas I want to get a set of models at the other end of the M2M.
 I would formulate a patch to do this, but the ORM code is deep magic to me
 -- I wouldn't know where to start :)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17314: Error creating nested query with GeoDjango's spatial filters

[Django]

#17314: Error creating nested query with GeoDjango's spatial filters
--+
 Reporter:  jpk   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 With the following models:
 {{{
 from django.contrib.gis.db import models

 class Spot(models.Model):
 objects = models.GeoManager()
 location = models.PointField(srid=4326, spatial_index=True)

 def __unicode__(self):
 return "id: %s" % self.id

 class Property(models.Model):
 objects = models.GeoManager()
 spot = models.ForeignKey(Spot)

 def __unicode__(self):
 return "belonging to Spot %s" % self.spot_id
 }}}

 And using, for example, the following filters:
 {{{
 spots = Spot.objects.filter(location__contained=Polygon((
 (-180,90),(180,90),(180,0),(-180,0),(-180,90)  )) )
 props = Property.objects.filter(spot__in=spots)
 }}}

 And trying to iterate over props, causes the following error:
 {{{
 >>> for p in props:
 ... print p
 ...
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/pymodules/python2.7/django/db/models/query.py", line 107,
 in _result_iter
 self._fill_cache()
   File "/usr/lib/pymodules/python2.7/django/db/models/query.py", line 772,
 in _fill_cache
 self._result_cache.append(self._iter.next())
   File "/usr/lib/pymodules/python2.7/django/db/models/query.py", line 273,
 in iterator
 for row in compiler.results_iter():
   File "/usr/lib/pymodules/python2.7/django/db/models/sql/compiler.py",
 line 680, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/usr/lib/pymodules/python2.7/django/db/models/sql/compiler.py",
 line 725, in execute_sql
 sql, params = self.as_sql()
   File "/usr/lib/pymodules/python2.7/django/db/models/sql/compiler.py",
 line 68, in as_sql
 where, w_params = self.query.where.as_sql(qn=qn,
 connection=self.connection)
   File "/usr/lib/pymodules/python2.7/django/db/models/sql/where.py", line
 92, in as_sql
 sql, params = child.as_sql(qn=qn, connection=connection)
   File "/usr/lib/pymodules/python2.7/django/db/models/sql/where.py", line
 95, in as_sql
 sql, params = self.make_atom(child, qn, connection)
   File
 "/usr/lib/pymodules/python2.7/django/contrib/gis/db/models/sql/where.py",
 line 50, in make_atom
 return super(GeoWhereNode, self).make_atom(child, qn, connection)
   File "/usr/lib/pymodules/python2.7/django/db/models/sql/where.py", line
 166, in make_atom
 if (len(params) == 1 and params[0] == '' and lookup_type == 'exact'
   File
 
"/usr/lib/pymodules/python2.7/django/contrib/gis/db/backends/postgis/adapter.py",
 line 24, in __eq__
 return (self.ewkb == other.ewkb) and (self.srid == other.srid)
 AttributeError: 'str' object has no attribute 'ewkb'
 }}}
 A full paste of me reproducing the error in the python shell here:
 http://pastebin.com/fBySTUD0  I also have a little test project I used to
 reproduce this.  I can post it somewhere if needed.

 Doing the same thing without using a spatial filter works fine.  Being new
 to django, I assumed I was doing something wrong, but after a conversation
 in the #geodjango channel, it was concluded that this is probably a bug in
 the ORM.  There's a paste of that conversation here:
 http://pastebin.com/bwZYVa6j

 System information (everything installed from ubuntu's packages):
  * Ubuntu 11.10
  * Python 2.7.2
  * Django 1.3.0
  * PostgreSQL 9.1.1
  * PostGIS 1.5.3

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16763: code.djangoproject.com won't stop emailing me (doesn't abide by cc/reporter/etc)

[Django]

#16763: code.djangoproject.com won't stop emailing me (doesn't abide by
cc/reporter/etc)
-+-
 Reporter:  ferringb |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Djangoproject.com|  Version:
  Web site   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Replying to [comment:17 mlavin]:
 > This rant is very colorful but I believe you are incorrect in your
 understanding of the law in this case. While I'm not a lawyer, CAN-SPAM
 does not apply to transactional content which the Trac updates would fall
 under. The law only applies to commercial messages as defined by
 >
 > > any electronic mail message the primary purpose of which is the
 commercial advertisement or promotion of a commercial product or service
 >
 > which Trac ticket update emails are clearly not. Your frustration is
 understandable but your subtle threats against the DSF are not necessary
 nor based on fact.
 >
 > Read the CAN-SPAM rule here: http://ecfr.gpoaccess.gov/cgi/t/text/text-
 
idx?c=ecfr=a273032f4545305b53bd3b788739f586=/ecfrbrowse/Title16/16cfr316_main_02.tpl

 Shush.  It was attempted motivation/shaming, although I should've expected
 someone would look up the letter of the law rather than just fixing the
 damn configuration ;)

 Also, must admit I find it rather interesting that rather than fixing it,
 or pruning my address as was offered (and aparently never followed through
 with, useful, that), instead someone goes and bans my primary account from
 django dev ml- roughly, w/in the last hour or two.  While I've not had
 much intent on posting to the ml (did have interest to see if a discussion
 about this had started however), but I find it rather entertaining- no
 problems spamming me, but y'all go to the trouble of banning my account?
 Double standard there, albeit a funny one.

 Pretty easy to fix this; if devs want to be cc'd on everything, either
 create a global list trac mails and have people subscribe to that, or
 collect the names and add them to existing tickets cc; this covers the
 reasoning given thus far.

 Then flip the setting off.  Really is that easy, and much more productive
 than banning, arguing over CAN-SPAM, or generally leaving the setting in
 place to piss further people off.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16763: code.djangoproject.com won't stop emailing me (doesn't abide by cc/reporter/etc)

[Django]

#16763: code.djangoproject.com won't stop emailing me (doesn't abide by
cc/reporter/etc)
-+-
 Reporter:  ferringb |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Djangoproject.com|  Version:
  Web site   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by mlavin):

 This rant is very colorful but I believe you are incorrect in your
 understanding of the law in this case. While I'm not a lawyer, CAN-SPAM
 does not apply to transactional content which the Trac updates would fall
 under. The law only applies to commercial messages as defined by

 > any electronic mail message the primary purpose of which is the
 commercial advertisement or promotion of a commercial product or service

 which Trac ticket update emails are clearly not. Your frustration is
 understandable but your subtle threats against the DSF are not necessary
 nor based on fact.

 Read the CAN-SPAM rule here: http://ecfr.gpoaccess.gov/cgi/t/text/text-
 
idx?c=ecfr=a273032f4545305b53bd3b788739f586=/ecfrbrowse/Title16/16cfr316_main_02.tpl

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16763: code.djangoproject.com won't stop emailing me (doesn't abide by cc/reporter/etc)

[Django]

#16763: code.djangoproject.com won't stop emailing me (doesn't abide by
cc/reporter/etc)
-+-
 Reporter:  ferringb |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Djangoproject.com|  Version:
  Web site   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by anonymous):

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


Comment:

 Reopening.  I'm still getting spammed, and frankly this is getting pretty
 fucking ridiculous I even need to lecture you folk about not spamming
 people.

 Summarizing; per comment #16763:3, y'all want it such that touching a bug
 /ever/ means you get notified /forever/.  This is not a limitation in
 trac, this is an intentional configuration setting (always_notify_updater
 = true per comment #16763:6, and knowing that this is /not/ tracs default
 behavior).  Basically, spamming everyone for the benefit of people who
 can't be bothered to get off their ass and use a CC field properly.

 Combine this w/ the lack of an actual opt-out method (per regulations,
 page is required, or opt out link in the email; this page no longer
 qualifies going by the fact I'm /still/ getting fucking email), puts this
 pretty squarely in the realm of violating the US CAN-SPAM act.
 Interesting note, django foundation is US based... hmmm. legally bound are
 we?  Same for adrian.

 Seriously, I shouldn't have to point this shit out, point out the laws
 y'all are bound by, nor even consider targeted multiplicative forwards to
 annoy people into cleaning it up.  Do it correctly rather than half assing
 it and I'll shut up, and likely so shall others.  No illwill intended, but
 y'all need to sort this properly.

 ~ferringb (commenting anonymously since using an account on this bug will
 result in me getting ongoing spam).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #4102: Allow UPDATE of only specific fields in model.save()

[Django]

#4102: Allow UPDATE of only specific fields in model.save()
-+-
 Reporter:  Collin Grady |Owner:  cgrady
   |   Status:  new
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:  update fields sql|  Patch needs improvement:  1
  row table modified |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Kronuz):

 * cc: Kronuz (added)


Comment:

 With the current patch in multitable inheritance, when I modify an already
 existing object and save it, it only saves data to the parent. This
 happens because `_reset_modified_attrs()` is called during the topmost
 first parent's save_base() call and further updates are ignored since
 `_modified_attrs` no longer have anything after that. I'm attaching a new
 patch to fix this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
 Reporter:  Manfred Wassmann |Owner:  jgelens
   |   Status:  assigned
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  dceu2011 |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by jgelens):

 @ akaariai  Thanks for your thorough comments :)
 I fixed your first point about the join removal when calling distinct()
 multiple times.
 It now applies the distinct in the compiler. This didn't fix the problem
 however, so I had to unref the fields manually, which is working great.

 As you've said, the combination of a annotation and an distinct on is
 probably a use case which is never used. This is certainly not a blocker
 for this feature.

 Anyways, this patch took a lot of time. I hope all the bugs were fixed :-D

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17312: Testing examples should use django.utils.TestCase

[Django]

#17312: Testing examples should use django.utils.TestCase
--+
 Reporter:  jcspray@… |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  SVN
 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 ptone):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16047: postgresql_psycopg2 never restores autocommit mode when leaving transaction management

[Django]

#16047: postgresql_psycopg2 never restores autocommit mode when leaving 
transaction
management
-+-
 Reporter:  brodie   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  psycopg2 autocommit  |  Needs documentation:  0
  transactions   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by dikbrouwer):

 * cc: dick@… (added)
 * ui_ux:   => 0


Comment:

 Hi brodie, any updates on this patch? It seems to be critical to anybody
 who is using manual transaction management and PGBouncer.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17312: Testing examples should use django.utils.TestCase

[Django]

#17312: Testing examples should use django.utils.TestCase
-+-
 Reporter:  jcspray@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by krw1243):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17305: Cache middleware keys too difficult to customize

[Django]

#17305: Cache middleware keys too difficult to customize
-+-
 Reporter:  subsume  |Owner:  subsume
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Core (Cache system)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by subsume):

 Also I think there's an oversight in the Fetch middleware:

 
https://code.djangoproject.com/browser/django/trunk/django/middleware/cache.py#L133

 Perhaps someone can inform me if I am being ignorant, but the Fetch
 middleware seems to make no reference to
 settings.CACHE_MIDDLEWARE_UNAUTHENTICATED_ONLY before creating a
 connection to cache and checking for the value. The only reason it happens
 to work in the current setup is because the Update happens to skip
 creation of a key. So even though I have explicitly set UNUAUTH=True, when
 I use a key that isn't generated by the above utils, it will result in my
 auth users getting a cached version.

 Began ticket about this #17313

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17313: Cache FetchMiddleware checks cache for auth despite UNAUTH_ONLY=True

[Django]

#17313: Cache FetchMiddleware checks cache for auth despite UNAUTH_ONLY=True
-+
 Reporter:  subsume  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Cache system)  |Version:
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 
https://code.djangoproject.com/browser/django/trunk/django/middleware/cache.py#L133

 The Fetch middleware makes no explicit check of its own to
 settings.CACHE_MIDDLEWARE_UNAUTHENTICATED_ONLY. This results in a check to
 the cache for the key. Currently, the only way it happens to work is
 because the key created by django.utils.cache.get_cache_key happens to
 cause a miss. If you use a simpler key which doesn't take into account the
 users session, the key will not miss and authenticated users will get a
 cached version despite the rather unambiguous setting.

 Related to #17305 in the sense that this is another stumbling block for
 people wanting to customize the Cache Middlewares.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17311: bool(queryset) calls __len__ instead of __nonzero__

[Django]

#17311: bool(queryset) calls __len__ instead of __nonzero__
-+-
 Reporter:  adamnelson   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by lukeplant):

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


Comment:

 Almost everything about this bug report is incorrect, I'm afraid :-) .
 When running `if queryset`, `__nonzero__` is called, not `__len__` (this
 is Python behaviour over which we have no control. It is true that
 `__len__` is called indirectly in some situations in trunk, but not
 always).  The special attribute `__len__` does not call `count()`. Finally
 `__nonzero__` already exists and does not and should not call `exists()`.

 The current behaviour is exactly as intended. The reason for this is to
 make the behaviour 1) predictable, and 2) behave nicely with several
 common usage patterns, such as:

 {{{
 #!python
 if queryset:
for obj in queryset
 }}}

 In short, the rule is you only get special queries (like `exists()` and
 `count()`) if you ask for them, because we cannot predict if you are going
 to want to use the `QuerySet`'s result cache or not. All other constructs
 like `bool()` and `len()` and `iter()` evaluate the same query, and
 populate/use the same result cache where possible.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17312: Testing examples should use django.utils.TestCase

[Django]

#17312: Testing examples should use django.utils.TestCase
--+
 Reporter:  jcspray@… |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The 'Testing Django applications page'
 (https://docs.djangoproject.com/en/dev/topics/testing/) gives many
 examples of tests using unittest2.TestCase directly rather than
 django.test.TestCase.

 For the DB to be reset between tests it is essential to use
 django.test.TestCase, and that is not made at all obvious in this
 documentation.
  * At least: a prominent warning should be present about the fact that DB
 side effects are possible when using unittest2.TestCase
  * Preferably: the examples should use django.utils.TestCase since it is a
 safer 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10060: Multiple table annotation failure

[Django]

#10060: Multiple table annotation failure
-+
 Reporter:  svsharma@…   |Owner:
 Type:  Bug  |   Status:  new
Component:  ORM aggregation  |  Version:  SVN
 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 lukeplant):

 Replying to [comment:31 anonymous]:
 > Is this something that will ever be fixed?

 It will only ever get fixed if someone cares enough to write a patch
 (complete with tests). I think at this point a patch which threw an
 exception for the failure case would be accepted. Obviously ideally this
 would be replaced with a proper fix at some point.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17281: AdminErrorHandler silently fails if the log message contains newlines

[Django]

#17281: AdminErrorHandler silently fails if the log message contains newlines
--+
 Reporter:  russellm  |Owner:  elbarto
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:
 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 elbarto):

 * owner:  nobody => elbarto


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17193: Send templated email.

[Django]

#17193: Send templated email.
-+---
 Reporter:  tomchristie  |Owner:  julianapplebaum
 Type:  New feature  |   Status:  assigned
Component:  Core (Mail)  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---

Comment (by tevans.uk@…):

 I have a few doubts about how this has been designed. With both html and
 plain 'templates' actually just being blocks of a single template, it is
 not possible to use template inheritance to design consistent emails,
 which is a common use of the template system. Without this, styles would
 need to be replicated across multiple templates.

 In our send_mail wrapper at $JOB, we allow the user to pass in the stub
 name of a template. The utility then attempts to render the templates
 stub+'.html' and stub+'.txt', and uses the results of these to determine
 whether we send a text/plain, text/html or multipart/alternative.

 Instead of extracting the subject from a template, we allow it to be
 passed in directly. We also add a language argument, which is used to
 activate the appropriate translation prior to rendering the emails, or
 coercing the subject to unicode. This allows us to send fully translated
 emails appropriate for the user receiving the email - which may not be the
 same as the language currently activated, if there is any, or the language
 that has been activated for the current view.

 Cheers

 Tom (one of these days I'll remember my trac login)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5423: "dumpdata" should stream output one row at a time

[Django]

#5423: "dumpdata" should stream output one row at a time
-+-
 Reporter:  adrian   |Owner:  ramiro
 Type:  New feature  |   Status:  assigned
Component:  Core |  Version:  SVN
  (Serialization)|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  dumpdata fixtures|  Needs documentation:  0
  memory |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Cerin):

 * cc: Cerin (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13252: Use the natural key instead of the primary key when serializing

[Django]

#13252: Use the natural key instead of the primary key when serializing
-+-
 Reporter:  SmileyChris  |Owner:
 Type:  New feature  |  mtredinnick
Component:  Core |   Status:  reopened
  (Serialization)|  Version:  SVN
 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 Cerin):

 * cc: Cerin (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17311: bool(queryset) calls __len__ instead of __nonzero__

[Django]

#17311: bool(queryset) calls __len__ instead of __nonzero__
--+
 Reporter:  adamnelson|  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When testing the boolean value of a queryset (i.e. running "if queryset:
 ..."), the special attribute __len__ is called which calls count() in the
 ORM.  It should use the special attribute __nonzero__ which would call the
 exists() method in the ORM.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10060: Multiple table annotation failure

[Django]

#10060: Multiple table annotation failure
-+
 Reporter:  svsharma@…   |Owner:
 Type:  Bug  |   Status:  new
Component:  ORM aggregation  |  Version:  SVN
 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 anonymous):

 Is this something that will ever 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17163 - django/trunk/docs/releases

[noreply]

Author: lukeplant
Date: 2011-11-29 06:20:23 -0800 (Tue, 29 Nov 2011)
New Revision: 17163

Modified:
   django/trunk/docs/releases/1.4.txt
Log:
Punctuation fix in the 1.4 release notes

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-11-29 12:50:10 UTC (rev 17162)
+++ django/trunk/docs/releases/1.4.txt  2011-11-29 14:20:23 UTC (rev 17163)
@@ -56,7 +56,7 @@
 
 
 This method allows for more efficient creation of multiple objects in the ORM.
-It can provide significant performance increases if you have many objects,
+It can provide significant performance increases if you have many objects.
 Django makes use of this internally, meaning some operations (such as database
 setup for test suites) have seen a performance benefit as a result.
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17310: Delete an object linked to a GenericForeignKey

[Django]

#17310: Delete an object linked to a GenericForeignKey
-+-
 Reporter:  Natim|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.3
  contrib.contenttypes   |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kmtracey):

 * status:  reopened => closed
 * resolution:   => invalid


Comment:

 If you are suggesting that !GenericRelations should be validated and raise
 an exception that would more clearly indicate the problem here, that is
 covered by #3055. The base problem here was that the !GenericRelation was
 defined incorrectly, that's not a Django bug, so re-closing this as
 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17307: Admin.site.register() upgrade

[Django]

#17307: Admin.site.register() upgrade
---+--
 Reporter:  admin@…|Owner:  belegnar
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by lukeplant):

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


Comment:

 You can use locals() to get all objects in local scope.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10868: _destroy_test_db exposes the production database to possibly destructive actions from the unit tests

[Django]

#10868: _destroy_test_db exposes the production database to possibly destructive
actions from the unit tests
-+-
 Reporter:  ovidiu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:
 Severity:  Release blocker  |   Resolution:
 Keywords:  django.test  | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by akaariai):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 The problem here is that the settings_dict is shared between threads. This
 means that after `self.connection.settings_dict['NAME'] =
 old_database_name` (line 323 in creation.py) every new connection taken by
 different threads will access the production database, not the test
 database. I don't know how likely this is to happen. You would need a
 thread taking a _new_ connection.

 For potential fixes: on line 323, do a copy of the settings dict, then set
 the old database name. self.connection is threading.local subclass, so if
 the settings_dict is copied, the change affects only current thread (the
 one doing the drop database). Changing directly the settings dict will do
 the change for every thread, as the passed in settings_dict is the same
 instance for every thread. But I think Django does want to restore the
 environment to the previous state after tests have ran, and thus, if a
 thread wakes up at a later point (after the test db has been dropped) and
 takes a new connection, it will be directed to the production database. So
 3 more solutions:
   - Do not restore the environment
   - The user should make sure the threads he has created are not running
 after the test suite is completed (in other words, mark as wont fix).
   - Check alive threads before dropping the test database. If there are
 more alive threads than the main thread, bail out. I think this is safest
 way to go forward. Anyways you should not have any test threads running
 after the test suite has completed. You would possibly want to check the
 running thread names before tests, and after test and see that they match,
 so that if there are threads running in the background before the test,
 you would still be able to run tests.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17162 - django/trunk/django/db/models

[noreply]

Author: lukeplant
Date: 2011-11-29 04:50:10 -0800 (Tue, 29 Nov 2011)
New Revision: 17162

Modified:
   django/trunk/django/db/models/query.py
Log:
Small code clarification in prefetch_related code using better variable names

Modified: django/trunk/django/db/models/query.py
===
--- django/trunk/django/db/models/query.py  2011-11-29 12:01:38 UTC (rev 
17161)
+++ django/trunk/django/db/models/query.py  2011-11-29 12:50:10 UTC (rev 
17162)
@@ -1576,12 +1576,11 @@
 done_lookups = set() # list of lookups like foo__bar__baz
 done_queries = {}# dictionary of things like 'foo__bar': [results]
 
-manual_lookups = list(related_lookups)
 auto_lookups = [] # we add to this as we go through.
 followed_descriptors = set() # recursion protection
 
-related_lookups = itertools.chain(manual_lookups, auto_lookups)
-for lookup in related_lookups:
+all_lookups = itertools.chain(related_lookups, auto_lookups)
+for lookup in all_lookups:
 if lookup in done_lookups:
 # We've done exactly this already, skip the whole thing
 continue

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17161 - in django/trunk/docs: internals releases

[noreply]

Author: lukeplant
Date: 2011-11-29 04:01:38 -0800 (Tue, 29 Nov 2011)
New Revision: 17161

Modified:
   django/trunk/docs/internals/deprecation.txt
   django/trunk/docs/releases/1.4.txt
Log:
Clarified release note about the removal of 'mixin' parameter to Storage.open, 
and added a note in the deprecation timeline.

Modified: django/trunk/docs/internals/deprecation.txt
===
--- django/trunk/docs/internals/deprecation.txt 2011-11-28 19:41:58 UTC (rev 
17160)
+++ django/trunk/docs/internals/deprecation.txt 2011-11-29 12:01:38 UTC (rev 
17161)
@@ -114,7 +114,10 @@
   beyond that of a simple ``TextField`` since the removal of oldforms.
   All uses of ``XMLField`` can be replaced with ``TextField``.
 
+* The undocumented ``mixin`` parameter to the ``open()`` method of
+  ``django.core.files.storage.Storage`` (and subclasses) will be removed.
 
+
 1.5
 ---
 

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-11-28 19:41:58 UTC (rev 17160)
+++ django/trunk/docs/releases/1.4.txt  2011-11-29 12:01:38 UTC (rev 17161)
@@ -780,9 +780,10 @@
 ~~
 
 The ``open`` method of the base Storage class took an obscure parameter
-``mixin`` which allowed to dynamically change the base classes of the
-returned file object. In the rare case you relied on the `mixin` parameter,
-you can easily achieve the same by overriding the `open` method, e.g.::
+``mixin`` which allowed you to dynamically change the base classes of the
+returned file object. This has been removed. In the rare case you relied on the
+`mixin` parameter, you can easily achieve the same by overriding the `open`
+method, e.g.::
 
 from django.core.files import File
 from django.core.files.storage import FileSystemStorage

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13021: Allowing models to influence QuerySet.update

[Django]

#13021: Allowing models to influence QuerySet.update
-+-
 Reporter:  seveas   |Owner:  seveas
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  update   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by lukeplant):

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


Comment:

 For the reasons given by Jacob in that thread, I'm going to WONTFIX this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17270: methods of the manager on subqueries QuerySet objects

[Django]

#17270: methods of the manager on subqueries QuerySet objects
-+-
 Reporter:  Wojciech Banaś   |Owner:  fizista@…
  |   Status:  new
 Type:  New feature  |  Version:
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:  queryset manager |  Needs documentation:  1
  Extends|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by lukeplant):

 * easy:  1 => 0


Comment:

 For reference, an alternative solution is here:
 https://github.com/zacharyvoase/django-qmixin

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17310: Delete an object linked to a GenericForeignKey

[Django]

#17310: Delete an object linked to a GenericForeignKey
-+-
 Reporter:  Natim|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:   |  Version:  1.3
  contrib.contenttypes   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natim):

 * status:  closed => reopened
 * resolution:  invalid =>


Comment:

 Maybe instead of taking the generic names, it should try if the name
 exists and raise an Exception.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17310: Delete an object linked to a GenericForeignKey

[Django]

#17310: Delete an object linked to a GenericForeignKey
-+-
 Reporter:  Natim|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.3
  contrib.contenttypes   |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Natim):

 Don't forget to override the fields in the GenericRelation.

 {{{
 class Award(models.Model):
 name = models.CharField(max_length=25)
 app_object_id = models.PositiveIntegerField()
 app_content_type = models.ForeignKey(ContentType)
 content_object = generic.GenericForeignKey('app_content_type',
 'app_object_id')

 class Person(models.Model):
 name = models.CharField(max_length=25)
 awards = generic.GenericRelation(Award,
  content_type_field=
 'app_content_type',
  object_id_field='app_object_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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17310: Delete an object linked to a GenericForeignKey

[Django]

#17310: Delete an object linked to a GenericForeignKey
-+-
 Reporter:  Natim|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.3
  contrib.contenttypes   |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natim):

 * status:  new => closed
 * resolution:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17310: Delete an object linked to a GenericForeignKey

[Django]

#17310: Delete an object linked to a GenericForeignKey
-+-
 Reporter:  Natim|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.3
  contrib.contenttypes   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natim):

 * component:  Database layer (models, ORM) => contrib.contenttypes


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17310: Delete an object linked to a GenericForeignKey

[Django]

#17310: Delete an object linked to a GenericForeignKey
-+-
 Reporter:  Natim|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natim):

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


Comment:

 As you can see by running the patched test :


 {{{
 ./runtests.py --settings=test_sqlite delete_regress
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 ..E...s
 ==
 ERROR: test_generic_relation_cascade
 (regressiontests.delete_regress.tests.DeleteCascadeTests)
 --
 Traceback (most recent call last):
   File
 
"/home/rhubscher/django/Django-1.3.1/tests/regressiontests/delete_regress/tests.py",
 line 81, in test_generic_relation_cascade
 person.delete()
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/base.py", line 580, in delete
 collector.collect([self])
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/deletion.py", line 178, in collect
 sub_objs = relation.bulk_related_objects(new_objs, self.using)
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/contrib/contenttypes/generic.py", line 189, in
 bulk_related_objects
 [obj.pk for obj in objs]
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/manager.py", line 141, in filter
 return self.get_query_set().filter(*args, **kwargs)
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 550, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 568, in _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/sql/query.py", line 1194, in add_q
 can_reuse=used_aliases, force_having=force_having)
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/sql/query.py", line 1069, in add_filter
 negate=negate, process_extras=process_extras)
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/sql/query.py", line 1260, in setup_joins
 "Choices are: %s" % (name, ", ".join(names)))
 FieldError: Cannot resolve keyword 'object_id' into field. Choices are:
 app_content_type, app_object_id, awardnote, id, name, person

 --
 Ran 7 tests in 0.266s

 FAILED (errors=1, skipped=1)
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17310: Delete an object linked to a GenericForeignKey

[Django]

#17310: Delete an object linked to a GenericForeignKey
--+
 Reporter:  Natim |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 On delete a GenericForeignKey, if you don't use `object_id`, you get this
 error :

 {{{
 >>> l = PageApp_Blog.objects.all()
 >>> l
 [, ]
 >>> l[1].delete()
 Traceback (most recent call last):
   File "", line 1, in 
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/base.py", line 580, in delete
 collector.collect([self])
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/deletion.py", line 178, in collect
 sub_objs = relation.bulk_related_objects(new_objs, self.using)
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/contrib/contenttypes/generic.py", line 189, in
 bulk_related_objects
 [obj.pk for obj in objs]
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/manager.py", line 141, in filter
 return self.get_query_set().filter(*args, **kwargs)
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 550, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 568, in _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/sql/query.py", line 1194, in add_q
 can_reuse=used_aliases, force_having=force_having)
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/sql/query.py", line 1069, in add_filter
 negate=negate, process_extras=process_extras)
   File
 "/home/rhubscher/hg/modulo3/demos/jungleland/apps/local/lib/python2.7
 /site-packages/django/db/models/sql/query.py", line 1260, in setup_joins
 "Choices are: %s" % (name, ", ".join(names)))
 FieldError: Cannot resolve keyword 'object_id' into field. Choices are:
 app_page_id, app_page_type, children, id, last_modif, layout, level, lft,
 meta_description, meta_keywords, navigation, pageapp_blog, pageapp_text,
 parent, placeholder_slug, plugin_order, plugins, rght, sha1, slug, title,
 tree_id, website
 }}}

 Here is the model :

 {{{
 class Page(MPTTModel):
 ...
 app_page_type = models.ForeignKey(ContentType,
   limit_choices_to =
 {'model__startswith': 'pageapp_'},
   verbose_name="page application")
 app_page_id = models.PositiveIntegerField(editable=False)
 app_page_object = generic.GenericForeignKey('app_page_type',
 'app_page_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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.