Re: [Django] #14640: Add elapsed request time to the development server log

[Django]

#14640: Add elapsed request time to the development server log
+---
  Reporter:  vaughnkoch | Owner:  vaughnkoch
 
Status:  assigned   | Milestone:  1.3   
 
 Component:  HTTP handling  |   Version:  1.2   
 
Resolution: |  Keywords:  log time development 
server
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Comment (by anonymous):

 Hehe no worries guys.  Just a couple of thoughts:[[BR]]
 [[BR]]


 - I use firebug daily, and sometimes it's hard to cut through all the mess
 when looking at the timings.  I've personally used this log-timing patch
 to make improvements in my views.[[BR]]
 - There is a difference between the total time it takes to serve a Django
 view and the total roundtrip time from the browser's viewpoint.   You
 can't do the first one just using Firebug.[[BR]]
 - You can easily address (2) and (4) by calling the view multiple times
 and looking at a few instances of the data - you'd have to do this with a
 profiler in any case.[[BR]]
 - Also, I use profiling tools as well - they're more precise, but also
 much more heavyweight.  Sometimes you just need the insight of 'hey, that
 view is taking 1 second instead of 0.05 seconds...'[[BR]]

-- 
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-upda...@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] #14640: Add elapsed request time to the development server log

[Django]

#14640: Add elapsed request time to the development server log
+---
  Reporter:  vaughnkoch | Owner:  vaughnkoch
 
Status:  assigned   | Milestone:  1.3   
 
 Component:  HTTP handling  |   Version:  1.2   
 
Resolution: |  Keywords:  log time development 
server
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Comment (by vaughnkoch):

 Replying to [comment:6 anonymous]: Sorry, wasn't logged in when I posted
 this.
 > Hehe no worries guys.  Just a couple of thoughts:[[BR]]
 > [[BR]]
 >
 >
 > - I use firebug daily, and sometimes it's hard to cut through all the
 mess when looking at the timings.  I've personally used this log-timing
 patch to make improvements in my views.[[BR]]
 > - There is a difference between the total time it takes to serve a
 Django view and the total roundtrip time from the browser's viewpoint.
 You can't do the first one just using Firebug.[[BR]]
 > - You can easily address (2) and (4) by calling the view multiple times
 and looking at a few instances of the data - you'd have to do this with a
 profiler in any case.[[BR]]
 > - Also, I use profiling tools as well - they're more precise, but also
 much more heavyweight.  Sometimes you just need the insight of 'hey, that
 view is taking 1 second instead of 0.05 seconds...'[[BR]]
 >

-- 
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-upda...@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] r14522 - django/trunk/docs/releases

[noreply]

Author: ubernostrum
Date: 2010-11-11 01:21:07 -0600 (Thu, 11 Nov 2010)
New Revision: 14522

Modified:
   django/trunk/docs/releases/index.txt
Log:
Add 1.3 alpha notes to release-notes index.

Modified: django/trunk/docs/releases/index.txt
===
--- django/trunk/docs/releases/index.txt2010-11-11 07:20:31 UTC (rev 
14521)
+++ django/trunk/docs/releases/index.txt2010-11-11 07:21:07 UTC (rev 
14522)
@@ -64,6 +64,7 @@
 .. toctree::
:maxdepth: 1
 
+   1.3-alpha-1
1.2-rc-1
1.2-beta-1
1.2-alpha-1

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14521 - django/trunk/docs/releases

[noreply]

Author: ubernostrum
Date: 2010-11-11 01:20:31 -0600 (Thu, 11 Nov 2010)
New Revision: 14521

Modified:
   django/trunk/docs/releases/1.3-alpha-1.txt
Log:
Remove the 1.3 paragraph from the alpha notes.

Modified: django/trunk/docs/releases/1.3-alpha-1.txt
===
--- django/trunk/docs/releases/1.3-alpha-1.txt  2010-11-11 07:18:15 UTC (rev 
14520)
+++ django/trunk/docs/releases/1.3-alpha-1.txt  2010-11-11 07:20:31 UTC (rev 
14521)
@@ -2,10 +2,6 @@
 Django 1.3 alpha 1 release notes
 
 
-This page documents release notes for the as-yet-unreleased Django
-1.3. As such, it's tentative and subject to change. It provides
-up-to-date information for those who are following trunk.
-
 November 11, 2010
 
 Welcome to Django 1.3 alpha 1!

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14520 - django/trunk

[noreply]

Author: ubernostrum
Date: 2010-11-11 01:18:15 -0600 (Thu, 11 Nov 2010)
New Revision: 14520

Modified:
   django/trunk/setup.py
Log:
Change development-status classifier in setup.py since this is an alpha.

Modified: django/trunk/setup.py
===
--- django/trunk/setup.py   2010-11-11 07:15:30 UTC (rev 14519)
+++ django/trunk/setup.py   2010-11-11 07:18:15 UTC (rev 14520)
@@ -82,7 +82,7 @@
 cmdclass = cmdclasses,
 data_files = data_files,
 scripts = ['django/bin/django-admin.py'],
-classifiers = ['Development Status :: 5 - Production/Stable',
+classifiers = ['Development Status :: 3 - Alpha',
'Environment :: Web Environment',
'Framework :: Django',
'Intended Audience :: Developers',

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14519 - in django/trunk: . django

[noreply]

Author: ubernostrum
Date: 2010-11-11 01:15:30 -0600 (Thu, 11 Nov 2010)
New Revision: 14519

Modified:
   django/trunk/django/__init__.py
   django/trunk/setup.py
Log:
Bump version number and download URL for 1.3 alpha 1.

Modified: django/trunk/django/__init__.py
===
--- django/trunk/django/__init__.py 2010-11-11 07:14:28 UTC (rev 14518)
+++ django/trunk/django/__init__.py 2010-11-11 07:15:30 UTC (rev 14519)
@@ -1,4 +1,4 @@
-VERSION = (1, 3, 0, 'alpha', 0)
+VERSION = (1, 3, 0, 'alpha', 1)
 
 def get_version():
 version = '%s.%s' % (VERSION[0], VERSION[1])

Modified: django/trunk/setup.py
===
--- django/trunk/setup.py   2010-11-11 07:14:28 UTC (rev 14518)
+++ django/trunk/setup.py   2010-11-11 07:15:30 UTC (rev 14519)
@@ -77,7 +77,7 @@
 author = 'Django Software Foundation',
 author_email = 'foundat...@djangoproject.com',
 description = 'A high-level Python Web framework that encourages rapid 
development and clean, pragmatic design.',
-download_url = 
'http://media.djangoproject.com/releases/1.2/Django-1.2.1.tar.gz',
+download_url = 
'http://media.djangoproject.com/releases/1.3/Django-1.3-alpha-1.tar.gz',
 packages = packages,
 cmdclass = cmdclasses,
 data_files = data_files,

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14518 - django/trunk/docs/releases

[noreply]

Author: ubernostrum
Date: 2010-11-11 01:14:28 -0600 (Thu, 11 Nov 2010)
New Revision: 14518

Modified:
   django/trunk/docs/releases/1.3-alpha-1.txt
Log:
Correct a typo in the 1.3 alpha release notes.

Modified: django/trunk/docs/releases/1.3-alpha-1.txt
===
--- django/trunk/docs/releases/1.3-alpha-1.txt  2010-11-11 07:06:27 UTC (rev 
14517)
+++ django/trunk/docs/releases/1.3-alpha-1.txt  2010-11-11 07:14:28 UTC (rev 
14518)
@@ -19,7 +19,7 @@
 As such, this release is *not* intended for production use, and any such use is
 discouraged.
 
-As of this alpha release, Django 1.3 containsa number of nifty `new
+As of this alpha release, Django 1.3 contains a number of nifty `new
 features`_, lots of bug fixes, some minor `backwards incompatible
 changes`_ and an easy upgrade path from Django 1.2.
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14517 - django/trunk/docs/releases

[noreply]

Author: ubernostrum
Date: 2010-11-11 01:06:27 -0600 (Thu, 11 Nov 2010)
New Revision: 14517

Modified:
   django/trunk/docs/releases/1.3-alpha-1.txt
Log:
Add roadmap and contributing boilerplate to 1.3 alpha notes.

Modified: django/trunk/docs/releases/1.3-alpha-1.txt
===
--- django/trunk/docs/releases/1.3-alpha-1.txt  2010-11-11 07:02:02 UTC (rev 
14516)
+++ django/trunk/docs/releases/1.3-alpha-1.txt  2010-11-11 07:06:27 UTC (rev 
14517)
@@ -331,3 +331,60 @@
 redundancy, :class:`~django.test.simple.DjangoTestRunner` has been
 turned into an empty placeholder class, and will be removed entirely
 in Django 1.5.
+
+The Django 1.3 roadmap
+==
+
+Before the final Django 1.3 release, several other preview/development
+releases will be made available. The current schedule consists of at
+least the following:
+
+* Week of **November 29, 2010**: First Django 1.3 beta release. Final
+  feature freeze for Django 1.3.
+
+* Week of **January 10, 2011**: First Django 1.3 release
+  candidate. String freeze for translations.
+
+* Week of **January 17, 2011**: Django 1.3 final release.
+
+If necessary, additional alpha, beta or release-candidate packages
+will be issued prior to the final 1.3 release. Django 1.3 will be
+released approximately one week after the final release candidate.
+
+
+What you can do to help
+===
+
+In order to provide a high-quality 1.3 release, we need your help. Although 
this
+alpha release is, again, *not* intended for production use, you can help the
+Django team by trying out the alpha codebase in a safe test environment and
+reporting any bugs or issues you encounter. The Django ticket tracker is the
+central place to search for open issues:
+
+* http://code.djangoproject.com/timeline
+
+Please open new tickets if no existing ticket corresponds to a problem you're
+running into.
+
+Additionally, discussion of Django development, including progress toward the
+1.3 release, takes place daily on the django-developers mailing list:
+
+* http://groups.google.com/group/django-developers
+
+... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
+interested in helping out with Django's development, feel free to join the
+discussions there.
+
+Django's online documentation also includes pointers on how to contribute to
+Django:
+
+* :doc:`How to contribute to Django `
+
+Contributions on any level -- developing code, writing documentation or simply
+triaging tickets and helping to test proposed bugfixes -- are always welcome 
and
+appreciated.
+
+Several development sprints will also be taking place before the 1.3
+release; these will typically be announced in advance on the
+django-developers mailing list, and anyone who wants to help is
+welcome to join in.
\ No newline at end of file

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14516 - django/trunk/docs/releases

[noreply]

Author: ubernostrum
Date: 2010-11-11 01:02:02 -0600 (Thu, 11 Nov 2010)
New Revision: 14516

Added:
   django/trunk/docs/releases/1.3-alpha-1.txt
Log:
Add 1.3 alpha 1 release notes.

Added: django/trunk/docs/releases/1.3-alpha-1.txt
===
--- django/trunk/docs/releases/1.3-alpha-1.txt  (rev 0)
+++ django/trunk/docs/releases/1.3-alpha-1.txt  2010-11-11 07:02:02 UTC (rev 
14516)
@@ -0,0 +1,333 @@
+
+Django 1.3 alpha 1 release notes
+
+
+This page documents release notes for the as-yet-unreleased Django
+1.3. As such, it's tentative and subject to change. It provides
+up-to-date information for those who are following trunk.
+
+November 11, 2010
+
+Welcome to Django 1.3 alpha 1!
+
+This is the first in a series of preview/development releases leading
+up to the eventual release of Django 1.3. This release is primarily
+targeted at developers who are interested in trying out new features
+and testing the Django codebase to help identify and resolve bugs
+prior to the final 1.3 release.
+
+As such, this release is *not* intended for production use, and any such use is
+discouraged.
+
+As of this alpha release, Django 1.3 containsa number of nifty `new
+features`_, lots of bug fixes, some minor `backwards incompatible
+changes`_ and an easy upgrade path from Django 1.2.
+
+.. _new features: `What's new in Django 1.3 alpha 1`_
+
+.. _backwards incompatible changes: backwards-incompatible-changes-1.3_
+
+What's new in Django 1.3 alpha 1
+
+
+Class-based views
+~
+
+Django 1.3 adds a framework that allows you to use a class as a view.
+This means you can compose a view out of a collection of methods that
+can be subclassed and overridden to provide
+
+Analogs of all the old function-based generic views have been
+provided, along with a completely generic view base class that can be
+used as the basis for reusable applications that can be easily
+extended.
+
+See :doc:`the documentation on Generic Views`
+for more details. There is also a document to help you :doc:`convert
+your function-based generic views to class-based
+views`.
+
+Logging
+~~~
+
+Django 1.3 adds framework-level support for Python's logging module.
+This means you can now easily configure and control logging as part of
+your Django project. A number of logging handlers and logging calls
+have been added to Django's own code as well -- most notably, the
+error emails sent on a HTTP 500 server error are now handled as a
+logging activity. See :doc:`the documentation on Django's logging
+interface ` for more details.
+
+``unittest2`` support
+~
+
+Python 2.7 introduced some major changes to the unittest library,
+adding some extremely useful features. To ensure that every Django
+project can benefit from these new features, Django ships with a
+copy of unittest2_, a copy of the Python 2.7 unittest library,
+backported for Python 2.4 compatibility.
+
+To access this library, Django provides the
+``django.utils.unittest`` module alias. If you are using Python
+2.7, or you have installed unittest2 locally, Django will map the
+alias to the installed version of the unittest library. Otherwise,
+Django will use it's own bundled version of unittest2.
+
+To use this alias, simply use::
+
+from django.utils import unittest
+
+wherever you would have historically used::
+
+import unittest
+
+If you want to continue to use the base unittest libary, you can --
+you just won't get any of the nice new unittest2 features.
+
+.. _unittest2: http://pypi.python.org/pypi/unittest2
+
+Transaction context managers
+
+
+Users of Python 2.5 and above may now use :ref:`transaction management 
functions
+` as `context managers`_. For example::
+
+with transaction.autocommit():
+# ...
+
+.. _context managers: http://docs.python.org/glossary.html#term-context-manager
+
+For more information, see :ref:`transaction-management-functions`.
+
+Configurable delete-cascade
+~~~
+
+:class:`~django.db.models.ForeignKey` and
+:class:`~django.db.models.OneToOneField` now accept an
+:attr:`~django.db.models.ForeignKey.on_delete` argument to customize behavior
+when the referenced object is deleted. Previously, deletes were always
+cascaded; available alternatives now include set null, set default, set to any
+value, protect, or do nothing.
+
+For more information, see the :attr:`~django.db.models.ForeignKey.on_delete`
+documentation.
+
+Contextual markers in translatable strings
+~~
+
+For translation strings with ambiguous meaning, you can now
+use the ``pgettext`` function to specify the context of the string.
+
+For more information, see :ref:`contextual-markers`
+
+Everything else
+~~~
+
+Django :doc:`1.1 <1.1>` and :doc:`1.2 <1.2>` added
+lots 

[Changeset] r14515 - django/branches/releases/1.2.X/django/db/backends/oracle

[noreply]

Author: ramiro
Date: 2010-11-10 23:18:27 -0600 (Wed, 10 Nov 2010)
New Revision: 14515

Modified:
   django/branches/releases/1.2.X/django/db/backends/oracle/base.py
Log:
[1.2.X] Fixed error introduced in r14512.

Backport of [14514] from trunk

Modified: django/branches/releases/1.2.X/django/db/backends/oracle/base.py
===
--- django/branches/releases/1.2.X/django/db/backends/oracle/base.py
2010-11-11 05:17:31 UTC (rev 14514)
+++ django/branches/releases/1.2.X/django/db/backends/oracle/base.py
2010-11-11 05:18:27 UTC (rev 14515)
@@ -346,7 +346,7 @@
 
 def _connect_string(self):
 settings_dict = self.settings_dict
-if settings_dict['HOST'].strip():
+if not settings_dict['HOST'].strip():
 settings_dict['HOST'] = 'localhost'
 if settings_dict['PORT'].strip():
 dsn = Database.makedsn(settings_dict['HOST'],

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14514 - django/trunk/django/db/backends/oracle

[noreply]

Author: ramiro
Date: 2010-11-10 23:17:31 -0600 (Wed, 10 Nov 2010)
New Revision: 14514

Modified:
   django/trunk/django/db/backends/oracle/base.py
Log:
Fixed error introduced in r14512.

Modified: django/trunk/django/db/backends/oracle/base.py
===
--- django/trunk/django/db/backends/oracle/base.py  2010-11-11 05:12:05 UTC 
(rev 14513)
+++ django/trunk/django/db/backends/oracle/base.py  2010-11-11 05:17:31 UTC 
(rev 14514)
@@ -349,7 +349,7 @@
 
 def _connect_string(self):
 settings_dict = self.settings_dict
-if settings_dict['HOST'].strip():
+if not settings_dict['HOST'].strip():
 settings_dict['HOST'] = 'localhost'
 if settings_dict['PORT'].strip():
 dsn = Database.makedsn(settings_dict['HOST'],

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14513 - django/branches/releases/1.2.X/django/db/backends/oracle

[noreply]

Author: ramiro
Date: 2010-11-10 23:12:05 -0600 (Wed, 10 Nov 2010)
New Revision: 14513

Modified:
   django/branches/releases/1.2.X/django/db/backends/oracle/base.py
Log:
[1.2.X] Fixed small multi-db compatibility issue in the Oracle backend.

Also, converted a couple of constructs to a more Python idiomatic form.

Backport of [14512] from trunk

Modified: django/branches/releases/1.2.X/django/db/backends/oracle/base.py
===
--- django/branches/releases/1.2.X/django/db/backends/oracle/base.py
2010-11-11 05:07:32 UTC (rev 14512)
+++ django/branches/releases/1.2.X/django/db/backends/oracle/base.py
2010-11-11 05:12:05 UTC (rev 14513)
@@ -329,11 +329,11 @@
 'istartswith': "LIKE UPPER(TRANSLATE(%s USING NCHAR_CS)) ESCAPE 
TRANSLATE('\\' USING NCHAR_CS)",
 'iendswith': "LIKE UPPER(TRANSLATE(%s USING NCHAR_CS)) ESCAPE 
TRANSLATE('\\' USING NCHAR_CS)",
 }
-oracle_version = None
 
 def __init__(self, *args, **kwargs):
 super(DatabaseWrapper, self).__init__(*args, **kwargs)
 
+self.oracle_version = None
 self.features = DatabaseFeatures()
 self.ops = DatabaseOperations()
 self.client = DatabaseClient(self)
@@ -346,9 +346,9 @@
 
 def _connect_string(self):
 settings_dict = self.settings_dict
-if len(settings_dict['HOST'].strip()) == 0:
+if settings_dict['HOST'].strip():
 settings_dict['HOST'] = 'localhost'
-if len(settings_dict['PORT'].strip()) != 0:
+if settings_dict['PORT'].strip():
 dsn = Database.makedsn(settings_dict['HOST'],
int(settings_dict['PORT']),
settings_dict['NAME'])

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14512 - django/trunk/django/db/backends/oracle

[noreply]

Author: ramiro
Date: 2010-11-10 23:07:32 -0600 (Wed, 10 Nov 2010)
New Revision: 14512

Modified:
   django/trunk/django/db/backends/oracle/base.py
Log:
Fixed small multi-db compatibility issue in the Oracle backend.

Also, converted a couple of constructs to a more Python idiomatic form.

Modified: django/trunk/django/db/backends/oracle/base.py
===
--- django/trunk/django/db/backends/oracle/base.py  2010-11-11 04:37:37 UTC 
(rev 14511)
+++ django/trunk/django/db/backends/oracle/base.py  2010-11-11 05:07:32 UTC 
(rev 14512)
@@ -332,11 +332,11 @@
 'istartswith': "LIKE UPPER(TRANSLATE(%s USING NCHAR_CS)) ESCAPE 
TRANSLATE('\\' USING NCHAR_CS)",
 'iendswith': "LIKE UPPER(TRANSLATE(%s USING NCHAR_CS)) ESCAPE 
TRANSLATE('\\' USING NCHAR_CS)",
 }
-oracle_version = None
 
 def __init__(self, *args, **kwargs):
 super(DatabaseWrapper, self).__init__(*args, **kwargs)
 
+self.oracle_version = None
 self.features = DatabaseFeatures(self)
 self.ops = DatabaseOperations()
 self.client = DatabaseClient(self)
@@ -349,9 +349,9 @@
 
 def _connect_string(self):
 settings_dict = self.settings_dict
-if len(settings_dict['HOST'].strip()) == 0:
+if settings_dict['HOST'].strip():
 settings_dict['HOST'] = 'localhost'
-if len(settings_dict['PORT'].strip()) != 0:
+if settings_dict['PORT'].strip():
 dsn = Database.makedsn(settings_dict['HOST'],
int(settings_dict['PORT']),
settings_dict['NAME'])

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #11101: Oracle fails admin_view tests when the whole suite is run -- transaction problem?

[Django]

#11101: Oracle fails admin_view tests when the whole suite is run -- transaction
problem?
---+
  Reporter:  mboersma  | Owner:  mboersma   

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
transaction test
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 Replying to [comment:11 ikelly]:
 > After going through the test suite, here's what I've found:
 >
 > The views, admin_views, and model_formsets test suites are still getting
 a single 'unique constraint violated' error each.  I don't know why yet,
 and it may be unrelated, but at least that's a heck of a lot better than
 before.
 >
 > The backends test suite is getting a couple of errors that look like
 this:
 > {{{
 > DatabaseError: ORA-02091: transaction rolled back
 > ORA-02291: integrity constraint (DJANGO_TEST_DEFAULT.SYS_C001650670)
 violated - parent key not found
 > }}}

 This one isn't caused by the fix you implemented so it can be included
 with the last group you detailed (''There are a handful of other failures
 that don't appear to be related to this issue. ''). r14320 needed to be
 ported to Oracle (I started playing with it because I wanted to be sure I
 could test things). I committed a fix for it in r14510.

-- 
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-upda...@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] r14511 - django/branches/releases/1.2.X/django/db/backends/oracle

[noreply]

Author: ramiro
Date: 2010-11-10 22:37:37 -0600 (Wed, 10 Nov 2010)
New Revision: 14511

Modified:
   django/branches/releases/1.2.X/django/db/backends/oracle/base.py
Log:
[1.2.X] Implemented changes made in r14320 in the Oracle backend. Thanks 
Russell for reviewing the proposed fix.

Backport of [14510] from trunk

Modified: django/branches/releases/1.2.X/django/db/backends/oracle/base.py
===
--- django/branches/releases/1.2.X/django/db/backends/oracle/base.py
2010-11-11 04:36:20 UTC (rev 14510)
+++ django/branches/releases/1.2.X/django/db/backends/oracle/base.py
2010-11-11 04:37:37 UTC (rev 14511)
@@ -396,7 +396,29 @@
 def _savepoint_commit(self, sid):
 pass
 
+def _commit(self):
+if self.connection is not None:
+try:
+return self.connection.commit()
+except Database.IntegrityError, e:
+# In case cx_Oracle implements (now or in a future version)
+# raising this specific exception
+raise utils.IntegrityError, utils.IntegrityError(*tuple(e)), 
sys.exc_info()[2]
+except Database.DatabaseError, e:
+# cx_Oracle 5.0.4 raises a cx_Oracle.DatabaseError exception
+# with the following attributes and values:
+#  code = 2091
+#  message = 'ORA-02091: transaction rolled back
+#'ORA-02291: integrity constraint 
(TEST_DJANGOTEST.SYS
+#   _C00102056) violated - parent key not found'
+# We convert that particular case to our IntegrityError 
exception
+x = e.args[0]
+if hasattr(x, 'code') and hasattr(x, 'message') \
+   and x.code == 2091 and 'ORA-02291' in x.message:
+raise utils.IntegrityError, 
utils.IntegrityError(*tuple(e)), sys.exc_info()[2]
+raise utils.DatabaseError, utils.DatabaseError(*tuple(e)), 
sys.exc_info()[2]
 
+
 class OracleParam(object):
 """
 Wrapper object for formatting parameters for Oracle. If the string

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14510 - django/trunk/django/db/backends/oracle

[noreply]

Author: ramiro
Date: 2010-11-10 22:36:20 -0600 (Wed, 10 Nov 2010)
New Revision: 14510

Modified:
   django/trunk/django/db/backends/oracle/base.py
Log:
Implemented changes made in r14320 in the Oracle backend. Thanks Russell for 
reviewing the proposed fix.

Modified: django/trunk/django/db/backends/oracle/base.py
===
--- django/trunk/django/db/backends/oracle/base.py  2010-11-09 17:42:38 UTC 
(rev 14509)
+++ django/trunk/django/db/backends/oracle/base.py  2010-11-11 04:36:20 UTC 
(rev 14510)
@@ -399,7 +399,29 @@
 def _savepoint_commit(self, sid):
 pass
 
+def _commit(self):
+if self.connection is not None:
+try:
+return self.connection.commit()
+except Database.IntegrityError, e:
+# In case cx_Oracle implements (now or in a future version)
+# raising this specific exception
+raise utils.IntegrityError, utils.IntegrityError(*tuple(e)), 
sys.exc_info()[2]
+except Database.DatabaseError, e:
+# cx_Oracle 5.0.4 raises a cx_Oracle.DatabaseError exception
+# with the following attributes and values:
+#  code = 2091
+#  message = 'ORA-02091: transaction rolled back
+#'ORA-02291: integrity constraint 
(TEST_DJANGOTEST.SYS
+#   _C00102056) violated - parent key not found'
+# We convert that particular case to our IntegrityError 
exception
+x = e.args[0]
+if hasattr(x, 'code') and hasattr(x, 'message') \
+   and x.code == 2091 and 'ORA-02291' in x.message:
+raise utils.IntegrityError, 
utils.IntegrityError(*tuple(e)), sys.exc_info()[2]
+raise utils.DatabaseError, utils.DatabaseError(*tuple(e)), 
sys.exc_info()[2]
 
+
 class OracleParam(object):
 """
 Wrapper object for formatting parameters for Oracle. If the string

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #14661: A couple of MySQL/MyISAM test failures

[Django]

#14661: A couple of MySQL/MyISAM test failures
---+
 Reporter:  kmtracey   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Two tests fail when the Django test suite is run against MySQL with the
 MyISAM engine:

 {{{
 ==
 FAIL: test_initial_sql
 (regressiontests.initial_sql_regress.tests.InitialSQLTests)
 --
 Traceback (most recent call last):
   File
 
"/home/kmtracey/django/trunk/tests/regressiontests/initial_sql_regress/tests.py",
 line 8, in test_initial_sql
 self.assertEqual(Simple.objects.count(), 7)
 AssertionError: 0 != 7

 ==
 FAIL: test_tickets_8921_9188 (regressiontests.queries.tests.Queries6Tests)
 --
 Traceback (most recent call last):
   File
 "/home/kmtracey/django/trunk/tests/regressiontests/queries/tests.py", line
 1275, in test_tickets_8921_9188
 ['', '']
   File "/home/kmtracey/django/trunk/django/test/testcases.py", line 512,
 in assertQuerysetEqual
 return self.assertEqual(map(transform, qs), values)
 AssertionError: Lists differ: ['', '', '', '']

 First differing element 1:
 
 

 First list contains 1 additional elements.
 First extra element 2:
 

 - ['', '', '']
 ?  -

 + ['', '']

 --
 Ran 2853 tests in 11845.811s

 FAILED (failures=2, skipped=63, expected failures=2)
 Destroying test database 'default'...
 Destroying test database 'other'...

 }}}

 Running the queries and initial_sql_regress tests in isolation fail as
 well, so it's not necessary to run the full suite to see the errors. Have
 not looked into the errors at all, running the test suite in this config
 takes a while and now it is bedtime

-- 
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-upda...@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] #14647: ModelForm fields' non-uniqueness errors aren't customizable

[Django]

#14647: ModelForm fields' non-uniqueness errors aren't customizable
-+--
  Reporter:  teolicy | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  1.2   
Resolution:  duplicate   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

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

Comment:

 There is already an open ticket for this: #8913.

-- 
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-upda...@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] #494: Collapse in admin interface for inline related objects

[Django]

#494: Collapse in admin interface for inline related objects
---+
  Reporter:  jcsto...@nilling.nl   | Owner:  aptiko 
 
Status:  reopened  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  edit_inline, 
nfa-someday
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  1  
 
Needs_better_patch:  1 |  
---+
Changes (by anonymous):

 * cc: kmike (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-upda...@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] #11101: Oracle fails admin_view tests when the whole suite is run -- transaction problem?

[Django]

#11101: Oracle fails admin_view tests when the whole suite is run -- transaction
problem?
---+
  Reporter:  mboersma  | Owner:  mboersma   

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
transaction test
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by ikelly):

 After going through the test suite, here's what I've found:

 The views, admin_views, and model_formsets test suites are still getting a
 single 'unique constraint violated' error each.  I don't know why yet, and
 it may be unrelated, but at least that's a heck of a lot better than
 before.

 The backends test suite is getting a couple of errors that look like this:
 {{{
 DatabaseError: ORA-02091: transaction rolled back
 ORA-02291: integrity constraint (DJANGO_TEST_DEFAULT.SYS_C001650670)
 violated - parent key not found
 }}}

 And the fixtures_regress test suite is getting a failure that is caused by
 the patch:
 {{{
 ==
 FAIL: test_duplicate_pk
 (regressiontests.fixtures_regress.tests.TestFixtures)
 --
 Traceback (most recent call last):
   File
 
"/home/ikelly/projects/django.trunk/tests/regressiontests/fixtures_regress/tests.py",
 line 60, in test_duplicate_pk
 self.assertEqual(animal.id, 2)
 AssertionError: 12L != 2
 }}}
 This happens because the sequence value no longer gets decreased when the
 sequence is reset.  That's not really what the test is meant to be
 testing, however, and I would suggest that it perhaps should be replaced
 with assertGreaterEqual.

 There are a handful of other failures that don't appear to be related to
 this issue.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #3400: Support for lookup separator with list_filter admin option

[Django]

#3400: Support for lookup separator with list_filter admin option
---+
  Reporter:  n...@intv.com.au  | Owner:  DrMeers
 
Status:  assigned  | Milestone:  1.3
 
 Component:  django.contrib.admin  |   Version:  newforms-admin 
 
Resolution:|  Keywords:  edc nfa-someday 
list_filter FilterSpec nfa-changelist ep2008
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by mark0978):

 * cc: mark0978 (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-upda...@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] #14642: save_as=True and generic inline in admin gives IndexError

[Django]

#14642: save_as=True and generic inline in admin gives IndexError
---+
  Reporter:  si...@hostit.se   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  django.contrib.admin  |   Version:  1.2
   
Resolution:|  Keywords:  save_as generic 
inline
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by cmarrer):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * milestone:  => 1.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-upda...@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] #12028: Generic Inline doesn't validate unique_together

[Django]

#12028: Generic Inline doesn't validate unique_together
---+
  Reporter:  diverman  | Owner: 
 
Status:  new   | Milestone:  1.3
 
 Component:  Contrib apps  |   Version:  1.2
 
Resolution:|  Keywords:  content type generic 
inline unique validation formset admin modeladmin model
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by cmarrero):

  * version:  SVN => 1.2
  * milestone:  => 1.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-upda...@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] #11101: Oracle fails admin_view tests when the whole suite is run -- transaction problem?

[Django]

#11101: Oracle fails admin_view tests when the whole suite is run -- transaction
problem?
---+
  Reporter:  mboersma  | Owner:  mboersma   

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
transaction test
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by andrewsk):

 * cc: andrewsk (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-upda...@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] #14660: Using a CheckboxSelectMultiple widget on a M to M field in Admin causes 'SelectBox is not defined' JS error in RelatedObjectLookups.js

[Django]

#14660: Using a CheckboxSelectMultiple widget on a M to M field in Admin causes
'SelectBox is not defined' JS error in RelatedObjectLookups.js
---+
  Reporter:  sloggz| Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by sloggz):

  * needs_better_patch:  => 0
  * component:  Uncategorized => django.contrib.admin
  * 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-upda...@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] #14660: Using a CheckboxSelectMultiple widget on a M to M field in Admin causes 'SelectBox is not defined' JS error in RelatedObjectLookups.js

[Django]

#14660: Using a CheckboxSelectMultiple widget on a M to M field in Admin causes
'SelectBox is not defined' JS error in RelatedObjectLookups.js
---+
 Reporter:  sloggz |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 (Using Django 1.2.1)

 Form and Model given like so:

 forms.py:

 {{{

 class PictureGalleryForm(ModelForm):
 class Meta:
 model=PictureGallery
 widgets = {
 'pictures' : CheckboxSelectMultiple,

 }


 }}}


 models.py:

 {{{

 class GalleryCommon(models.Model):
 date_created = models.DateTimeField(auto_now_add=True)
 date_updated = models.DateTimeField(auto_now=True)
 title = models.CharField(max_length=256)

 class Meta:
 abstract = True

 class PictureGallery(GalleryCommon):
 pictures = models.ManyToManyField(Picture, related_name="pic_gallery",
 help_text="Select Gallery Images.")

 def __unicode__(self):
 return (self.title)
 }}}



 To encounter the error, register PictureGallery with admin using the
 PictureGalleryForm and click the green plus arrow to add a picture.
 On clicking the save button in the popup admin window, the picture will
 save, but the popup will hang at line 92 of RelatedObjectLookup.js .

 The error is 'SelectBox is not defined.'

 Assume this occurs because somehow the 'if' statement at line 76 goes
 wrong.

 As best I can tell this is similar to tickets #7133, #5731, and #10191 but
 not the same.

-- 
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-upda...@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] #11101: Oracle fails admin_view tests when the whole suite is run -- transaction problem?

[Django]

#11101: Oracle fails admin_view tests when the whole suite is run -- transaction
problem?
---+
  Reporter:  mboersma  | Owner:  mboersma   

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
transaction test
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by ikelly):

  * 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-upda...@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] #25: Filtering interface on ForeignKey boxes

[Django]

#25: Filtering interface on ForeignKey  boxes
---+
  Reporter:  adrian| Owner:  cpharmston
Status:  assigned  | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: eppsilon (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-upda...@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] #11101: Oracle fails admin_view tests when the whole suite is run -- transaction problem?

[Django]

#11101: Oracle fails admin_view tests when the whole suite is run -- transaction
problem?
---+
  Reporter:  mboersma  | Owner:  mboersma   

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
transaction test
 Stage:  Accepted  | Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by ikelly):

 I've attached a patch that appears to fix the problem, although I haven't
 yet run the entire test suite to verify.  The patch drops the ALTER
 SEQUENCE statements from the reset PL/SQL and instead just spins the
 sequence until the sequence value is large enough to avoid a conflict with
 an existing row.  This way the current transaction is unaffected, at the
 cost of reduced efficiency and that the reset code will no longer ever
 decrease the sequence value.  The latter is arguably a good thing anyway.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #11101: Oracle fails admin_view tests when the whole suite is run -- transaction problem?

[Django]

#11101: Oracle fails admin_view tests when the whole suite is run -- transaction
problem?
---+
  Reporter:  mboersma  | Owner:  mboersma   

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
transaction test
 Stage:  Accepted  | Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 Our move from doctests to unit tests for the Django test has exacerbated
 this problem and it can be seen even in the most basic tests that use
 fixtures, e.g.
 
`modeltests.fixtures.FixtureLoadingTests.{test_compress_format_loading,test_compressed_loading}`
 in that order. The second test method doesn't get a clean DB state, when
 it starts the DB contains an `Article` record loaded from the
 `initial_data` fixture (expected) AND the record loaded by the `loaddata`
 management call in the previous test method (unexpected).

 Failure rate of our suite under Oracle is currently very high because this
 basic unit test assumption is broken.

 AFAICS, this issue can affect any app test case that uses fixtures, not
 only the Django test suite.

-- 
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-upda...@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] #8424: Implement time filters

[Django]

#8424: Implement time filters
---+
  Reporter:  gnuvince  | Owner:  UloPe  
   
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version: 
   
Resolution:|  Keywords:  datetime 
filter hour minute second
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  1  
   
Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 Docs in the patch: "This will match every record with a pub_date that
 occurred between  3:00 AM and 3:59 AM."

 3:59:15 AM is not between 3:00 AM and 3:59 AM but it should be matched.

-- 
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-upda...@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] #14659: Assigning floats to DecimalFields

[Django]

#14659: Assigning floats to DecimalFields
--+-
 Reporter:  maraujop  |   Owner:  maraujop  
   Status:  new   |   Milestone:  1.3   
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:  DecimalField, float   |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 {{{DecimalField}}} does not accept a float as a parameter, as it should be
 first converted to a string. So if you have {{{DecimalField}}} in a model,
 you will not be able to assign a float to it.

 {{{
 class Item(models.Model):
 weight = models.DecimalField(max_digits=7, decimal_places = 2)

 Item.objects.create(weight=100.43)
 }}}

 The patch passes Django tests, regards

 Miguel Araujo

-- 
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-upda...@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] #14658: DateField initial does not honor locale, against documentation

[Django]

#14658: DateField initial does not honor locale, against documentation
---+
 Reporter:  intgr  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The documentation at
 
http://docs.djangoproject.com/en/dev/ref/forms/fields/#django.forms.Field.initial
 suggests that when passing the `intial=` argument to Date``Field, it's
 converted to the locale date format:
 {{{
 >>> import datetime
 >>> class DateForm(forms.Form):
 ... day = forms.DateField(initial=datetime.date.today)
 >>> print DateForm()
 Day:
 }}}

 Notice that `value="12/23/2008"` is localized.

 However, this does not seem to work in practice:
 {{{
 In [1]: from django import forms

 In [2]: import datetime

 In [3]: class DateForm(forms.Form):
...: day = forms.DateField(initial=datetime.date.today)

 In [4]: print DateForm()
 Day:
 }}}
 Notice above `value="2010-11-10"` -- it behaves this way in both Django
 1.2.3 and in trunk.

 Compare this to what the templater uses with its `|date` filter:

 {{{
 In [10]: from django.template import Template, Context

 In [11]: t=Template("{{ foo|date }}")

 In [12]: t.render(Context({'foo': datetime.date.today()}))
 Out[12]: u'10.11.2010'

 In [13]: from django.conf import settings

 In [14]: settings.DATE_FORMAT
 Out[14]: 'd.m.Y'

 In [15]: settings.DATETIME_FORMAT
 Out[15]: 'd.m.Y H:M:s'

 In [16]: settings.USE_L10N
 Out[16]: True
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #3304: [patch] Support "httponly"-attribute in session cookie.

[Django]

#3304: [patch] Support "httponly"-attribute in session cookie.
-+--
  Reporter:  arvin   | Owner:  nobody  
Status:  new | Milestone:  
 Component:  Core framework  |   Version:  SVN 
Resolution:  |  Keywords:  session security
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  1   
Needs_better_patch:  0   |  
-+--
Comment (by lukeplant):

 Replying to [comment:29 cyounkins]:

 > Does Django have a vulnerability? No. Is Django empowering users to
 secure their apps? No. And I think it should.

 We absolutely agree, and have consistently sought to do just that - we
 have excellent out-of-the-box behaviour and APIs for all kinds of security
 issues.  Russell's comment was about whether this feature should be
 backported to our bug fix branch or not.  The answer is it shouldn't, as
 it is a new feature, and it is not a "security issue" in the sense that is
 relevant for our policy regarding backporting security fixes. But we do
 want to add it to trunk, and would do so much quicker if a patch appeared
 that addressed the current deficiencies - namely the need for tests. The
 patch also needs to be updated for [12282] AFAICS.

-- 
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-upda...@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] #3304: [patch] Support "httponly"-attribute in session cookie.

[Django]

#3304: [patch] Support "httponly"-attribute in session cookie.
-+--
  Reporter:  arvin   | Owner:  nobody  
Status:  new | Milestone:  
 Component:  Core framework  |   Version:  SVN 
Resolution:  |  Keywords:  session security
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  1   
Needs_better_patch:  0   |  
-+--
Comment (by cyounkins):

 "While HTTP-only cookies will prevent a certain class of attack from being
 possible, there is no evidence of an in-theory or an in-practice actual
 attack on code for which the Django project itself is responsible."

 This comment represents a serious flaw in the way Django developers are
 handling security. Django is a key part of any user-created applications,
 and thus the security of user applications is intertwined with the
 security of Django.

 Does Django have a vulnerability? No. Is Django empowering users to secure
 their apps? No. And I think it should.

 Django developers need to develop a sense of responsibility for the
 security of user applications. The responsibility is not Django's alone of
 course, and certainly the developer is also to blame, but framework
 developers need to provide usable security controls to aid users.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #14657: Extra select fields are merged into 'GROUP BY'

[Django]

#14657: Extra select fields are merged into 'GROUP BY'
--+-
 Reporter:  Gregory   |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:  extra_select, |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Fields are merged into 'GROUP BY', when using some extra select fields and
 query.group_by attribute.

 {{{
 fragments = Fragment.objects.all().extra(
 select = {'au_names': 'GROUP_CONCAT(lib_author.surnames ORDER
 BY names DESC SEPARATOR ", ")'},
 )
 fragments.query.group_by = ['lib_fragment.id']
 fragments.query.join((None, 'lib_fragment', None, None))

 connection = (
 'lib_fragment',
 'lib_fragment_authors',
 'id',
 'fragment_id',
 )
 fragments.query.join(connection, promote=True)

 connection = (
 'lib_fragment_authors',
 'lib_author',
 'author_id',
 'id',
 )
 fragments.query.join(connection, promote=True)
 }}}


 {{{
 SELECT
 (GROUP_CONCAT(lib_author.surnames ORDER BY names DESC SEPARATOR ", "))
 AS `au_ids`,
 FROM `lib_fragment`
 LEFT OUTER JOIN `lib_fragment_authors` ON (`lib_fragment`.`id` =
 `lib_fragment_authors`.`fragment_id`)
 LEFT OUTER JOIN `lib_author` ON (`lib_fragment_authors`.`author_id` =
 `lib_author`.`id`)
 GROUP BY (lib_fragment.id), (GROUP_CONCAT(lib_author.surnames ORDER BY
 names DESC SEPARATOR ", "))
 ORDER BY `lib_fragment`.`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-upda...@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] #14057: Expose an interface for custom-escaping template content

[Django]

#14057: Expose an interface for custom-escaping template content
-+--
  Reporter:  steveire| Owner:  nobody
Status:  reopened| Milestone:
 Component:  Template system |   Version:
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  1 
Needs_better_patch:  0   |  
-+--
Comment (by willhardy):

 As mentioned before, I can think of three classes of filters:

 '''1. Filters that don't prevent escaping'''

 The first patch seems to cover this group.

 '''2. Filters that explicitly mark the output as safe'''

 These filters often take an `autoescape` parameter (`.needs_autoescape`),
 which means they can use the custom function that is passed in. The
 filters that don't currently do this, can simply add it.

 '''3. Filters that don't taint output (`myfilter.is_safe = True`)'''

 I've written a second patch that would allow these filters to operate
 safely.

 It does this by defining an "autoescape context" (another name can be
 chosen to avoid confusion with template contexts). By default, the
 autoescape context is "html". Custom escape functions can define a
 different context (eg "latex") and custom filters can do the same. Custom
 escape functions can also define a whitelist of filters that are ok for
 the given context.

 For example:
 {{{
 def rtfescape(value):
 return value.replace('\\', '')
 .replace('{','\\{')
 .replace('}', '\\}')
 rtfescape.autoescape_context = "rtf"
 rtfescape.safe_filters = set(['lower'])
 }}}

 All new filters that are designed to be safe in the RTF context can be
 written as follows:
 {{{
 @stringfilter
 def myupper(value):
 return value.upper()
 upper.autoescape_context = "rtf"
 }}}

  Using a filter from a different context on safe data will cause it to be
 escaped, even though the filter may operate safely. There are three
 possible solutions, the choice of which would depend on what you have
 access to change (the escape function, the filter or the template code).
 If you can change the escape function, you can add the filter to
 `safe_filters`. If you have access to the filter, you can define the
 appropriate context using `.autoescape_context`. If you (only) have access
 to the template, you can add the `|safe` filter to your variables.

 Two imperfections I can see with this approach are:

  * that the filter's name doesn't actually correspond to a specific known
 filter: default filters can be overridden by custom filters.
  * the name "autoescape context" could be better, as "context" is already
 used in templates

-- 
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-upda...@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] #14638: to_python howto documentation improvement

[Django]

#14638: to_python howto documentation improvement
+---
  Reporter:  maraujop   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords:  to_python, model, field
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by maraujop):

 Thanks gabrielhurley,

 That makes sense. I have changed my code and now {{{ to_python }}} is
 being called as I was expecting. I have to say I've lost a lot of hours
 trying to figure this out and the documentation could be much clear on
 this. When I was asking this online, stackoverflow and IRC, people were
 answering {{{ to_python }}} (that's what I thought before asking the first
 time), but I was saying, no, it's not being called.

 Beware that you don't subclass {{{ SubfieldBase }}}. {{{ SubfieldBase }}}
 is a metaclass. So now I'm subclassing {{{ DecimalField }}} with {{{
 SubfieldBase }}} as a metaclass and It works as I wanted.

 I totally agree that the docs should stress this more heavily, but I also
 think some parts should be rewritten to be more coherent. I will make a
 quote from the docs as an example:

 {{{
 If you use SubfieldBase, to_python() will be called every time an instance
 of the field is assigned a value. This means that whenever a value may be
 assigned to the field, you need to ensure that it will be of the correct
 datatype, or that you handle any exceptions.
 }}}

 This is not true. If you use SubfieldBase to_python will be called when
 assigning a value and when getting the value from the database.

 {{{
 Converts a value as returned by your database (or a serializer) to a
 Python object.
 }}}

 True, but if only you are using {{{ SubfieldBase }}} and not completely
 true, as it does more than that as you know.

 Thank you very much for your help, I had already desisted on this
 Miguel Araujo

-- 
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-upda...@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] #8424: Implement time filters

[Django]

#8424: Implement time filters
---+
  Reporter:  gnuvince  | Owner:  UloPe  
   
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version: 
   
Resolution:|  Keywords:  datetime 
filter hour minute second
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  1  
   
Needs_better_patch:  1 |  
---+
Comment (by ramiro):

 Last thunk of latest patch

 {{{
 --- a/tests/regressiontests/null_queries/tests.py
 +++ b/tests/regressiontests/null_queries/tests.py
 @@ -53,17 +53,17 @@ class NullQueriesTests(TestCase):
  """
  obj = OuterA.objects.create()
  self.assertQuerysetEqual(
 -OuterA.objects.filter(inner__second=None),
 +OuterA.objects.filter(inner__secondary=None),
  ['']
  )
  self.assertQuerysetEqual(
 -OuterA.objects.filter(inner__second__data=None),
 +OuterA.objects.filter(inner__secondary__data=None),
  ['']
  )

  inner_obj = Inner.objects.create(first=obj)
  self.assertQuerysetEqual(
 -Inner.objects.filter(first__inner__second=None),
 +Inner.objects.filter(first__inner__secondary=None),
  ['']
  )

 }}}

 reveals something potentially dangerous. FTR, from a django-dev IRC
 channel discussion about it:

 {{{
 cramm: hrm, looking at the patch for #8424.
 cramm: Specifically the last thunk. Adding new filtering lookups like
 'hour', 'second', ...  means there could be clashes with existing
 identically named model fields?
 cramm: I mean, in user apps
 Alex_Gaynor cramm: yeah, it would
 Alex_Gaynor: I'd much rather wait for us to have a real solution to
 alternate filtering, but that won't be 1.4 at the earliest
 carljm: cramm, Alex_Gaynor: dunno, I'm inclined to think these are obvious
 omissions.
 carljm: i.e. "wait till we have custom filtering" doesn't make sense to
 me.
 Alex_Gaynor: carljm: unless it breaks everyone's fields named hour,
 second, minute
 carljm: yes. that, of course, is icky.
 carljm: that shouldn't be a problem, though. can't the splitter be
 smarter?
 carljm: i.e. only DateTimeFields can have these lookups
 carljm: and only related fields can be traversed.
 carljm: you can't traverse across a DateTimeField to a related object.
 Alex_Gaynor: carljm: it could, ATM it's not
 carljm: right. so it's a "patch needs improvement" situation, then.
 }}}

-- 
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-upda...@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] #14656: Atom1Feed should write atom:published element

[Django]

#14656: Atom1Feed should write atom:published element
+---
 Reporter:  ttenc...@gmail.com  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  RSS framework   | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 `Atom1Feed` currently produces XML like this:

 {{{
 #!xml
 
   ..
   
   2010-10-18T00:00:00+02:00
   ...
   ...
   ...
 
 }}}

 The thing to note here is that the date goes in the `atom:updated`
 element, not the `atom:published` element.

 The [http://tools.ietf.org/html/rfc4287#page-23 RFC] clearly suggests to
 me that this is not the intended usage:

 {{{
The "atom:updated" element is a Date construct indicating the most
recent instant in time when an entry or feed was modified in a way
the publisher considers significant.  Therefore, not all
modifications necessarily result in a changed atom:updated value.
 }}}

 Whereas:

 {{{
The "atom:published" element is a Date construct indicating an
instant in time associated with an event early in the life cycle of
the entry.
 }}}

 This is more than just a theoretical problem. Google Reader, for example,
 does not seem to use the updated element, and uses the date that it first
 saw the item appear. As a result, it does not order the items properly
 upon first import of the feed.

 The code in Django responsible for this:

 `django/utils/feedgenerator.py:331`

 {{{
 #!python
 if item['pubdate'] is not None:
 handler.addQuickElement(u"updated",
 rfc3339_date(item['pubdate']).decode('utf-8'))
 }}}

 There appears to be no mention of the `published` element.

 I suggest also writing the `published` element, because this is the
 intended usage of that element. The `updated` element is mandatory, so it
 should still be written as well.

 However, maybe this needs review by someone who knows more about Atom and
 the peculiarities of various feed readers.

-- 
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-upda...@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] #14655: formsets should be iterable

[Django]

#14655: formsets should be iterable
-+--
  Reporter:  kenth   | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by kenth):

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

Comment:

 Another use of `__iter__` in formsets is to allow a formset panel of
 questions to be presented in random order. Override `__iter__` to assign a
 random number to each form, and then display in sorted order.

-- 
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-upda...@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] #11906: QuerySet._fill_cache is not thread-safe

[Django]

#11906: QuerySet._fill_cache is not thread-safe
---+
  Reporter:  mrts  | Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:|  Keywords:  threading 
thread
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by DavidReynolds):

 * cc: DavidReynolds (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-upda...@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] #14652: Sessions seem to be improperly using Pickle to hash a dictionary

[Django]

#14652: Sessions seem to be improperly using Pickle to hash a dictionary
--+-
  Reporter:  PaulM| Owner:  nobody
Status:  closed   | Milestone:  1.3   
 Component:  django.contrib.sessions  |   Version:  1.2   
Resolution:  invalid  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by lukeplant):

 Replying to [comment:2 PaulM]:
 > A differently ordered but valid pickle of the same data will still
 produce a different MAC

 True

 > and so fail our check.

 False, because we don't compare the pickle of the new data to the pickle
 of the old data (or the hashes of those pickles).

 It simply does not matter that pickle doesn't necessarily produce the same
 results twice.  As far as the MAC step is concerned, the pickled string is
 simply an opaque string that needs signing.  The origin of that string,
 and what process is used to generate it, is completely irrelevant as far
 as HMAC is concerned. We are storing an opaque string and the HMAC of that
 string, and neither can 'change' - or rather the point is that if either
 'changes' (by someone tampering with the data) we will know about it.

 Once we've checked the integrity of our opaque string, we then go on to
 unpickle it. At this point, the '''only''' thing required is that
 `pickle.loads` will correctly load the data.  At this point, the
 `pickle.dumps()` of the restored data might be completely different, but
 that makes no difference.  We would have a problem if we had code that did
 this:

 {{{
 #!python
 restored_data = pickle.loads(saved_data)
 if MAC(pickle.dumps(restored_data)) != saved_hash:
 return {}
 else:
 return restored_data
 }}}

 But we don't. Instead we do this:

 {{{
 #!python
 hash, pickled = encoded_data.split(':', 1)
 expected_hash = self._hash(pickled)
 if not constant_time_compare(hash, expected_hash):
 raise SuspiciousOperation("Session data corrupted")
 else:
 return pickle.loads(pickled)
 }}}


 Our process requires the following properties:

  1. `pickle.dumps` can be used to serialise our values to a string
  2. HMAC can be used to verify the integrity and authenticity of a string
  3. `pickle.loads` can be used to restore the value produced by 1. to the
 same data originally stored (where 'same' means Python equality, `==`, not
 `is`).

 All of these are satisfied, and further properties of pickle are not
 relevant. Tim's e-mail is about a completely different process - in which
 someone was effectively trying to take the pickle of two values and use
 the pickled string to compare those values.  This fails because
 `pickle.dumps` is multi-valued in its output i.e. the same input can
 produce different output.

-- 
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-upda...@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] #9771: Wrong form action

[Django]

#9771: Wrong form action
+---
  Reporter:  tutonien   | Owner:  jacob 

Status:  closed | Milestone:

 Component:  Documentation  |   Version:  1.0   

Resolution:  wontfix|  Keywords:  tutorial, form, post, 
action, absolute
 Stage:  Accepted   | Has_patch:  0 

Needs_docs:  0  |   Needs_tests:  0 

Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

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

Comment:

 I'm in agreement with the assessment that practicality wins in this
 instance. The tutorial should be simple, understandable, and "just work".

 If you want to make your app pluggable you need to be using the `{% url
 %}` tag and/or `get_absolute_url` to be getting these attributes
 dynamically, which is outside the current scope of the tutorial. Using a
 hard-coded relative path is (IMHO) just as bad as using a less-pluggable
 absolute path. It's already been proven to be just as fraught with error.

 If someone wants to suggest that the tutorial cover named views and using
 the `{% url %}` tag then a new ticket should be opened for it.

 As such, I'm closing this as a 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-upda...@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] #14638: to_python howto documentation improvement

[Django]

#14638: to_python howto documentation improvement
+---
  Reporter:  maraujop   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords:  to_python, model, field
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by gabrielhurley):

 So I have an answer for your question, but not a right answer for the
 documentation... here's the answer to your question:

 You are not seeing `to_python` called because you are subclassing
 `DecimalField`. For one, all of the standard Django field types subclass
 Field, which *does not* subclass SubfieldBase (which guarantees
 `to_python` being called). Second, `DecimalField` registers a separate
 database conversion callback function for sqlite (and others). These types
 of functions exist to handle the vagaries of the different backends. There
 are a handful of fields that use this behavior, but which fields may vary
 by backend. Since they use custom conversion functions
 (`django.db.backends.util.typecast_decimal` in this case) they bypass
 `to_python` on the return trip from the db. `to_python` *is* called during
 validation on the field (such as when saving the model).

 Effectively, if you are subclassing existing fields, `to_python` is not
 guaranteed to be called, and that behavior may be backend-dependent. If
 you want it to be called consistently, you should do as the docs say, and
 subclass `SubfieldBase`.

 There is a takeaway message from all this that should be encapsulated in
 the docs, but at present I'm not quite sure what that message is. Given
 that this is a how-to doc, and `SubfieldBase` is addressed earlier in the
 doc I'm inclined to say that the docs should simply stress subclassing
 `SubfieldBase` more heavily, with a little more warning about subclassing
 existing fields...

 Input from others is welcome.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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.