date:20100702

Re: [Django] #13872: "AttributeError: 'module' object has no attribute 'day_abbr'" when using Admin to add instance of model with DateField, TimeField, or DateTimeField

2010-07-02 Thread Django

#13872: "AttributeError: 'module' object has no attribute 'day_abbr'" when using
Admin to add instance of model with DateField, TimeField, or DateTimeField
---+
  Reporter:  Lexo  | Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  django.contrib.admin  |   Version:  1.2
 
Resolution:  worksforme|  Keywords:  attributeerror 
module day_abbr strptime datefield datetime datetimefield timefield admin
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by Lexo):

 Yup - a fresh install of Python (not just Django) solved this. Thanks
 again for your help.

-- 
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] #13872: "AttributeError: 'module' object has no attribute 'day_abbr'" when using Admin to add instance of model with DateField, TimeField, or DateTimeField

2010-07-02 Thread Django

#13872: "AttributeError: 'module' object has no attribute 'day_abbr'" when using
Admin to add instance of model with DateField, TimeField, or DateTimeField
---+
  Reporter:  Lexo  | Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  django.contrib.admin  |   Version:  1.2
 
Resolution:  worksforme|  Keywords:  attributeerror 
module day_abbr strptime datefield datetime datetimefield timefield admin
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by Lexo):

 Thanks for looking into this. I thought it might have been something like
 that too, which is why I started a new project named Foobar, with app Foo,
 and models Bar and Baz. I'm just going to try a fresh install of Python
 and Django.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #13874: get_image_dimensions should seek to 0

2010-07-02 Thread Django

#13874: get_image_dimensions should seek to 0
+---
 Reporter:  rcatherman  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Passing in a file-like object that is not set at 0 causes this method to
 fail.

 Workaround:  caller seeks back to 0 before calling

-- 
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] #13872: "AttributeError: 'module' object has no attribute 'day_abbr'" when using Admin to add instance of model with DateField, TimeField, or DateTimeField

2010-07-02 Thread Django

#13872: "AttributeError: 'module' object has no attribute 'day_abbr'" when using
Admin to add instance of model with DateField, TimeField, or DateTimeField
---+
  Reporter:  Lexo  | Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  django.contrib.admin  |   Version:  1.2
 
Resolution:  worksforme|  Keywords:  attributeerror 
module day_abbr strptime datefield datetime datetimefield timefield admin
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by lrekucki):

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

Comment:

 Tested on a clean project with versions you gave. I'm guessing you named
 one of your apps or some other module "calendar" which breaks the built-in
 python module. Rename your app/module and it should work fine.
 [http://groups.google.com/group/django-
 
users/browse_thread/thread/ac8edf1d28c8ec54/2275a1b175a8a2dc?lnk=gst&q='module'+object+has+no+attribute+'day_abbr'#
 A similar problem on django-users from the past].

-- 
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] #13872: "AttributeError: 'module' object has no attribute 'day_abbr'" when using Admin to add instance of model with DateField, TimeField, or DateTimeField

2010-07-02 Thread Django

#13872: "AttributeError: 'module' object has no attribute 'day_abbr'" when using
Admin to add instance of model with DateField, TimeField, or DateTimeField
---+
  Reporter:  Lexo  | Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  1.2
 
Resolution:|  Keywords:  attributeerror 
module day_abbr strptime datefield datetime datetimefield timefield admin
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Old description:

> I'm running Django 1.2.1 on Python 2.5.4
>
> Whenever I try to add a new instance of a model that contains one of
> either DateTimeField, DateField, or TimeField, I get "AttributeError:
> 'module' object has no attribute 'day_abbr'"
>
> I have a feeling it's related to
> [http://code.djangoproject.com/ticket/13560] but I'm not sure.
>
> Here are my models. Adding a Baz works just fine, but adding a Bar causes
> the exception:
>
> {{{from django.db import models
>
> class Bar(models.Model):
> name = models.TextField()
> publish_date = models.DateTimeField()
>

> class Baz(models.Model):
> name = models.CharField(max_length = 10)
> age = models.IntegerField()
> }}}
>
> And a traceback:
> {{{Environment:
>
> Request Method: POST
> Request URL: http://localhost:8000/admin/foo/bar/add/
> Django Version: 1.2.1
> Python Version: 2.5.4
> Installed Applications:
> ['django.contrib.auth',
>  'django.contrib.contenttypes',
>  'django.contrib.sessions',
>  'django.contrib.messages',
>  'django.contrib.admin',
>  'foobar.foo']
> Installed Middleware:
> ('django.middleware.common.CommonMiddleware',
>  'django.contrib.sessions.middleware.SessionMiddleware',
>  'django.middleware.csrf.CsrfViewMiddleware',
>  'django.contrib.auth.middleware.AuthenticationMiddleware',
>  'django.contrib.messages.middleware.MessageMiddleware')
>

> Traceback:
> File "C:\Python25\Lib\site-packages\django\core\handlers\base.py" in
> get_response
>   100. response = callback(request, *callback_args,
> **callback_kwargs)
> File "C:\Python25\Lib\site-packages\django\contrib\admin\options.py" in
> wrapper
>   239. return self.admin_site.admin_view(view)(*args,
> **kwargs)
> File "C:\Python25\Lib\site-packages\django\utils\decorators.py" in
> _wrapped_view
>   76. response = view_func(request, *args, **kwargs)
> File "C:\Python25\Lib\site-packages\django\views\decorators\cache.py" in
> _wrapped_view_func
>   69. response = view_func(request, *args, **kwargs)
> File "C:\Python25\Lib\site-packages\django\contrib\admin\sites.py" in
> inner
>   190. return view(request, *args, **kwargs)
> File "C:\Python25\Lib\site-packages\django\utils\decorators.py" in
> _wrapper
>   21. return decorator(bound_func)(*args, **kwargs)
> File "C:\Python25\Lib\site-packages\django\utils\decorators.py" in
> _wrapped_view
>   76. response = view_func(request, *args, **kwargs)
> File "C:\Python25\Lib\site-packages\django\utils\decorators.py" in
> bound_func
>   17. return func(self, *args2, **kwargs2)
> File "C:\Python25\Lib\site-packages\django\db\transaction.py" in
> _commit_on_success
>   299. res = func(*args, **kw)
> File "C:\Python25\Lib\site-packages\django\contrib\admin\options.py" in
> add_view
>   777. if form.is_valid():
> File "C:\Python25\Lib\site-packages\django\forms\forms.py" in is_valid
>   121. return self.is_bound and not bool(self.errors)
> File "C:\Python25\Lib\site-packages\django\forms\forms.py" in _get_errors
>   112. self.full_clean()
> File "C:\Python25\Lib\site-packages\django\forms\forms.py" in full_clean
>   267. self._clean_fields()
> File "C:\Python25\Lib\site-packages\django\forms\forms.py" in
> _clean_fields
>   284. value = field.clean(value)
> File "C:\Python25\Lib\site-packages\django\forms\fields.py" in clean
>   775. clean_data.append(field.clean(field_value))
> File "C:\Python25\Lib\site-packages\django\forms\fields.py" in clean
>   162. valu

[Django] #13873: Provide an explicit setting to skip tests for INSTALLED_APPS

2010-07-02 Thread Django

#13873: Provide an explicit setting to skip tests for INSTALLED_APPS
---+
 Reporter:  lakinwecker|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 When developing an application that depends on thirdparty django
 libraries, be it apps in contrib, or libraries like south or treebeard,
 you rarely want to run their tests as part of your normal testing routine.
 The latest treebeard library has somewhere around 600 tests!  And although
 it's great that it has such extensive tests (yay tabo!) - I rarely want to
 run them as part of my testing routine.  Rather than having to explicitly
 specify all of my apps everytime I test, a setting that explicitly asks
 for certain apps to be skipped it much nicer.

 I'm attaching a patch that implements just such a setting.  The patch has
 an implementation, tests and updates the documentation.

 The patch was made against r13409 - although I marked this as part of SVN
 - it would be awesome to see this released in the current releases - of
 course, I realize that may not be possible.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13872: "AttributeError: 'module' object has no attribute 'day_abbr'" when using Admin to add instance of model with DateField, TimeField, or DateTimeField

2010-07-02 Thread Django

#13872: "AttributeError: 'module' object has no attribute 'day_abbr'" when using
Admin to add instance of model with DateField, TimeField, or DateTimeField
--+
 Reporter:  Lexo
  |   Owner:  nobody
   Status:  new 
  |   Milestone:
Component:  django.contrib.admin
  | Version:  1.2   
 Keywords:  attributeerror module day_abbr strptime datefield datetime 
datetimefield timefield admin  |   Stage:  Unreviewed
Has_patch:  0   
  |  
--+
 I'm running Django 1.2.1 on Python 2.5.4

 Whenever I try to add a new instance of a model that contains one of
 either DateTimeField, DateField, or TimeField, I get "AttributeError:
 'module' object has no attribute 'day_abbr'"

 I have a feeling it's related to
 [http://code.djangoproject.com/ticket/13560] but I'm not sure.

 Here are my models. Adding a Baz works just fine, but adding a Bar causes
 the exception:

 {{{from django.db import models

 class Bar(models.Model):
 name = models.TextField()
 publish_date = models.DateTimeField()


 class Baz(models.Model):
 name = models.CharField(max_length = 10)
 age = models.IntegerField()
 }}}

 And a traceback:
 {{{Environment:

 Request Method: POST
 Request URL: http://localhost:8000/admin/foo/bar/add/
 Django Version: 1.2.1
 Python Version: 2.5.4
 Installed Applications:
 ['django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.messages',
  'django.contrib.admin',
  'foobar.foo']
 Installed Middleware:
 ('django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware')


 Traceback:
 File "C:\Python25\Lib\site-packages\django\core\handlers\base.py" in
 get_response
   100. response = callback(request, *callback_args,
 **callback_kwargs)
 File "C:\Python25\Lib\site-packages\django\contrib\admin\options.py" in
 wrapper
   239. return self.admin_site.admin_view(view)(*args,
 **kwargs)
 File "C:\Python25\Lib\site-packages\django\utils\decorators.py" in
 _wrapped_view
   76. response = view_func(request, *args, **kwargs)
 File "C:\Python25\Lib\site-packages\django\views\decorators\cache.py" in
 _wrapped_view_func
   69. response = view_func(request, *args, **kwargs)
 File "C:\Python25\Lib\site-packages\django\contrib\admin\sites.py" in
 inner
   190. return view(request, *args, **kwargs)
 File "C:\Python25\Lib\site-packages\django\utils\decorators.py" in
 _wrapper
   21. return decorator(bound_func)(*args, **kwargs)
 File "C:\Python25\Lib\site-packages\django\utils\decorators.py" in
 _wrapped_view
   76. response = view_func(request, *args, **kwargs)
 File "C:\Python25\Lib\site-packages\django\utils\decorators.py" in
 bound_func
   17. return func(self, *args2, **kwargs2)
 File "C:\Python25\Lib\site-packages\django\db\transaction.py" in
 _commit_on_success
   299. res = func(*args, **kw)
 File "C:\Python25\Lib\site-packages\django\contrib\admin\options.py" in
 add_view
   777. if form.is_valid():
 File "C:\Python25\Lib\site-packages\django\forms\forms.py" in is_valid
   121. return self.is_bound and not bool(self.errors)
 File "C:\Python25\Lib\site-packages\django\forms\forms.py" in _get_errors
   112. self.full_clean()
 File "C:\Python25\Lib\site-packages\django\forms\forms.py" in full_clean
   267. self._clean_fields()
 File "C:\Python25\Lib\site-packages\django\forms\forms.py" in
 _clean_fields
   284. value = field.clean(value)
 File "C:\Python25\Lib\site-packages\django\forms\fields.py" in clean
   775. clean_data.append(field.clean(field_value))
 File "C:\Python25\Lib\site-packages\django\forms\fields.py" in clean
   162. value = self.to_python(value)
 File "C:\Python25\Lib\site-packages\django\forms\fields.py" in to_python
   342. return datetime.date(*time.strptime(value,
 format)[:3])
 File "C:\Python25\lib\_strptime.py" in 
   272. _TimeRE_cache = TimeRE()
 File "C:\Python25\lib\_strptime.py" in __init__
   191. self.locale_time = LocaleTime()
 File "C:\Python25\lib\_strptime.py" in __init__
   74. self.__calc_weekday()
 File "C:\Python25\lib\_strptime.py"

Re: [Django] #6447: memcached does not support arbitrary string keys

2010-07-02 Thread Django

#6447: memcached does not support arbitrary string keys
---+
  Reporter:  nicois   | Owner:  carljm 
  
Status:  assigned  | Milestone: 
  
 Component:  Cache system  |   Version:  SVN
  
Resolution:|  Keywords:  
memcached
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by carljm):

 Comments on the above patch:

 1. I chose to make an invalid key an exception, rather than a warning. My
 feeling is cache code ought to be backend-portable, so if it'll blow up on
 memcached it might as well blow up elsewhere too. I'll change this if core
 devs prefer it as a warning.

 2. If the idea is that cache-code ought to be backend-portable, is there
 any reason for the dummy backend to still accept *args, **kwargs on most
 of its methods, where the other backends do not? What's the rationale for
 keeping this?

 3. As noted before, the design decision here is not to apply any
 additional key checking to the memcached backend, for speed reasons. The
 restrictions applied match memcached's restrictions (it appears that some
 control characters are accepted in keys by memcached itself, but python-
 memcached applies the same restrictions we apply here), so the result
 should be the same on all backends, except that memcached will raise a
 different exception.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] r13418 - django/branches/soc2010/test-refactor/tests/modeltests/fixtures

2010-07-02 Thread noreply

Author: PaulM
Date: 2010-07-02 14:14:58 -0500 (Fri, 02 Jul 2010)
New Revision: 13418

Modified:
   django/branches/soc2010/test-refactor/tests/modeltests/fixtures/tests.py
Log:
[soc2010/test-refactor] Can't use class decorators in python 2.4.


Modified: 
django/branches/soc2010/test-refactor/tests/modeltests/fixtures/tests.py
===
--- django/branches/soc2010/test-refactor/tests/modeltests/fixtures/tests.py
2010-07-02 19:07:56 UTC (rev 13417)
+++ django/branches/soc2010/test-refactor/tests/modeltests/fixtures/tests.py
2010-07-02 19:14:58 UTC (rev 13418)
@@ -230,7 +230,6 @@
 self._dumpdata_assert(['fixtures'], """
 News StoriesLatest news storiesTime to reform 
copyright2006-06-16 
13:00:00Poker has no place on ESPN2006-06-16 
12:00:00Python program becomes self 
aware2006-06-16 
11:00:00copyrightfixturesarticle3lawfixturesarticle3Django 
ReinhardtPrinceStephane 
Grappelli""", format='xml', natural_keys=True)
 
-...@skipifdbengine('django.db.backends.mysql')
 class FixtureTransactionTests(TransactionTestCase):
 def _dumpdata_assert(self, args, output, format='json'):
 new_io = StringIO.StringIO()
@@ -238,6 +237,7 @@
 command_output = new_io.getvalue().strip()
 self.assertEqual(command_output, output)
 
+@skipIfDBEngine('django.db.backends.mysql')
 def test_format_discovery(self):
 # Load fixture 1 again, using format discovery
 management.call_command('loaddata', 'fixture1', verbosity=0, 
commit=False)

-- 
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] r13417 - django/branches/soc2010/test-refactor/tests/modeltests/fixtures

2010-07-02 Thread noreply

Author: PaulM
Date: 2010-07-02 14:07:56 -0500 (Fri, 02 Jul 2010)
New Revision: 13417

Modified:
   django/branches/soc2010/test-refactor/tests/modeltests/fixtures/tests.py
Log:
[soc2010/test-refactor] updated fixtures tests to use @skipIfDBEngine() 
decorator


Modified: 
django/branches/soc2010/test-refactor/tests/modeltests/fixtures/tests.py
===
--- django/branches/soc2010/test-refactor/tests/modeltests/fixtures/tests.py
2010-07-02 19:06:53 UTC (rev 13416)
+++ django/branches/soc2010/test-refactor/tests/modeltests/fixtures/tests.py
2010-07-02 19:07:56 UTC (rev 13417)
@@ -1,10 +1,9 @@
 import StringIO
 import sys
 
-from django.test import TestCase, TransactionTestCase
+from django.test import TestCase, TransactionTestCase, skipIfDBEngine
 from django.conf import settings
 from django.core import management
-from django.db import DEFAULT_DB_ALIAS
 
 from models import Article, Blog, Book, Category, Person, Tag, Visa
 
@@ -22,7 +21,6 @@
 ])
 
 class FixtureLoadingTests(TestCase):
-
 def _dumpdata_assert(self, args, output, format='json', 
natural_keys=False):
 new_io = StringIO.StringIO()
 management.call_command('dumpdata', *args, **{'format':format, 
'stdout':new_io, 'use_natural_keys':natural_keys})
@@ -232,46 +230,46 @@
 self._dumpdata_assert(['fixtures'], """
 News StoriesLatest news storiesTime to reform 
copyright2006-06-16 
13:00:00Poker has no place on ESPN2006-06-16 
12:00:00Python program becomes self 
aware2006-06-16 
11:00:00copyrightfixturesarticle3lawfixturesarticle3Django 
ReinhardtPrinceStephane 
Grappelli""", format='xml', natural_keys=True)
 
-if settings.DATABASES[DEFAULT_DB_ALIAS]['ENGINE'] != 
'django.db.backends.mysql':
-class FixtureTransactionTests(TransactionTestCase):
-def _dumpdata_assert(self, args, output, format='json'):
-new_io = StringIO.StringIO()
-management.call_command('dumpdata', *args, **{'format':format, 
'stdout':new_io})
-command_output = new_io.getvalue().strip()
-self.assertEqual(command_output, output)
+...@skipifdbengine('django.db.backends.mysql')
+class FixtureTransactionTests(TransactionTestCase):
+def _dumpdata_assert(self, args, output, format='json'):
+new_io = StringIO.StringIO()
+management.call_command('dumpdata', *args, **{'format':format, 
'stdout':new_io})
+command_output = new_io.getvalue().strip()
+self.assertEqual(command_output, output)
 
-def test_format_discovery(self):
-# Load fixture 1 again, using format discovery
-management.call_command('loaddata', 'fixture1', verbosity=0, 
commit=False)
-self.assertQuerysetEqual(Article.objects.all(), [
-'',
-'',
-''
-])
+def test_format_discovery(self):
+# Load fixture 1 again, using format discovery
+management.call_command('loaddata', 'fixture1', verbosity=0, 
commit=False)
+self.assertQuerysetEqual(Article.objects.all(), [
+'',
+'',
+''
+])
 
-# Try to load fixture 2 using format discovery; this will fail
-# because there are two fixture2's in the fixtures directory
-new_io = StringIO.StringIO()
-management.call_command('loaddata', 'fixture2', verbosity=0, 
stderr=new_io)
-output = new_io.getvalue().strip().split('\n')
-self.assertEqual(len(output), 1)
-self.assertTrue(output[0].startswith("Multiple fixtures named 
'fixture2'"))
+# Try to load fixture 2 using format discovery; this will fail
+# because there are two fixture2's in the fixtures directory
+new_io = StringIO.StringIO()
+management.call_command('loaddata', 'fixture2', verbosity=0, 
stderr=new_io)
+output = new_io.getvalue().strip().split('\n')
+self.assertEqual(len(output), 1)
+self.assertTrue(output[0].startswith("Multiple fixtures named 
'fixture2'"))
 
-# object list is unaffected
-self.assertQuerysetEqual(Article.objects.all(), [
-'',
-'',
-''
-])
+# object list is unaffected
+self.assertQuerysetEqual(Article.objects.all(), [
+'',
+'',
+''
+])
 
-# Dump the current contents of the database as a JSON fixture
-self._dumpdata_assert(['fixtures'], '[{"pk": 1, "model": 
"fixtures.category", "fields": {"description": "Latest news stories", "title": 
"News Stories"}}, {"pk": 3, "model": "fixtures.article", "fields": {"headline": 
"Time to reform copyright", "pub_date": "2006-06-16 13:00:00"}}, {"pk": 2, 
"model": "fixtures.article", "fields": {"headline": "Poker has no place on 
ESPN", "pub_date": "2006-06-16 12:00:00"}}, {"pk": 1, "model": 
"fixtures.article", "fiel

[Changeset] r13416 - django/branches/soc2010/test-refactor/django/test

2010-07-02 Thread noreply

Author: PaulM
Date: 2010-07-02 14:06:53 -0500 (Fri, 02 Jul 2010)
New Revision: 13416

Modified:
   django/branches/soc2010/test-refactor/django/test/__init__.py
   django/branches/soc2010/test-refactor/django/test/utils.py
Log:
[soc2010/test-refactor] Added skipIfDBEngine() decorator to django.test


Modified: django/branches/soc2010/test-refactor/django/test/__init__.py
===
--- django/branches/soc2010/test-refactor/django/test/__init__.py   
2010-07-02 18:06:24 UTC (rev 13415)
+++ django/branches/soc2010/test-refactor/django/test/__init__.py   
2010-07-02 19:06:53 UTC (rev 13416)
@@ -4,3 +4,4 @@
 
 from django.test.client import Client
 from django.test.testcases import TestCase, TransactionTestCase
+from django.test.utils import skipIfDBEngine

Modified: django/branches/soc2010/test-refactor/django/test/utils.py
===
--- django/branches/soc2010/test-refactor/django/test/utils.py  2010-07-02 
18:06:24 UTC (rev 13415)
+++ django/branches/soc2010/test-refactor/django/test/utils.py  2010-07-02 
19:06:53 UTC (rev 13416)
@@ -2,9 +2,11 @@
 from django.conf import settings
 from django.core import mail
 from django.core.mail.backends import locmem
+from django.db import DEFAULT_DB_ALIAS
 from django.test import signals
 from django.template import Template
 from django.utils.translation import deactivate
+from django.utils.unittest import skipIf
 
 class ContextList(list):
 """A wrapper that provides direct key access to context items contained
@@ -77,3 +79,14 @@
 test_module = __import__(test_module_name, {}, {}, test_path[-1])
 test_runner = getattr(test_module, test_path[-1])
 return test_runner
+
+def skipIfDBEngine(engine, reason=None):
+"""
+Decorator to skip tests on a given database engine.
+
+Note that you can pass a single engine or an iterable here
+"""
+if not reason:
+reason = "not supported on this database"
+return skipIf(settings.DATABASES[DEFAULT_DB_ALIAS]['ENGINE'] in engine,
+  reason)

-- 
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] #13871: contrib.admin:list_editable - ForeignKey performance is O(m*n)

2010-07-02 Thread Django

#13871: contrib.admin:list_editable - ForeignKey performance is O(m*n)
---+
  Reporter:  chadc | Owner:  nobody 
   
Status:  new   | Milestone: 
   
 Component:  django.contrib.admin  |   Version:  1.2
   
Resolution:|  Keywords:  list_editable, 
admin, ForeignKey, admin efficiency
 Stage:  Unreviewed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by patrys):

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

Comment:

 Keep in mind the formset is using forms that can apply additional
 filtering to the data sets thus making each choice set unique. If you want
 to introduce some sort of caching, you pretty much have to cache by
 serialized query params. Also you need to make sure the cache is thread-
 safe and does not outlive the formset (your CachedSelect does not seem to
 ever invalidate the cache).

-- 
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] r13415 - django/branches/soc2010/test-refactor/tests/modeltests/field_defaults

2010-07-02 Thread noreply

Author: PaulM
Date: 2010-07-02 13:06:24 -0500 (Fri, 02 Jul 2010)
New Revision: 13415

Modified:
   
django/branches/soc2010/test-refactor/tests/modeltests/field_defaults/tests.py
Log:
[soc2010/test-refactor] Updated field_defaults to use unittest2 delta arg for 
assertAlmostEqual


Modified: 
django/branches/soc2010/test-refactor/tests/modeltests/field_defaults/tests.py
===
--- 
django/branches/soc2010/test-refactor/tests/modeltests/field_defaults/tests.py  
2010-07-02 17:53:09 UTC (rev 13414)
+++ 
django/branches/soc2010/test-refactor/tests/modeltests/field_defaults/tests.py  
2010-07-02 18:06:24 UTC (rev 13415)
@@ -1,5 +1,5 @@
 # coding: utf-8
-from datetime import datetime
+from datetime import datetime, timedelta
 
 from django.test import TestCase
 from django.utils.safestring import SafeUnicode, SafeString
@@ -29,9 +29,7 @@
 self.assertEqual(a.headline, u'Default headline')
 
 # make sure the two dates are sufficiently close
-#fixme, use the new unittest2 function
-d = now - a.pub_date
-self.assertTrue(d.seconds < 5)
+self.assertAlmostEqual(now, a.pub_date, delta=timedelta(5))
 
 # make sure that SafeString/SafeUnicode fields work
 a.headline = SafeUnicode(u'Iñtërnâtiônàlizætiøn1')

-- 
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] r13414 - django/branches/soc2010/test-refactor/tests/modeltests/expressions

2010-07-02 Thread noreply

Author: PaulM
Date: 2010-07-02 12:53:09 -0500 (Fri, 02 Jul 2010)
New Revision: 13414

Modified:
   django/branches/soc2010/test-refactor/tests/modeltests/expressions/tests.py
Log:
[soc2010/test-refactor] update expressions test to use unittest2 
assertItemsEqual


Modified: 
django/branches/soc2010/test-refactor/tests/modeltests/expressions/tests.py
===
--- django/branches/soc2010/test-refactor/tests/modeltests/expressions/tests.py 
2010-07-02 17:51:12 UTC (rev 13413)
+++ django/branches/soc2010/test-refactor/tests/modeltests/expressions/tests.py 
2010-07-02 17:53:09 UTC (rev 13414)
@@ -8,10 +8,6 @@
 class ExpressionsTestCase(TestCase):
 fixtures = ['f_expression_testdata.json']
 
-def assertItemsEqual(self, a, b):
-#fixme, replace with unittest2 function
-return self.assertEqual(sorted(a), sorted(b))
-
 def test_basic_f_expression(self):
 company_query = Company.objects.values('name','num_employees',
'num_chairs'

-- 
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] r13413 - django/branches/soc2010/test-refactor/django/utils/unittest

2010-07-02 Thread noreply

Author: PaulM
Date: 2010-07-02 12:51:12 -0500 (Fri, 02 Jul 2010)
New Revision: 13413

Modified:
   django/branches/soc2010/test-refactor/django/utils/unittest/case.py
Log:
[soc2010/test-refactor] small fix to allow unittest2 to compare ValuesQuerySet 
using assertItemsEqual


Modified: django/branches/soc2010/test-refactor/django/utils/unittest/case.py
===
--- django/branches/soc2010/test-refactor/django/utils/unittest/case.py 
2010-07-02 17:19:17 UTC (rev 13412)
+++ django/branches/soc2010/test-refactor/django/utils/unittest/case.py 
2010-07-02 17:51:12 UTC (rev 13413)
@@ -898,7 +898,7 @@
 expected.sort()
 actual = actual_seq[:]
 actual.sort()
-except TypeError:
+except (TypeError, AttributeError):
 # Unsortable items (example: set(), complex(), ...)
 expected = list(expected_seq)
 actual = list(actual_seq)

-- 
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] r13412 - django/branches/soc2010/test-refactor/tests/modeltests/custom_pk

2010-07-02 Thread noreply

Author: PaulM
Date: 2010-07-02 12:19:17 -0500 (Fri, 02 Jul 2010)
New Revision: 13412

Modified:
   django/branches/soc2010/test-refactor/tests/modeltests/custom_pk/tests.py
Log:
[soc2010/test-refactor] updated custom_pk modeltest to take advantage of 
unittest2


Modified: 
django/branches/soc2010/test-refactor/tests/modeltests/custom_pk/tests.py
===
--- django/branches/soc2010/test-refactor/tests/modeltests/custom_pk/tests.py   
2010-07-02 16:34:41 UTC (rev 13411)
+++ django/branches/soc2010/test-refactor/tests/modeltests/custom_pk/tests.py   
2010-07-02 17:19:17 UTC (rev 13412)
@@ -1,6 +1,6 @@
 # -*- coding: utf-8 -*-
 from django.test import TestCase
-
+from django.utils.unittest import skipIf
 from django.conf import settings
 from django.db import transaction, IntegrityError, DEFAULT_DB_ALIAS
 
@@ -116,10 +116,10 @@
 # SQLite lets objects be saved with an empty primary key, even though an
 # integer is expected. So we can't check for an error being raised in that 
case
 # for SQLite. Remove it from the suite for this next bit.
+@skipIf(settings.DATABASES[DEFAULT_DB_ALIAS]['ENGINE'] == 
'django.db.backends.sqlite3',
+"SQLite lets objects be saved with empty pk")
 def test_empty_pk_error(self):
-#fixme, improve this skiping with unittest2
-if settings.DATABASES[DEFAULT_DB_ALIAS]['ENGINE'] != 
'django.db.backends.sqlite3':
-self.assertRaises(IntegrityError,
-  Employee.objects.create,
-  first_name='Tom', last_name='Smith')
+self.assertRaises(IntegrityError,
+  Employee.objects.create,
+  first_name='Tom', last_name='Smith')
 

-- 
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] #13867: Feature request: Comments in Django models saved to database schema

2010-07-02 Thread Django

#13867: Feature request: Comments in Django models saved to database schema
---+
  Reporter:  rjalves   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by rjalves):

  * summary:  Feature request: docstring and comments in Django models
  saved to database schema => Feature request:
  Comments in Django models saved to database
  schema

-- 
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] #13867: Feature request: docstring and comments in Django models saved to database schema

2010-07-02 Thread Django

#13867: Feature request: docstring and comments in Django models saved to 
database
schema
---+
  Reporter:  rjalves   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by rjalves):

 For PostgreSQL yes, for MySQL something like:

 {{{
  CREATE TABLE `bacteria`.`dummy` (
 `dummy_name` VARCHAR ( 20 ) NOT NULL COMMENT 'All dummies should have
 names right?'
 ) ENGINE = InnoDB COMMENT = 'This comment goes into the schema.'
 }}}

 I agree with the point about the docstring magic, however for the column
 comment I think they should be kept separate.[[BR]]
 One may want to include a content specific comment in the database and a
 different message in help_text as user guideline.

-- 
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] r13411 - django/branches/soc2010/test-refactor/django/test

2010-07-02 Thread noreply

Author: PaulM
Date: 2010-07-02 11:34:41 -0500 (Fri, 02 Jul 2010)
New Revision: 13411

Modified:
   django/branches/soc2010/test-refactor/django/test/testcases.py
Log:
[soc2010/test-refactor] Forgot to remove a comment.


Modified: django/branches/soc2010/test-refactor/django/test/testcases.py
===
--- django/branches/soc2010/test-refactor/django/test/testcases.py  
2010-07-02 16:30:52 UTC (rev 13410)
+++ django/branches/soc2010/test-refactor/django/test/testcases.py  
2010-07-02 16:34:41 UTC (rev 13411)
@@ -2,8 +2,6 @@
 from urlparse import urlsplit, urlunsplit
 from xml.dom.minidom import parseString, Node
 
-#from django.utils import unittest
-
 from django.conf import settings
 from django.core import mail
 from django.core.management import call_command

-- 
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] #13868: Inability to create superuser during syncdb when using GIS fields in AUTH_PROFILE_MODULE

2010-07-02 Thread Django

#13868: Inability to create superuser during syncdb when using GIS fields in
AUTH_PROFILE_MODULE
-+--
  Reporter:  jskitz  | Owner:  nobody
Status:  new | Milestone:
 Component:  GIS |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

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

Comment:

 test

-- 
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] #13871: contrib.admin:list_editable - ForeignKey performance is O(m*n)

2010-07-02 Thread Django

#13871: contrib.admin:list_editable - ForeignKey performance is O(m*n)
+---
 Reporter:  chadc   |   Owner:  
nobody
   Status:  new |   Milestone:  
  
Component:  django.contrib.admin| Version:  
1.2   
 Keywords:  list_editable, admin, ForeignKey, admin efficiency  |   Stage:  
Unreviewed
Has_patch:  0   |  
+---
 '''Overview'''

 Including ForeignKey fields in list_editable results in m*n database
 queries where m is the number of ForeignKey fields in list_editable and n
 is the number of rows in the changelist.

 '''Description'''

 I have been experiencing poor performance with the admin changelist when
 list_editable includes ForeignKey fields. In particular, rendering the
 changelist requires O(m*n) database queries where m is the number of
 ForeignKey fields included in list_editable and n is the number of rows in
 the changelist. The problem, as I understand it, stems from the fact that
 the choices for the ForeignKey widgets are not cached. So, when each
 ForeignKey widget is rendered, it queries the database to retrieve the
 list of possible values.

 My solution to this problem has been to override the Select widget with a
 CachedSelect widget in the admin model. However, as Jeremy Dunck noted in
 django-developers (link below), this may stem from a more general problem
 with ModelFormSet. I have ticketed this under contrib.admin for now, but I
 hope that Jeremy will update it as any larger issues become clear.

 '''Example'''

 {{{
 class Host(models.Model):
 name = models.CharField(max_length=128, unique=True)

 class Account(models.Model):
 host = models.ForeignKey(Host, related_name="accounts")
 name = models.CharField(max_length=128)

 class AccountAdmin(admin.ModelAdmin):
 list_display = ('name', 'host')
 list_editable = ('host',)
 list_per_page = 25
 admin.site.register(Account, AccountAdmin)
 }}}


 Rendering the ForeignKey widgets in this example requires n*m=25*1=25
 database queries:

 SELECT "hosts_host"."id",  "hosts_host"."name" FROM "hosts_host" ORDER BY
 "hosts_host"."name" ASC
 Total time: 330 ms
 Numer of queries: 25

 '''Related Links'''

 django-developers: http://groups.google.ca/group/django-
 developers/browse_thread/thread/76066baed6ba70dc

 django-users: http://groups.google.ca/group/django-
 users/browse_thread/thread/7b63fd40c891ec19

-- 
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] #11058: list_display_links doesn't allow callables not defined in the model

2010-07-02 Thread Django

#11058: list_display_links doesn't allow callables not defined in the model
---+
  Reporter:  dvine | Owner:
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:  list_display_links
 Stage:  Ready for checkin | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by cmbeelby):

  * version:  1.0 => SVN

-- 
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] #13841: Allow context processors access to current version of context

2010-07-02 Thread Django

#13841: Allow context processors access to current version of context
--+-
  Reporter:  mitar| Owner:  nobody
Status:  new  | Milestone:
 Component:  Template system  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by gregmuellegger):

 mitar:
 > I could make a patch if there would be an agreement that this is useful.

 It seems that you want to discuss this first before implementing. The best
 place for discussion is the django-developers mailinglist[1] - writing
 your proposal there will result in better feedback and you can get an idea
 if core developers also find this useful and would accept a patch.

 [1] http://groups.google.com/group/django-developers

-- 
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] #13864: DatabaseError while saving with force_update set

2010-07-02 Thread Django

#13864: DatabaseError while saving with force_update set
---+
  Reporter:  fva   | Owner:  nobody 
   
Status:  reopened  | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  
force_update DatabaseError
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by gregmuellegger):

  * has_patch:  0 => 1
  * version:  1.2 => SVN
  * stage:  Unreviewed => Accepted

Comment:

 The problem is that the subclass has no custom fields assigned. So the
 subclassed model will try to make an update query without and values this
 results in an empty query.

 There is a very simple fix for this, added in the second patch. This
 avoids making the empty query that ofcourse doesn't affect any rows which
 causes the error.

 Maybe someone with a better understanding of the ORM could have a look if
 this fix is sufficient and confirm that it doesn't have sideeffects to NOT
 execute the update query if there is nothing to change.

-- 
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] #13870: psycopg2 backend never terminates isolating transactions

2010-07-02 Thread Django

#13870: psycopg2 backend never terminates isolating transactions
--+-
 Reporter:  patrys|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 First some background info:

  1. PostgreSQL provides several transaction isolation levels.
  2. Django's psycopg backend defaults to ghost-read-preventing isolation.
  3. psycopg isolation modes automatically create the isolating transaction
 whenever you execute your first SQL statement.
  4. psycopg expects you to tell it when you're done with your work by
 either running `connection.commit()` or `connection.rollback()`
  5. When you terminate the transaction, psycopg will wait for the next SQL
 statement and start a new isolating transaction.

 The problem is: Django breaks assumption 4 and never commits or rollbacks
 the isolating transaction. Note I'm not talking about the transactions
 explicitly started by django, I'm talking about the transaction implicitly
 started by requesting a non-zero isolation level. This has the nasty side-
 effect of leaving the connection permanently in-transaction.

 Try it yourselves: start a django server, make it use the DB and then try
 to - say - `VACUUM FULL` the table it selected from. Or try to `ALTER` the
 table (run a south migration). You will end up with a hanging connection,
 waiting for Django to leave the transaction block.

 The attached patch makes it work for psycopg2 by introducing a new method
 in the backend class. It needs a call to `leave_transaction_management()`
 so it works best with the `TransactionMiddleware`.

 Now for a real solution:

 I think it would be better to introduce some sort of
 `enter_isolation_block()` / `leave_isolation_block()` API. "Enter" would
 call `set_isolation_level(1)` (currently done unconditionally), "leave"
 would terminate the isolation transaction. Then introduce a default
 middleware that wraps all the views in these calls. It just doesn't seem
 intuitive to mix the transactions implicitly created by isolation API with
 the explicit transaction management API.

-- 
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] #6447: memcached does not support arbitrary string keys

2010-07-02 Thread Django

#6447: memcached does not support arbitrary string keys
---+
  Reporter:  nicois   | Owner:  carljm 
  
Status:  assigned  | Milestone: 
  
 Component:  Cache system  |   Version:  SVN
  
Resolution:|  Keywords:  
memcached
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by carljm):

  * stage:  Design decision needed => Accepted

Comment:

 Marking as accepted per the above IRC conversation with core committers.

-- 
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] #6447: memcached does not support arbitrary string keys

2010-07-02 Thread Django

#6447: memcached does not support arbitrary string keys
---+
  Reporter:  nicois   | Owner:  carljm 
  
Status:  assigned  | Milestone: 
  
 Component:  Cache system  |   Version:  SVN
  
Resolution:|  Keywords:  
memcached
 Stage:  Design decision needed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by carljm):

  * status:  new => assigned

Comment:

 Oh, and #13066 was a duplicate of this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #6447: memcached does not support arbitrary string keys

2010-07-02 Thread Django

#6447: memcached does not support arbitrary string keys
---+
  Reporter:  nicois   | Owner:  carljm 
  
Status:  new   | Milestone: 
  
 Component:  Cache system  |   Version:  SVN
  
Resolution:|  Keywords:  
memcached
 Stage:  Design decision needed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by carljm):

  * owner:  nobody => carljm
  * status:  reopened => new

Comment:

 Following discussion with jacobkm and jezdez in IRC, the plan is to leave
 the memcached backend unmodified (as any key mangling there could slow
 down a critical code path), but modify the other builtin backends (locmem,
 dummy, file, db) so they throw an error (or perhaps just a warning?) if
 you pass them a key that would be invalid on memcached. This
 discourages/prevents writing cache code that would not be portable to
 memcached.

 I'm working on a 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-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] #13066: cache.get and cache.set should have consistent key rules across different backends

2010-07-02 Thread Django

#13066: cache.get and cache.set should have consistent key rules across 
different
backends
-+--
  Reporter:  rbanffy | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Cache system|   Version:  SVN   
Resolution:  duplicate   |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by carljm):

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

Comment:

 Marking duplicate of #6447.

-- 
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] #13869: Documentation should mention that QuerySet.iterator() method doesn't affect db driver

2010-07-02 Thread Django

#13869: Documentation should mention that QuerySet.iterator() method doesn't 
affect
db driver
+---
 Reporter:  jtiai   |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Documentation   | Version:  1.2   
 Keywords:  orm large dataset psycopg2  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Some Python database drivers, like psycopg2 does caching if using client
 side cursors (instantiated with connection.cursor() call).

 Driver itself will still cache all data from queryset causing in huge
 datasets massive usage of memory even Django documentation suggests that
 using QuerySet.iterator() doesn't cache anything. It should be noted that
 database drivers still might do that.

 Side-effects: This also will lead to double caching in normal situations.
 First psycopg2 caches raw queryset itself and after that Django caches
 queryset.

-- 
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] #13165: Display edit link beside add button for ForeignKey fields in admin

2010-07-02 Thread Django

#13165: Display edit link beside add button for ForeignKey fields in admin
--+-
  Reporter:  DrMeers  | Owner:  DrMeers 
   
Status:  new  | Milestone:  1.3 
   
 Component:  User Experience  |   Version:  SVN 
   
Resolution:   |  Keywords:  admin foreign key edit 
link
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by gklka):

 OK, that works fine. Thanks for your efforts!

-- 
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] #13165: Display edit link beside add button for ForeignKey fields in admin

2010-07-02 Thread Django

#13165: Display edit link beside add button for ForeignKey fields in admin
--+-
  Reporter:  DrMeers  | Owner:  DrMeers 
   
Status:  new  | Milestone:  1.3 
   
 Component:  User Experience  |   Version:  SVN 
   
Resolution:   |  Keywords:  admin foreign key edit 
link
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by DrMeers):

 Replying to [comment:17 gklka]:
 > That's it:

 Try replacing

 {{{
   text = _('edit %s' % obj)
 }}}

 with

 {{{
   text = _(u'edit %s' % force_unicode(obj))
 }}}

 and let me know how if this solves it; I'll then update 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-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] #13165: Display edit link beside add button for ForeignKey fields in admin

2010-07-02 Thread Django

#13165: Display edit link beside add button for ForeignKey fields in admin
--+-
  Reporter:  DrMeers  | Owner:  DrMeers 
   
Status:  new  | Milestone:  1.3 
   
 Component:  User Experience  |   Version:  SVN 
   
Resolution:   |  Keywords:  admin foreign key edit 
link
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by gklka):

 That's it:


 {{{
 >>> get_changelink_html(obj, site, show_name = True)
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Library/Python/2.6/site-packages/django/contrib/admin/util.py",
 line 370, in get_changelink_html
 text = _('edit %s' % obj)
   File "/Library/Python/2.6/site-
 packages/django/utils/translation/__init__.py", line 55, in ugettext
 return real_ugettext(message)
   File "/Library/Python/2.6/site-packages/django/utils/functional.py",
 line 55, in _curried
 return _curried_func(*(args+moreargs), **dict(kwargs, **morekwargs))
   File "/Library/Python/2.6/site-
 packages/django/utils/translation/__init__.py", line 36, in delayed_loader
 return getattr(trans, real_name)(*args, **kwargs)
   File "/Library/Python/2.6/site-
 packages/django/utils/translation/trans_real.py", line 276, in ugettext
 return do_translate(message, 'ugettext')
   File "/Library/Python/2.6/site-
 packages/django/utils/translation/trans_real.py", line 262, in
 do_translate
 result = getattr(t, translation_function)(eol_message)
   File
 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/gettext.py",
 line 404, in ugettext
 return unicode(message)
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 26:
 ordinal not in range(128)

 }}}

-- 
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] #13165: Display edit link beside add button for ForeignKey fields in admin

2010-07-02 Thread Django

#13165: Display edit link beside add button for ForeignKey fields in admin
--+-
  Reporter:  DrMeers  | Owner:  DrMeers 
   
Status:  new  | Milestone:  1.3 
   
 Component:  User Experience  |   Version:  SVN 
   
Resolution:   |  Keywords:  admin foreign key edit 
link
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by DrMeers):

 Replying to [comment:15 gklka]:
 > It didn't help. I have tried to replace text with some constant string
 like 'text', but it does not work that way either. I think the bug is
 elsewhere.

 Very strange; that seems to be the only thing that should be affected by
 the unicode representation of the object. Can you try something like this
 in a shell?

 {{{
 >>> from AppName import admin # ensure models get
 registered
 >>> from AppName.models import *  # get models
 >>> from django.contrib.admin import site # get admin site
 >>> from django.contrib.admin.util import *   # get get_changelink_
 methods
 >>> obj = ModelName.objects.get(pk=ChooseAnID)
 >>> get_changelink_url(obj, site)
 '/admin/AppName/ModelName/ChooseAnID/'
 >>> get_changelink_html(obj, site)
 u' edit'
 >>> get_changelink_html(obj, site, show_name=True)
 u' edit \xe1rv\xedzt\u0171r\u0151
 T\xdcK\xd6RF\xdaR\xd3G\xc9P'
 }}}

 Hopefully something will blow up noisily so we can find where the problem
 is...

-- 
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] #13165: Display edit link beside add button for ForeignKey fields in admin

2010-07-02 Thread Django

#13165: Display edit link beside add button for ForeignKey fields in admin
--+-
  Reporter:  DrMeers  | Owner:  DrMeers 
   
Status:  new  | Milestone:  1.3 
   
 Component:  User Experience  |   Version:  SVN 
   
Resolution:   |  Keywords:  admin foreign key edit 
link
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by gklka):

 It didn't help. I have tried to replace text with some constant string
 like 'text', but it does not work that way either. I think the bug is
 elsewhere.

-- 
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] #13165: Display edit link beside add button for ForeignKey fields in admin

2010-07-02 Thread Django

#13165: Display edit link beside add button for ForeignKey fields in admin
--+-
  Reporter:  DrMeers  | Owner:  DrMeers 
   
Status:  new  | Milestone:  1.3 
   
 Component:  User Experience  |   Version:  SVN 
   
Resolution:   |  Keywords:  admin foreign key edit 
link
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by DrMeers):

 Replying to [comment:13 gklka]:
 > Please see this video: http://www.youtube.com/watch?v=BIMRoBbH8ws

 Thank you for taking the time to make this.

 Could you please try changing line 374 of
 {{{django/contrib/admin/util.py}}} from
 {{{
 '%(text)s' % {'url': url, 'text': text})
 }}}

 to

 {{{
 '%(text)s' % {'url': url, 'text': force_unicode(text)})
 }}}

 and let me know if this solves the problem?

-- 
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] #13165: Display edit link beside add button for ForeignKey fields in admin

2010-07-02 Thread Django

#13165: Display edit link beside add button for ForeignKey fields in admin
--+-
  Reporter:  DrMeers  | Owner:  DrMeers 
   
Status:  new  | Milestone:  1.3 
   
 Component:  User Experience  |   Version:  SVN 
   
Resolution:   |  Keywords:  admin foreign key edit 
link
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by gklka):

 Please see this video: http://www.youtube.com/watch?v=BIMRoBbH8ws

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

37 matches

Mail list logo