Re: [Django] #17092: Internal Redirects with Apache

[Django]

#17092: Internal Redirects with Apache
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  reopened
Component:  HTTP handling |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by anonymous):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10813: Database errors in the shell should roll back the transaction

[Django]

#10813: Database errors in the shell should roll back the transaction
-+-
 Reporter:  Glenn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by WoLpH):

 Replying to [comment:11 Glenn]:
 > Nothing says that errors are unexpected.  If an unexpected error does
 happen, it's the application's job to roll back the transaction; it's
 *not* the database's job to *force* it to.

 Regardless, when the database gives you an error like this it can be
 impossible (e.g. with stored procedures, triggers, etc..) to fully
 understand what has happened behind the scenes.

 The only reasonable cause of action in such cases is rolling back (either
 to a savepoint or the entire commit). There can be a lot of ambiguity if
 the database would allow you to continue after something like that.
 PostgreSQL has way too much features behind the scenes (rules, triggers,
 stored procedures) to allow you to fully know what is going on from
 Django.

 If ambiguity is possible than there should be no option to commit after
 all. It can severely corrupt your database.


 > > No, the correct fix is to make Django default to AutoCommit? settings
 with Postgres. If you want to continue running commands after your
 transaction has died than you shouldn't be using transactions in the first
 place.
 >
 > That doesn't make sense.  Of course I should be using transactions.

 The principle of transactions is that you are sure that _all_ of your
 statements either commit succesfully or rollback. Not doing either of
 those goes against ACID.

 > > My proposed fix, make autocommit the default setting for postgres.
 >
 > The default behavior should not vary across databases.

 But the default behaviour _is_ different. In MySQL the behaviour is very
 similar to autocommit mode by default. With MyISAM you don't even have
 transactions as an option. And having autocommit enabled doesn't stop you
 from manually opening a transaction like you would normally do.

-- 
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] #10813: Database errors in the shell should roll back the transaction

[Django]

#10813: Database errors in the shell should roll back the transaction
-+-
 Reporter:  Glenn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Glenn):

 > Can you explain the rationale behind that? If _anything_ inside my
 transaction gives me an error which I had not anticipated (otherwise I
 should have used a savepoint) it should just rollback the entire
 transaction. Just allowing new commands like nothing has happened can
 easily cause data loss and goes directly against ACID compliance.

 Nothing says that errors are unexpected.  If an unexpected error does
 happen, it's the application's job to roll back the transaction; it's
 *not* the database's job to *force* it to.

 > No, the correct fix is to make Django default to AutoCommit? settings
 with Postgres. If you want to continue running commands after your
 transaction has died than you shouldn't be using transactions in the first
 place.

 That doesn't make sense.  Of course I should be using transactions.

 > My proposed fix, make autocommit the default setting for postgres.

 The default behavior should not vary across databases.

 I don't intend to debate this further, since this bug has sat around for
 well over three years (despite having a reasonable fix available for at
 least the most common and annoying problem), giving me little expectation
 of it getting fixed, and I'm not even using Django for anything right now.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10813: Database errors in the shell should roll back the transaction

[Django]

#10813: Database errors in the shell should roll back the transaction
-+-
 Reporter:  Glenn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by WoLpH):

 Replying to [comment:7 Glenn]:
 > In my opinion, this is ultimately a bug in Postgresql: errors should
 *not* prevent subsequent commands in a transaction from working.  The only
 generic way I know to work around this is to set a savepoint before each
 command and commit it immediately after, so if an error occurs you can
 roll back to the checkpoint to unset the error flag.  The overhead of that
 isn't acceptable in production, of course, and doing that only when in a
 shell (which I'm not even sure is possible) would be a debugging
 nightmare.

 Can you explain the rationale behind that? If _anything_ inside my
 transaction gives me an error which I had not anticipated (otherwise I
 should have used a savepoint) it should just rollback the entire
 transaction. Just allowing new commands like nothing has happened can
 easily cause data loss and goes directly against ACID compliance.

 > The correct fix is to convince Postgresql upstream to add a flag to
 disable this behavior, so errors within a transaction don't abort the
 entire transaction.  This would make Postgresql's behavior match other SQL
 engines.  I've had trouble with this many times over the years and have
 never had any luck getting them to fix this.

 No, the correct fix is to make Django default to AutoCommit settings with
 Postgres. If you want to continue running commands after your transaction
 has died than you shouldn't be using transactions in the first place.


 My proposed fix, make autocommit the default setting for postgres.

-- 
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] #1688: Permissions don't get translated in admin interface

[Django]

#1688: Permissions don't get translated in admin interface
-+-
 Reporter:  Rudolph  |Owner:  hugo
 Type:  defect   |   Status:  closed
Component:   |  Version:  1.2
  Internationalization   |   Resolution:  wontfix
 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
-+-
Changes (by thepapermen):

 * cc: thepapermen (added)
 * ui_ux:   => 0
 * easy:   => 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] #17141: Placeholder images in contrib/webdesign

[Django]

#17141: Placeholder images in contrib/webdesign
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.webdesign|  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  placeholder, | Triage Stage:
  images, webdesign  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by russellm):

 Having to deploy a URL to support a placeholder sounds like overkill for
 me. By the time you've got the moving parts working, it would be easier to
 just look up the URL arguments to an external service of your choice.

 However:

  1) There was lots of talk at DjangoCon about shipping less with Django.
 The extreme case of this would be shipping contrib.auth as an external
 package; that's a way off being practical, but something like
 contrib.webdesign -- a package with a single template tag in it -- would
 be a good candidate for pruning. If someone wanted to take on
 contrib.webdesign as a third party project, I could get behind a move to
 prune it from the Django's tree, at which point, the new maintainer
 wouldn't be bound to Django's internal maintenance policies.

  2) If we have to manually deploy a view in urls.py, it would be a pain.
 But what if there was a way for an app to automatically hook in URLs at a
 predictable location? This isn't an isolated use case, either; consider
 the case of AJAX widgets -- they need a way to register a data source that
 needs to be exposed as a view. There might be a need for a framework
 support for 'machine usable, internal URL endpoints'.

-- 
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] #17143: select_related makes base __init__ unsafe

[Django]

#17143: select_related makes base __init__ unsafe
-+-
 Reporter:  Leo  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   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 carljm):

 * type:  Cleanup/optimization => Bug
 * component:  Documentation => Database layer (models, ORM)


Comment:

 I'm not sure I agree, aaugustin. I got further clarification from Leo that
 this only happens with select_related, not when selecting directly on Bs.
 IMO that indicates that it is a bug, and might be fixable. I might be
 wrong; would have to sit down and look at it in more detail to see what a
 fix would entail.

-- 
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] #17143: select_related makes base __init__ unsafe

[Django]

#17143: select_related makes base __init__ unsafe
--+
 Reporter:  Leo   |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 aaugustin):

 * needs_better_patch:   => 0
 * component:  Database layer (models, ORM) => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 To the best of my knowledge, that's the expected behavior. I agree the
 docs could be improved. Basically, `B` carries only the `bar` field and a
 one-to-one relation to `A`.

-- 
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] #17143: select_related makes base __init__ unsafe

[Django]

#17143: select_related makes base __init__ unsafe
--+
 Reporter:  Leo   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 For the following models setup:

 {{{#!python
 class A(models.Model):
 foo = models.CharField(max_length=1, default='N')

 def __init__(self, *args, **kwargs):
 super(A, self).__init__(*args, **kwargs)

 print self.foo

 class B(A):
 bar = models.CharField(max_length=1, default='X')
 }}}

 The `print` in in class `A` is just a proxy for doing something else with
 the field. My specific use case is that I'm trying to save the field off
 so I can detect whether it has been changed on save or not - but that
 doesn't impact the bug.

 {{{#!python
 >>> b = B(foo='Y', bar='Z')
 Y
 >>> b.save()
 >>> A.objects.select_related('b')
 Y
 N
 []
 }}}

 The second call to `A.__init__` is to create the B object, however, it
 doesn't have all of the fields from the original A so while in
 `A.__init__`, `self.foo` evaluates to the wrong value.

 This is either something broken with what fields `select_related` loads on
 related objects, or it needs to be documented as a really really nasty
 gotcha for inherited classes/`select_related`.

-- 
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] r17066 - django/trunk/docs/faq

[noreply]

Author: lukeplant
Date: 2011-11-01 15:27:02 -0700 (Tue, 01 Nov 2011)
New Revision: 17066

Modified:
   django/trunk/docs/faq/models.txt
Log:
Fixed #17129 - Model FAQ: Link to south

Thanks to guettli for report and initial patch

Modified: django/trunk/docs/faq/models.txt
===
--- django/trunk/docs/faq/models.txt2011-11-01 21:50:17 UTC (rev 17065)
+++ django/trunk/docs/faq/models.txt2011-11-01 22:27:02 UTC (rev 17066)
@@ -50,11 +50,12 @@
 This drops any tables associated with ``appname`` and recreates them.
 
 If you do care about deleting data, you'll have to execute the ``ALTER TABLE``
-statements manually in your database. That's the way we've always done it,
-because dealing with data is a very sensitive operation that we've wanted to
-avoid automating. That said, there's some work being done to add partially
-automated database-upgrade functionality.
+statements manually in your database.
 
+There are `external projects which handle schema updates
+`_, of which the current
+defacto standard is `south `_.
+
 Do Django models support multiple-column primary keys?
 --
 

-- 
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] #17129: Model FAQ: Link to south

[Django]

#17129: Model FAQ: Link to south
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  south| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by lukeplant):

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


Comment:

 In [17066]:
 {{{
 #!CommitTicketReference repository="" revision="17066"
 Fixed #17129 - Model FAQ: Link to south

 Thanks to guettli for report and initial patch
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #8291: "pk" alias doesn't work for Meta option "ordering"

[Django]

#8291: "pk" alias doesn't work for Meta option "ordering"
-+-
 Reporter:  peterd12 |Owner:  frog32
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  Meta ordering pk |  Needs documentation:  0
  alias  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by lukeplant):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 The tests pass without the patch to django/db/models/options.py, haven't
 investigated why.

 It would also be better if the test was put in its own method, for easier
 testing.

-- 
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] r17065 - in django/trunk/django/contrib/admin: . static/admin/js/admin

[noreply]

Author: lukeplant
Date: 2011-11-01 14:50:17 -0700 (Tue, 01 Nov 2011)
New Revision: 17065

Modified:
   django/trunk/django/contrib/admin/options.py
   
django/trunk/django/contrib/admin/static/admin/js/admin/RelatedObjectLookups.js
Log:
Fixed #5704 - Admin popup windows won't close when using application/xhtml as 
default content type

Thanks to Rob van der Linde for the report, and to mb0, dArignac and claudep
for the patch.

Modified: django/trunk/django/contrib/admin/options.py
===
--- django/trunk/django/contrib/admin/options.py2011-11-01 21:44:18 UTC 
(rev 17064)
+++ django/trunk/django/contrib/admin/options.py2011-11-01 21:50:17 UTC 
(rev 17065)
@@ -779,7 +779,9 @@
 return HttpResponseRedirect(post_url_continue % pk_value)
 
 if "_popup" in request.POST:
-return HttpResponse('opener.dismissAddAnotherPopup(window, "%s", 
"%s");' % \
+return HttpResponse(
+''
+'opener.dismissAddAnotherPopup(window, "%s", 
"%s");' % \
 # escape() calls force_unicode.
 (escape(pk_value), escapejs(obj)))
 elif "_addanother" in request.POST:

Modified: 
django/trunk/django/contrib/admin/static/admin/js/admin/RelatedObjectLookups.js
===
--- 
django/trunk/django/contrib/admin/static/admin/js/admin/RelatedObjectLookups.js 
2011-11-01 21:44:18 UTC (rev 17064)
+++ 
django/trunk/django/contrib/admin/static/admin/js/admin/RelatedObjectLookups.js 
2011-11-01 21:50:17 UTC (rev 17065)
@@ -74,11 +74,12 @@
 var name = windowname_to_id(win.name);
 var elem = document.getElementById(name);
 if (elem) {
-if (elem.nodeName == 'SELECT') {
+var elemName = elem.nodeName.toUpperCase();
+if (elemName == 'SELECT') {
 var o = new Option(newRepr, newId);
 elem.options[elem.options.length] = o;
 o.selected = true;
-} else if (elem.nodeName == 'INPUT') {
+} else if (elemName == 'INPUT') {
 if (elem.className.indexOf('vManyToManyRawIdAdminField') != -1 && 
elem.value) {
 elem.value += ',' + newId;
 } else {

-- 
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] #5704: Admin popup windows won't close when using application/xhtml as default content type

[Django]

#5704: Admin popup windows won't close when using application/xhtml as default
content type
-+-
 Reporter:  Rob van der Linde|Owner:  dArignac
   |   Status:  closed
 Type:  Bug  |  Version:  SVN
Component:  contrib.admin|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by lukeplant):

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


Comment:

 In [17065]:
 {{{
 #!CommitTicketReference repository="" revision="17065"
 Fixed #5704 - Admin popup windows won't close when using application/xhtml
 as default content type

 Thanks to Rob van der Linde for the report, and to mb0, dArignac and
 claudep
 for the patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] r17064 - django/trunk/docs/topics/db

[noreply]

Author: lukeplant
Date: 2011-11-01 14:44:18 -0700 (Tue, 01 Nov 2011)
New Revision: 17064

Modified:
   django/trunk/docs/topics/db/queries.txt
Log:
Fixed #4027 - Document how to make copies of model instances

Thanks to Marek Kubica for the report and initial patch, and to oinopion and
erikr for work on the patch.

Modified: django/trunk/docs/topics/db/queries.txt
===
--- django/trunk/docs/topics/db/queries.txt 2011-11-01 21:37:12 UTC (rev 
17063)
+++ django/trunk/docs/topics/db/queries.txt 2011-11-01 21:44:18 UTC (rev 
17064)
@@ -828,6 +828,46 @@
 
 Entry.objects.all().delete()
 
+.. _topics-db-queries-copy:
+
+Copying model instances
+===
+
+Although there is no built-in method for copying model instances, it is
+possible to easily create new instance with all fields' values copied. In the
+simplest case, you can just set ``pk`` to ``None``. Using our blog example::
+
+blog = Blog(name='My blog', tagline='Blogging is easy')
+blog.save() # post.pk == 1
+
+blog.pk = None
+blog.save() # post.pk == 2
+
+Things get more complicated if you use inheritance. Consider a subclass of
+``Blog``::
+
+class ThemeBlog(Blog):
+theme = models.CharField(max_length=200)
+
+django_blog = ThemeBlog(name='Django', tagline='Django is easy', theme = 
'python')
+django_blog.save() # django_blog.pk == 3
+
+Due to how inheritance works, you have to set both ``pk`` and ``id`` to None::
+
+django_blog.pk = None
+django_blog.id = None
+django_blog.save() # django_blog.pk == 4
+
+This process does not copy related objects. If you want to copy relations,
+you have to write a little bit more code. In our example, ``Entry`` has a many 
to many
+field to ``Author``::
+
+entry = Entry.objects.all()[0] # some previous entry
+old_authors = entry.authors.all()
+entry.pk = None
+entry.save()
+entry.authors = old_authors # saves new many2many relations
+
 .. _topics-db-queries-update:
 
 Updating multiple objects at once

-- 
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] #4027: Document how to make copies of model instances

[Django]

#4027: Document how to make copies of model instances
-+-
 Reporter:  Marek Kubica |Owner:  oinopion
 Type:  New feature  |   Status:  closed
Component:  Documentation|  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  db, copy | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by lukeplant):

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


Comment:

 In [17064]:
 {{{
 #!CommitTicketReference repository="" revision="17064"
 Fixed #4027 - Document how to make copies of model instances

 Thanks to Marek Kubica for the report and initial patch, and to oinopion
 and
 erikr for work on the patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17117: ADMIN_MEDIA_PREFIX should still be visible in docs

[Django]

#17117: ADMIN_MEDIA_PREFIX should still be visible in docs
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by lukeplant):

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


Comment:

 In [17063]:
 {{{
 #!CommitTicketReference repository="" revision="17063"
 Fixed #17117 - ADMIN_MEDIA_PREFIX should still be visible in docs

 Thanks to claudep for the report and patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] r17063 - django/trunk/docs/ref

[noreply]

Author: lukeplant
Date: 2011-11-01 14:37:12 -0700 (Tue, 01 Nov 2011)
New Revision: 17063

Modified:
   django/trunk/docs/ref/settings.txt
Log:
Fixed #17117 - ADMIN_MEDIA_PREFIX should still be visible in docs

Thanks to claudep for the report and patch.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2011-11-01 20:07:42 UTC (rev 17062)
+++ django/trunk/docs/ref/settings.txt  2011-11-01 21:37:12 UTC (rev 17063)
@@ -2148,6 +2148,16 @@
 Deprecated settings
 ===
 
+.. setting:: ADMIN_MEDIA_PREFIX
+
+ADMIN_MEDIA_PREFIX
+--
+
+.. deprecated:: 1.4
+   This setting has been obsoleted by the ``django.contrib.staticfiles`` app
+   integration. See the :doc:`Django 1.4 release notes` for
+   more information.
+
 .. setting:: CACHE_BACKEND
 
 CACHE_BACKEND

-- 
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] #17137: ModelForm is_valid() accepts options outside choices

[Django]

#17137: ModelForm is_valid() accepts options outside choices
+--
 Reporter:  hayrynen@…  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.3
 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 aaugustin):

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


Old description:

> If form is made using ModelForm and choices of ManyToMany field are
> limited like this:
>
> -- snip
> models.py:
>
> class Product(models.Model):
>name = models.CharField(max_length=60, verbose_name="Name")
>visibility = models.ManyToManyField(Group, verbose_name="Groups")
>

> views.py:
>
> class ProductForm(forms.ModelForm):
>def __init__(self, group_choices, *args, **kwargs):
>super(ProductForm, self).__init__(*args, **kwargs)
>self.fields['visibility'].choices = group_choices
>class Meta:
>model = Product
>
> @login_required
> def products_view(request):
>userprofile = UserProfile.objects.get(user = request.user)
>groups = [ (i.id, i.group) for i in
> Membership.objects.filter(userprofile=userprofile) ]
>
>if request.method == "POST":
>form = ProductForm(groups, request.POST)
>if form.is_valid():
>.. do stuff with visibility trusting form.is_valid()
> -- snip
>
> is_valid() allows values for ManyToMany selections outside what is
> specified in the form as long as there exists corresponding ID in the
> database. Obviously the submitted form needs to be modified outside
> standard browser UI.
>
> is_valid() should compare selections against .choices, not against what
> exists in the database.

New description:

 If form is made using `ModelForm` and choices of `ManyToMany` field are
 limited like this:

 {{{
 # models.py

 class Product(models.Model):
name = models.CharField(max_length=60, verbose_name="Name")
visibility = models.ManyToManyField(Group, verbose_name="Groups")

 # views.py

 class ProductForm(forms.ModelForm):
def __init__(self, group_choices, *args, **kwargs):
super(ProductForm, self).__init__(*args, **kwargs)
self.fields['visibility'].choices = group_choices
class Meta:
model = Product

 @login_required
 def products_view(request):
userprofile = UserProfile.objects.get(user = request.user)
groups = [ (i.id, i.group) for i in
 Membership.objects.filter(userprofile=userprofile) ]

if request.method == "POST":
form = ProductForm(groups, request.POST)
if form.is_valid():
.. do stuff with visibility trusting form.is_valid()
 }}}

 `is_valid()` allows values for `ManyToMany` selections outside what is
 specified in the form as long as there exists corresponding ID in the
 database. Obviously the submitted form needs to be modified outside
 standard browser UI.

 `is_valid()` should compare selections against .choices, not against what
 exists in the database.

--

Comment:

 Fixed formatting -- please use wiki syntax and preview.

-- 
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] #17134: Wrong parsing of microseconds in !BaseTemporalField.to_python

[Django]

#17134: Wrong parsing of microseconds in !BaseTemporalField.to_python
---+
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  SVN
 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 aaugustin):

 * easy:  0 => 1
 * 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] #16966: CachedStaticFilesStorage chokes on file references that end with a '#' or '?' character

[Django]

#16966: CachedStaticFilesStorage chokes on file references that end with a '#' 
or
'?' character
-+-
 Reporter:  mkai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  CachedStaticFilesStorage,  |  Needs documentation:  0
  CachedFilesMixin, collectstatic|  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 If I remember correctly, a unique id is added as query string in
 references to external files, and this feature should be kept.

 However, the fragment can be preserved.

-- 
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] #16966: CachedStaticFilesStorage chokes on file references that end with a '#' or '?' character

[Django]

#16966: CachedStaticFilesStorage chokes on file references that end with a '#' 
or
'?' character
-+-
 Reporter:  mkai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  CachedStaticFilesStorage,  |  Needs documentation:  0
  CachedFilesMixin, collectstatic|  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * 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] #16967: CachedStaticFilesStorage only populates the file name cache once, never updates

[Django]

#16967: CachedStaticFilesStorage only populates the file name cache once, never
updates
-+-
 Reporter:  mkai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  CachedStaticFilesStorage, cache|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * 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.

[Changeset] r17062 - in django/trunk: django/core/serializers docs/releases tests/modeltests/serializers

[noreply]

Author: aaugustin
Date: 2011-11-01 13:07:42 -0700 (Tue, 01 Nov 2011)
New Revision: 17062

Modified:
   django/trunk/django/core/serializers/pyyaml.py
   django/trunk/docs/releases/1.4.txt
   django/trunk/tests/modeltests/serializers/tests.py
Log:
Used yaml.safe_load instead of yaml.load, because safety should be the default.


Modified: django/trunk/django/core/serializers/pyyaml.py
===
--- django/trunk/django/core/serializers/pyyaml.py  2011-11-01 14:02:31 UTC 
(rev 17061)
+++ django/trunk/django/core/serializers/pyyaml.py  2011-11-01 20:07:42 UTC 
(rev 17062)
@@ -51,6 +51,6 @@
 stream = StringIO(stream_or_string)
 else:
 stream = stream_or_string
-for obj in PythonDeserializer(yaml.load(stream), **options):
+for obj in PythonDeserializer(yaml.safe_load(stream), **options):
 yield obj
 

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-11-01 14:02:31 UTC (rev 17061)
+++ django/trunk/docs/releases/1.4.txt  2011-11-01 20:07:42 UTC (rev 17062)
@@ -743,6 +743,16 @@
 def open(self, name, mode='rb'):
 return Spam(open(self.path(name), mode))
 
+YAML deserializer now uses ``yaml.safe_load``
+~
+
+``yaml.load`` is able to construct any Python object, which may trigger
+arbitrary code execution if you process a YAML document that comes from an
+untrusted source. This feature isn't necessary for Django's YAML deserializer,
+whose primary use is to load fixtures consisting of simple objects. Even though
+fixtures are trusted data, for additional security, the YAML deserializer now
+uses ``yaml.safe_load``.
+
 .. _deprecated-features-1.4:
 
 Features deprecated in 1.4

Modified: django/trunk/tests/modeltests/serializers/tests.py
===
--- django/trunk/tests/modeltests/serializers/tests.py  2011-11-01 14:02:31 UTC 
(rev 17061)
+++ django/trunk/tests/modeltests/serializers/tests.py  2011-11-01 20:07:42 UTC 
(rev 17062)
@@ -425,7 +425,7 @@
 @staticmethod
 def _validate_output(serial_str):
 try:
-yaml.load(StringIO(serial_str))
+yaml.safe_load(StringIO(serial_str))
 except Exception:
 return False
 else:
@@ -435,7 +435,7 @@
 def _get_pk_values(serial_str):
 ret_list = []
 stream = StringIO(serial_str)
-for obj_dict in yaml.load(stream):
+for obj_dict in yaml.safe_load(stream):
 ret_list.append(obj_dict["pk"])
 return ret_list
 
@@ -443,10 +443,10 @@
 def _get_field_values(serial_str, field_name):
 ret_list = []
 stream = StringIO(serial_str)
-for obj_dict in yaml.load(stream):
+for obj_dict in yaml.safe_load(stream):
 if "fields" in obj_dict and field_name in obj_dict["fields"]:
 field_value = obj_dict["fields"][field_name]
-# yaml.load will return non-string objects for some
+# yaml.safe_load will return non-string objects for some
 # of the fields we are interested in, this ensures that
 # everything comes back as a string
 if isinstance(field_value, basestring):

-- 
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] #17028: diveintopython.org links now dead

[Django]

#17028: diveintopython.org links now dead
-+-
 Reporter:  django@… |Owner:  pyriku
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by DrMeers):

 But how long will the nfshost version stick around I wonder...

 If we're really sold on it, perhaps we should host our own mirror

-- 
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] #17142: missing defaults keyword in tutorial 3

[Django]

#17142: missing defaults keyword in tutorial 3
---+--
 Reporter:  jbrown23@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Alex):

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


Comment:

 Duplicate of #16252 I think.  You're using the docs for the SVN version
 while using the 1.3 code.

-- 
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] #17142: missing defaults keyword in tutorial 3

[Django]

#17142: missing defaults keyword in tutorial 3
---+
 Reporter:  jbrown23@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In tutorial number 3, the "defaults" keyword is left out in the
 description to modify urls.py

 should be
 from django.conf.urls.'''defaults''' import patterns, include, url

-- 
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] #17096: Strengthen the makemessages command's safe-guarding of po files

[Django]

#17096: Strengthen the makemessages command's safe-guarding of po files
-+-
 Reporter:  julien   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 I agree that checking the timestamps and using `os.rename` are quick wins.

 I don't think it's worth engineering an enterprise class test harness for
 this -- the code should be trivial.

-- 
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] #17124: Need a 'Core (URLs)' Component for trac

[Django]

#17124: Need a 'Core (URLs)' Component for trac
-+-
 Reporter:  ptone|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Djangoproject.com|  Version:  1.3
  Web site   |   Resolution:  fixed
 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 aaugustin):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => fixed
 * 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] #17126: Docs in azw/mobi format.

[Django]

#17126: Docs in azw/mobi format.
-+-
 Reporter:  wassup@… |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:  wontfix
 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 aaugustin):

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


Comment:

 I agree that this would be useful.

 Unfortunately, Sphinx (the tool we use to generate Django's documentation)
 doesn't support azw or mobi yet.

 This feature request is tracked here:
 https://bitbucket.org/birkenfeld/sphinx/issue/739/please-add-a-mobi-
 builder

 Also, the standalone versions available for download are hosted by
 !ReadTheDocs.

 I'm sorry, but until Sphinx and !ReadTheDocs support mobi, there's not
 much we can do.

 Thanks for the suggestion!

-- 
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] #17128: Python 2.5-incompatible change in r16319 -- ModelAdmin.list_display.index method called

[Django]

#17128: Python 2.5-incompatible change in r16319 -- 
ModelAdmin.list_display.index
method called
-+-
 Reporter:  DrMeers  |Owner:  DrMeers
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  python 2.5, tuple,   | Triage Stage:  Ready for
  index, list_display|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Ready for checkin
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 This looks good to me.

-- 
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] #17122: Admin inlines and forms do not support custom model fields that store non-unicode data in the database to be the primary key referenced by relation fields.

[Django]

#17122: Admin inlines and forms do not support custom model fields that store 
non-
unicode data in the database to be the primary key referenced by relation
fields.
-+--
 Reporter:  nickname123  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by nickname123):

 * needs_tests:  1 => 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] #17122: Admin inlines and forms do not support custom model fields that store non-unicode data in the database to be the primary key referenced by relation fields.

[Django]

#17122: Admin inlines and forms do not support custom model fields that store 
non-
unicode data in the database to be the primary key referenced by relation
fields.
-+--
 Reporter:  nickname123  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by nickname123):

 * needs_tests:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #6773: Confusing error when ForeignKey lookup fails while serializing

[Django]

#6773: Confusing error when ForeignKey lookup fails while serializing
-+-
 Reporter:  kcarnold |Owner:
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Core |   Resolution:  needsinfo
  (Serialization)| Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:  dumpdata exception   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by nathank@…):

 * version:  1.2-alpha => 1.3


Comment:

 still a problem in 1.3.1.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #5691: Add the active language to generate the cache key

[Django]

#5691: Add the active language to generate the cache key
-+-
   Reporter:  aaloy@…|Owner:  aaloy
   Type: |   Status:  closed
  Component:  Core (Cache system)|  Version:  SVN
   Severity: |   Resolution:  fixed
   Keywords:  cache i18n jgd-| Triage Stage:  Accepted
  blackboard |  Needs documentation:  0
  Has patch:  1  |  Patch needs improvement:  0
Needs tests:  0  |
-+-

Comment (by aaugustin):

 In [17061]:
 {{{
 #!CommitTicketReference repository="" revision="17061"
 Made the cache locale-dependant when USE_L10N is True, even if USE_I18N is
 False. Refs #5691.
 }}}

-- 
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] r17061 - in django/trunk: django/utils docs/topics tests/regressiontests/cache

[noreply]

Author: aaugustin
Date: 2011-11-01 07:02:31 -0700 (Tue, 01 Nov 2011)
New Revision: 17061

Modified:
   django/trunk/django/utils/cache.py
   django/trunk/docs/topics/cache.txt
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Made the cache locale-dependant when USE_L10N is True, even if USE_I18N is 
False. Refs #5691.


Modified: django/trunk/django/utils/cache.py
===
--- django/trunk/django/utils/cache.py  2011-10-31 18:54:24 UTC (rev 17060)
+++ django/trunk/django/utils/cache.py  2011-11-01 14:02:31 UTC (rev 17061)
@@ -158,7 +158,7 @@
 
 def _i18n_cache_key_suffix(request, cache_key):
 """If enabled, returns the cache key ending with a locale."""
-if settings.USE_I18N:
+if settings.USE_I18N or settings.USE_L10N:
 # first check if LocaleMiddleware or another middleware added
 # LANGUAGE_CODE to request, then fall back to the active language
 # which in turn can also fall back to settings.LANGUAGE_CODE

Modified: django/trunk/docs/topics/cache.txt
===
--- django/trunk/docs/topics/cache.txt  2011-10-31 18:54:24 UTC (rev 17060)
+++ django/trunk/docs/topics/cache.txt  2011-11-01 14:02:31 UTC (rev 17061)
@@ -498,6 +498,10 @@
 :ref:`how-django-discovers-language-preference`). This allows you to easily
 cache multilingual sites without having to create the cache key yourself.
 
+.. versionchanged:: 1.4
+
+This also happens when :setting:`USE_L10N` is set to ``True``.
+
 __ `Controlling cache: Using other headers`_
 
 The per-view cache

Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-10-31 18:54:24 UTC 
(rev 17060)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-11-01 14:02:31 UTC 
(rev 17061)
@@ -1154,23 +1154,33 @@
 request.session = {}
 return request
 
-@override_settings(USE_I18N=True)
-def test_cache_key_i18n(self):
+@override_settings(USE_I18N=True, USE_L10N=False)
+def test_cache_key_i18n_translation(self):
 request = self._get_request()
 lang = translation.get_language()
 response = HttpResponse()
 key = learn_cache_key(request, response)
-self.assertTrue(key.endswith(lang), "Cache keys should include the 
language name when i18n is active")
+self.assertIn(lang, key, "Cache keys should include the language name 
when translation is active")
 key2 = get_cache_key(request)
 self.assertEqual(key, key2)
 
-@override_settings(USE_I18N=False)
+@override_settings(USE_I18N=False, USE_L10N=True)
+def test_cache_key_i18n_formatting(self):
+request = self._get_request()
+lang = translation.get_language()
+response = HttpResponse()
+key = learn_cache_key(request, response)
+self.assertIn(lang, key, "Cache keys should include the language name 
when formatting is active")
+key2 = get_cache_key(request)
+self.assertEqual(key, key2)
+
+@override_settings(USE_I18N=False, USE_L10N=False)
 def test_cache_key_no_i18n (self):
 request = self._get_request()
 lang = translation.get_language()
 response = HttpResponse()
 key = learn_cache_key(request, response)
-self.assertFalse(key.endswith(lang), "Cache keys shouldn't include the 
language name when i18n is inactive")
+self.assertNotIn(lang, key, "Cache keys shouldn't include the language 
name when i18n isn't active")
 
 @override_settings(
 CACHE_MIDDLEWARE_KEY_PREFIX="test",

-- 
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] #17141: Placeholder images in contrib/webdesign

[Django]

#17141: Placeholder images in contrib/webdesign
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.webdesign|  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  placeholder, | Triage Stage:
  images, webdesign  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 This was already requested in #16658 and rejected on the grounds of
 "reliance on external services".

 That said, do we really have to use a third party service? It should be
 fairly easy to generate PNGs of a given size with PIL. Django already has
 an optional dependency on PIL (`ImageField`). If we did this, all you'd
 have to do to use the feature is add an URL pointing to
 `django.webdesign.views.placeholder` in your URL conf.

 I believe that's what the OP had in mind, and not a wrapper around a
 third-party API.

 I agree that this brings little value — the only real advantage compared
 to placehold.it is that you can develop offline. However, it fits
 reasonably with Django's philosophy and shouldn't be a maintenance burden.
 If a patch with a self-contained and simple implementation was submitted,
 wouldn't we reconsider the "wontfix"?

-- 
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] #17141: Placeholder images in contrib/webdesign

[Django]

#17141: Placeholder images in contrib/webdesign
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.webdesign|  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  placeholder, | Triage Stage:
  images, webdesign  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by russellm):

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


Comment:

 I'm going to mark this as wontfix. The idea is certainly useful, but the
 dependence on an external web service is what has me concerned. The
 longevity and reliability of these services would impact on the stability
 of Django of a framework, and I'm not sure that's a position Django as a
 framework should be in.

 This would be a really good candidate for a third-party tag library,
 however. For that matter, the webdesign tools as a whole would probably be
 better suited to being a third party app.

-- 
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] #7231: New "join" parameter for the "extra" QuerySet method

[Django]

#7231: New "join" parameter for the "extra" QuerySet method
-+-
 Reporter:  Davide "Design"  |Owner:  nobody
  Muzzarelli |   Status:  closed
 Type:  Uncategorized|  Version:  SVN
Component:  Database layer   |   Resolution:  wontfix
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:  queryset extra left  |  Needs documentation:  1
  join   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by simonotron):

 * cc: simonotron (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] #17141: Placeholder images in contrib/webdesign

[Django]

#17141: Placeholder images in contrib/webdesign
--+
 Reporter:  anonymous |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:|Version:  1.3
  contrib.webdesign   |   Keywords:  placeholder, images, webdesign
 Severity:  Normal|  Has patch:  0
 Triage Stage:  Unreviewed|  UI/UX:  0
Easy pickings:  0 |
--+
 Placeholder images that can be automatically generated at the appropriate
 size is almost as useful as placeholder text.


 Some web services for this already exists:
 http://placekitten.com/
 http://placehold.it/


 It would be nice to have it in the webdesign package as well.

 Suggested syntax:

 {% placeholder_image [width] [height] [grayscale] %}

-- 
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] #17129: Model FAQ: Link to south

[Django]

#17129: Model FAQ: Link to south
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  south| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timo):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17129: Model FAQ: Link to south

[Django]

#17129: Model FAQ: Link to south
---+
 Reporter:  guettli|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords:  south  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by guettli):

 * needs_better_patch:  1 => 0


Comment:

 I uploaded a new version of the doc patch. If you are unhappy with the
 wording: Just change (and commit) it. Thank you.

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