Re: [Django] #11475: test.Client.session.save() raises error for anonymous users

[Django]

#11475: test.Client.session.save() raises error for anonymous users
+---
  Reporter:  egma...@gmail.com  | Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  1.1-beta-1
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kra...@canonical.org):

 Aha! Now I understand.

  1. Until you've gotten back a cookie from the middleware (which *does*
 run from `Client.get`) you don't have the session object. Instead you get
 the stupid useless empty dict.
  2. Obviously you don't get a cookie until after you make a request.
 (Unless you call `Client.login`.)
  3. But even if you make a request, Django won't set the cookie unless the
 view tries to store something in `request.session`.
  4. At that point `self.client.session` will give you a useful object, but
 it's not the same object the view will use, so if you want to communicate
 with the view, you have to call `.save()` on it.
  5. But you can't just say `self.client.session['foo'] = 'bar';
 self.client.session.save()` because, as explained in my previous two
 comments, you get a separate session object for each time you say
 `self.client.session`. Instead you have to say `s = self.client.session;
 s['foo'] = 'bar'; s.save()`, and then everything will work.

 So now I know. It's not a bug, really; it's just that Django-under-test
 behaves in a way that makes it error-prone to write unit tests for.

 It might still be useful to factor out the code in `Client.login` that
 creates a session and saves the session cookie without making an HTTP
 request, for tests that want to set up test session data without having to
 go through whatever series of views are necessary for a real person to set
 that data.

 Maybe this is some kind of a Django FAQ.

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

[Django] #11510: Import path for aggregates is incorrect

[Django]

#11510: Import path for aggregates is incorrect
---+
 Reporter:  admackin   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 All the samples for aggregates at
 http://docs.djangoproject.com/en/dev/topics/db/aggregation/#topics-db-
 aggregation show the import path as
 {{{
 >>> from django.db.models import Avg, Max, Min, Count
 }}}

 This results in an `ImportError`. It should be changed to the correct
 path:
 {{{
 >>> from django.db.models.aggregates import Avg, Max, Min, Count
 }}}

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

Re: [Django] #11503: Cache backend should expose a flush method

[Django]

#11503: Cache backend should expose a flush method
---+
  Reporter:  andrewfong| Owner:  andrewfong
Status:  assigned  | Milestone:
 Component:  Cache system  |   Version:  SVN   
Resolution:|  Keywords:  flush 
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by andrewfong):

  * needs_docs:  0 => 1
  * has_patch:  0 => 1

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

[Django] #11509: Incorrect capitalisation of web in Widget documentation

[Django]

#11509: Incorrect capitalisation of web in Widget documentation
---+
 Reporter:  thepointer |   Owner:  nobody
   Status:  new|   Milestone:  1.0.3 
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 http://docs.djangoproject.com/en/dev/ref/forms/widgets/#customizing-
 widget-instances - last paragraph before Widget.attrs:

 "On a real web page, you probably don't want every widget to look the
 same. You might want a larger input element for the comment, and you might
 want the 'name' widget to have some special CSS class. To do this, you use
 the attrs argument when creating the widget:"

 Should be:

 "On a real '''Web''' page, you probably don't want every widget to look
 the same. You might want a larger input element for the comment, and you
 might want the 'name' widget to have some special CSS class. To do this,
 you use the attrs argument when creating the widget:"

 I'd suggest doing a case sensitive 'find all' for 'web' through the
 documentation. This change should be applied to bring the documentation in
 line with http://docs.djangoproject.com/en/dev/internals/contributing
 /#commonly-used-terms

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

Re: [Django] #11496: max_value validation is inconsistant

[Django]

#11496: max_value validation is inconsistant
-+--
  Reporter:  bobbo...@gmail.com  | Owner:  nobody   
Status:  new | Milestone:   
 Component:  Forms   |   Version:  1.0  
Resolution:  |  Keywords:  max_value
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 TYPE_CHOICES = (
 ('T','Today Only'),
 ('P','Permanent'),
 ('B','Both Today and Permanent')
 )

 class Batch(models.Model):
 submit_date = models.DateTimeField('Batch Time')
 user = models.CharField(max_length=25)
 amount = models.DecimalField(max_digits=8,decimal_places=2)
 type = models.CharField(max_length=1,choices=TYPE_CHOICES,default='T')
 class Meta:
 ordering = ['-submit_date']

 class Amount(models.Model):
 value = models.DecimalField(max_digits=8,decimal_places=2)

 class BatchForm(ModelForm):
 amount = forms.DecimalField(max_digits=8,decimal_places=2)
 class Meta:
 model = Batch
 exclude = ('submit_date','user')

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

Re: [Django] #11496: max_value validation is inconsistant

[Django]

#11496: max_value validation is inconsistant
-+--
  Reporter:  bobbo...@gmail.com  | Owner:  nobody   
Status:  new | Milestone:   
 Component:  Forms   |   Version:  1.0  
Resolution:  |  Keywords:  max_value
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 Replying to [comment:2 kmtracey]:
 > Removing milestone as an unconfirmed problem should not block a bug-fix
 release.  As for investigating this -- there's not enough information here
 to recreate as the Batch model upon which your model form is based is
 missing.  Also you say "sometimes" you encounter this problem, so I'm
 guessing even with full information it will be hard to recreate.  The code
 involved here is in django/forms/fields.py and the case where this error
 message is raised is straightforward:
 >
 > {{{
 > #!python
 > if self.max_value is not None and value > self.max_value:
 > raise ValidationError(self.error_messages['max_value'] %
 self.max_value)
 > }}}
 >
 > As a first step I would probably change that error message and the code
 here that constructs it to also print the value being tested against, as
 that might give a clue what has gone wrong in the cases where you are
 seeing the problem.
 >

 Sometimes was a definite understatement.  I am able to reproduce within 10
 submits of my form.  I have removed that validation from the code and am
 now validating through the view itself.

 From views.py

 def processBatchForm(request):
 if request.method == 'POST':
 form = BatchForm(request.POST)
 message = ""
 if form.is_valid():

 ...

 else:
 message = message + "Data Validation Error!  Please see
 errors."

 prev_batches = Batch.objects.all()[:10]
 live_val = getBatchValue();
 return render_to_response('refunds/batch_list.html', {
 'form': form,
 'batch_history': prev_batches,
 'live_val' : live_val,
 'message' : message,
 'user' : request.user
 })
 else:
 print "Request Method not permitted."


 from

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

[Django] #11508: Missing with in Form Wizard documentation

[Django]

#11508: Missing with in Form Wizard documentation
-+--
 Reporter:  thepointer   |   Owner:  nobody
   Status:  new  |   Milestone:  1.0.3 
Component:  Documentation| Version:  1.0   
 Keywords:  formtools documentation  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-
 wizard/#creating-a-formwizard-class - 2nd paragraph:

 "As your Form classes, this FormWizard class can live anywhere in your
 codebase, but convention is to put it in forms.py."

 This should be:

 "As with your Form classes, this FormWizard class can live anywhere in
 your codebase, but convention is to put it in forms.py."

 .. or something similar.

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

Re: [Django] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  lukeplant
Status:  assigned| Milestone:  1.2  
 Component:  HTTP handling   |   Version:  SVN  
Resolution:  |  Keywords:  csrf 
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Comment (by Glenn):

 Another tweak: only set the CSRF cookie if get_token was called.

 {{{
 def get_token(request):
 """
 Returns the the CSRF token required for a POST form, or None if the
 CSRF middleware
 is not installed.
 """
 request.META["CSRF_COOKIE_USED"] = True
 return request.META.get("CSRF_COOKIE", None)

 ...
 if not request.META.get("CSRF_COOKIE_USED", False):
 return response

 response.set_cookie(settings.CSRF_COOKIE_NAME,
 request.META["CSRF_COOKIE"], max_age = 60 * 60 * 24 * 7 *
 52,
 domain=settings.CSRF_COOKIE_DOMAIN)
 }}}

 This avoids setting the header on every request, which is one of those
 little incremental bits of waste in every request that Django shouldn't be
 accumulating.

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

Re: [Django] #11496: max_value validation is inconsistant

[Django]

#11496: max_value validation is inconsistant
-+--
  Reporter:  bobbo...@gmail.com  | Owner:  nobody   
Status:  new | Milestone:   
 Component:  Forms   |   Version:  1.0  
Resolution:  |  Keywords:  max_value
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

  * milestone:  1.0.3 =>

Comment:

 Removing milestone as an unconfirmed problem should not block a bug-fix
 release.  As for investigating this -- there's not enough information here
 to recreate as the Batch model upon which your model form is based is
 missing.  Also you say "sometimes" you encounter this problem, so I'm
 guessing even with full information it will be hard to recreate.  The code
 involved here is in django/forms/fields.py and the case where this error
 message is raised is straightforward:

 {{{
 #!python
 if self.max_value is not None and value > self.max_value:
 raise ValidationError(self.error_messages['max_value'] %
 self.max_value)
 }}}

 As a first step I would probably change that error message and the code
 here that constructs it to also print the value being tested against, as
 that might give a clue what has gone wrong in the cases where you are
 seeing 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #5338: User __unicode__ return value of get_full_name()

[Django]

#5338: User __unicode__ return value of get_full_name()
---+
  Reporter:  s...@cabedge.com  | Owner:  adrian
Status:  closed| Milestone:
 Component:  Contrib apps  |   Version:  SVN   
Resolution:  wontfix   |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by SmileyChris):

 Just for anyone stumbling on this ticket:
 http://www.djangosnippets.org/snippets/1642/

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

Re: [Django] #10646: memcached's incr and decr should throw ValueError if keys don't exist

[Django]

#10646: memcached's incr and decr should throw ValueError if keys don't exist
-+--
  Reporter:  dauerbaustelle  | Owner:  anonymous
   
Status:  assigned| Milestone:  1.2  
   
 Component:  Cache system|   Version:  1.1-beta-1   
   
Resolution:  |  Keywords:  memcached, cache, incr, 
decr
 Stage:  Accepted| Has_patch:  1
   
Needs_docs:  1   |   Needs_tests:  1
   
Needs_better_patch:  1   |  
-+--
Comment (by andrewfong):

 As of r11267, unit tests for the memcached backend were failing because
 the test expected a value error to be raised and the incr / decr did not
 do so. It was bugging me, so I made a quick fix (see attached patch). Hope
 it helps.

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

[Django] #11507: Bengali (bn) translation

[Django]

#11507: Bengali (bn) translation
--+-
 Reporter:  nsmgr8|   Owner:  nobody
   Status:  new   |   Milestone:  1.1   
Component:  Translations  | Version:  1.0   
 Keywords:  Bengali, bn   |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The current Bengali translation is impractical. Since the translation is
 done almost literally. It makes no sense in the usage. Moreover, it is
 outdated. Therefore I have started the localization from the scratch. I
 have added the the files here. I can do a diff file. Since it is almost
 rewritten, there is no point on diff.

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

[Changeset] r11273 - in django/branches/soc2009/multidb: . django/db/models django/db/models/fields tests/regressiontests/multiple_database

[noreply]

Author: Alex
Date: 2009-07-19 16:57:08 -0500 (Sun, 19 Jul 2009)
New Revision: 11273

Modified:
   django/branches/soc2009/multidb/TODO.txt
   django/branches/soc2009/multidb/django/db/models/fields/__init__.py
   django/branches/soc2009/multidb/django/db/models/fields/related.py
   django/branches/soc2009/multidb/django/db/models/query.py
   
django/branches/soc2009/multidb/tests/regressiontests/multiple_database/tests.py
Log:
[soc2009/multidb] Raise an exception at an attempt to do a subquery with 2 
different databases.  Eventually we'll just evaluate the 2 queries seperates.

Modified: django/branches/soc2009/multidb/TODO.txt
===
--- django/branches/soc2009/multidb/TODO.txt2009-07-19 21:31:13 UTC (rev 
11272)
+++ django/branches/soc2009/multidb/TODO.txt2009-07-19 21:57:08 UTC (rev 
11273)
@@ -14,12 +14,12 @@
 
 flush, reset, and syncdb need to not prompt the user multiple times.
 
-3)  Handle nesting of Querysets using __in across multiple dbs.
+3)  Handle backends with custom Query classes.
 
-4)  Handle backends with custom Query classes.
+4)  Wait on the merge of the m2m stuff.
 
-5)  Wait on the merge of the m2m stuff.
+5)  Fix django.contrib.gis, it's broken in all sorts of ways.
 
-6)  Fix django.contrib.gis, it's broken in all sorts of ways.
+6)  Generate SQL, instead of an error for nesting on different DBs.
 
 7) Time permitting add support for a ``DatabaseManager``.

Modified: django/branches/soc2009/multidb/django/db/models/fields/__init__.py
===
--- django/branches/soc2009/multidb/django/db/models/fields/__init__.py 
2009-07-19 21:31:13 UTC (rev 11272)
+++ django/branches/soc2009/multidb/django/db/models/fields/__init__.py 
2009-07-19 21:57:08 UTC (rev 11273)
@@ -201,9 +201,9 @@
 if hasattr(value, 'relabel_aliases'):
 return value
 if hasattr(value, 'as_sql'):
-sql, params = value.as_sql()
+sql, params = value.as_sql(connection)
 else:
-sql, params = value._as_sql()
+sql, params = value._as_sql(connection)
 return QueryWrapper(('(%s)' % sql), params)
 
 

Modified: django/branches/soc2009/multidb/django/db/models/fields/related.py
===
--- django/branches/soc2009/multidb/django/db/models/fields/related.py  
2009-07-19 21:31:13 UTC (rev 11272)
+++ django/branches/soc2009/multidb/django/db/models/fields/related.py  
2009-07-19 21:57:08 UTC (rev 11273)
@@ -149,9 +149,9 @@
 if hasattr(value, 'relabel_aliases'):
 return value
 if hasattr(value, 'as_sql'):
-sql, params = value.as_sql()
+sql, params = value.as_sql(connection)
 else:
-sql, params = value._as_sql()
+sql, params = value._as_sql(connection)
 return QueryWrapper(('(%s)' % sql), params)
 
 # FIXME: lt and gt are explicitally allowed to make

Modified: django/branches/soc2009/multidb/django/db/models/query.py
===
--- django/branches/soc2009/multidb/django/db/models/query.py   2009-07-19 
21:31:13 UTC (rev 11272)
+++ django/branches/soc2009/multidb/django/db/models/query.py   2009-07-19 
21:57:08 UTC (rev 11273)
@@ -745,12 +745,14 @@
 self.query.add_fields(field_names, False)
 self.query.set_group_by()
 
-def _as_sql(self):
+def _as_sql(self, connection):
 """
 Returns the internal query's SQL and parameters (as a tuple).
 """
 obj = self.values("pk")
-return obj.query.as_nested_sql()
+if connection.settings_dict == obj.query.connection.settings_dict:
+return obj.query.as_nested_sql()
+raise ValueError("Can't do subqueries with queries on different DBs.")
 
 def _validate(self):
 """
@@ -863,7 +865,7 @@
 
 super(ValuesQuerySet, self)._setup_aggregate_query(aggregates)
 
-def _as_sql(self):
+def _as_sql(self, connection):
 """
 For ValueQuerySet (and subclasses like ValuesListQuerySet), they can
 only be used as nested queries if they're already set up to select only
@@ -875,8 +877,12 @@
 (not self._fields and len(self.model._meta.fields) > 1)):
 raise TypeError('Cannot use a multi-field %s as a filter value.'
 % self.__class__.__name__)
-return self._clone().query.as_nested_sql()
 
+obj = self._clone()
+if connection.settings_dict == obj.query.connection.settings_dict:
+return obj.query.as_nested_sql()
+raise ValueError("Can't do subqueries with queries on different DBs.")
+
 def _validate(self):
 """
 Validates that we aren't trying to do a query like

[Changeset] r11272 - in django/branches/soc2009/multidb: . django/conf/locale/pl/LC_MESSAGES docs/internals docs/topics/http

[noreply]

Author: Alex
Date: 2009-07-19 16:31:13 -0500 (Sun, 19 Jul 2009)
New Revision: 11272

Modified:
   django/branches/soc2009/multidb/AUTHORS
   django/branches/soc2009/multidb/TODO.txt
   django/branches/soc2009/multidb/django/conf/locale/pl/LC_MESSAGES/django.mo
   django/branches/soc2009/multidb/django/conf/locale/pl/LC_MESSAGES/django.po
   django/branches/soc2009/multidb/docs/internals/committers.txt
   django/branches/soc2009/multidb/docs/topics/http/urls.txt
Log:
[soc2009/multidb] Merged up to trunk r11267.

Modified: django/branches/soc2009/multidb/AUTHORS
===
--- django/branches/soc2009/multidb/AUTHORS 2009-07-19 20:55:58 UTC (rev 
11271)
+++ django/branches/soc2009/multidb/AUTHORS 2009-07-19 21:31:13 UTC (rev 
11272)
@@ -14,6 +14,7 @@
 * Robert Wittams
 * Gary Wilson
 * Brian Rosner
+* Justin Bronn
 * Karen Tracey
 
 More information on the main contributors to Django can be found in

Modified: django/branches/soc2009/multidb/TODO.txt
===
--- django/branches/soc2009/multidb/TODO.txt2009-07-19 20:55:58 UTC (rev 
11271)
+++ django/branches/soc2009/multidb/TODO.txt2009-07-19 21:31:13 UTC (rev 
11272)
@@ -14,16 +14,12 @@
 
 flush, reset, and syncdb need to not prompt the user multiple times.
 
-3)  Remove any references to the global ``django.db.connection`` object in the
-SQL creation process.  This includes(but is probably not limited to):
+3)  Handle nesting of Querysets using __in across multiple dbs.
 
-* The way we create ``Query`` from ``BaseQuery`` is awkward and hacky.
-* ``Field.get_db_prep_lookup``
-* ``DateField.get_db_prep_value``
-* ``DateTimeField.get_db_prep_value``
-* ``DecimalField.get_db_prep_save``
-* ``TimeField.get_db_prep_value``
+4)  Handle backends with custom Query classes.
 
-4)  Wait on the merge of the m2m stuff.
+5)  Wait on the merge of the m2m stuff.
 
-6) Time permitting add support for a ``DatabaseManager``.
+6)  Fix django.contrib.gis, it's broken in all sorts of ways.
+
+7) Time permitting add support for a ``DatabaseManager``.

Modified: 
django/branches/soc2009/multidb/django/conf/locale/pl/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: 
django/branches/soc2009/multidb/django/conf/locale/pl/LC_MESSAGES/django.po
===
--- django/branches/soc2009/multidb/django/conf/locale/pl/LC_MESSAGES/django.po 
2009-07-19 20:55:58 UTC (rev 11271)
+++ django/branches/soc2009/multidb/django/conf/locale/pl/LC_MESSAGES/django.po 
2009-07-19 21:31:13 UTC (rev 11272)
@@ -5,7 +5,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2009-05-20 12:58+0200\n"
+"POT-Creation-Date: 2009-07-17 21:59+0200\n"
 "PO-Revision-Date: 2008-02-25 15:53+0100\n"
 "Last-Translator: Jarek Zgoda \n"
 "MIME-Version: 1.0\n"
@@ -223,7 +223,7 @@
 msgid "Successfully deleted %(count)d %(items)s."
 msgstr "Usunięto %(count)d %(items)s."
 
-#: contrib/admin/actions.py:67 contrib/admin/options.py:1025
+#: contrib/admin/actions.py:67 contrib/admin/options.py:1027
 msgid "Are you sure?"
 msgstr "Jesteś pewien?"
 
@@ -321,7 +321,7 @@
 
 #: contrib/admin/options.py:519 contrib/admin/options.py:529
 #: contrib/comments/templates/comments/preview.html:16 forms/models.py:388
-#: forms/models.py:587
+#: forms/models.py:600
 msgid "and"
 msgstr "i"
 
@@ -344,53 +344,53 @@
 msgid "No fields changed."
 msgstr "Żadne pole nie zmienione."
 
-#: contrib/admin/options.py:598 contrib/auth/admin.py:67
+#: contrib/admin/options.py:599 contrib/auth/admin.py:67
 #, python-format
 msgid "The %(name)s \"%(obj)s\" was added successfully."
 msgstr "%(name)s \"%(obj)s\" dodany pomyślnie."
 
-#: contrib/admin/options.py:602 contrib/admin/options.py:635
+#: contrib/admin/options.py:603 contrib/admin/options.py:636
 #: contrib/auth/admin.py:75
 msgid "You may edit it again below."
 msgstr "Możesz ponownie edytować wpis poniżej."
 
-#: contrib/admin/options.py:612 contrib/admin/options.py:645
+#: contrib/admin/options.py:613 contrib/admin/options.py:646
 #, python-format
 msgid "You may add another %s below."
 msgstr "Możesz dodać nowy wpis %s poniżej."
 
-#: contrib/admin/options.py:633
+#: contrib/admin/options.py:634
 #, python-format
 msgid "The %(name)s \"%(obj)s\" was changed successfully."
 msgstr "%(name)s \"%(obj)s\" zostało pomyślnie zmienione."
 
-#: contrib/admin/options.py:641
+#: contrib/admin/options.py:642
 #, python-format
 msgid ""
 "The %(name)s \"%(obj)s\" was added successfully. You may edit it again below."
 msgstr ""
 "%(name)s \"%(obj)s\" dodane pomyślnie. Możesz edytować ponownie wpis poniżej."
 
-#: contrib/admin/options.py:772
+#: contrib/admin/options.py:773
 #, python-format
 msgid "Add %s"
 msgstr "Dodaj %s"
 
-#: 

[Changeset] r11271 - in django/branches/soc2009/model-validation: django/db/models tests/modeltests/validation

[noreply]

Author: Honza_Kral
Date: 2009-07-19 15:55:58 -0500 (Sun, 19 Jul 2009)
New Revision: 11271

Modified:
   django/branches/soc2009/model-validation/django/db/models/base.py
   
django/branches/soc2009/model-validation/tests/modeltests/validation/__init__.py
   
django/branches/soc2009/model-validation/tests/modeltests/validation/models.py
   django/branches/soc2009/model-validation/tests/modeltests/validation/tests.py
   
django/branches/soc2009/model-validation/tests/modeltests/validation/validators.py
Log:
[soc2009/model-validation] Added capacity for ComplexValidator handling to 
models

Modified: django/branches/soc2009/model-validation/django/db/models/base.py
===
--- django/branches/soc2009/model-validation/django/db/models/base.py   
2009-07-19 20:55:34 UTC (rev 11270)
+++ django/branches/soc2009/model-validation/django/db/models/base.py   
2009-07-19 20:55:58 UTC (rev 11271)
@@ -10,6 +10,7 @@
 
 import django.db.models.manager # Imported to register signal handler.
 from django.core.exceptions import ObjectDoesNotExist, 
MultipleObjectsReturned, FieldError, ValidationError, NON_FIELD_ERRORS
+from django.core import validators
 from django.db.models.fields import AutoField, FieldDoesNotExist
 from django.db.models.fields.related import OneToOneRel, ManyToOneRel, 
OneToOneField
 from django.db.models.query import delete_objects, Q
@@ -760,6 +761,20 @@
 setattr(self, f.attname, f.clean(getattr(self, f.attname), 
self))
 except ValidationError, e:
 errors[f.name] = e.messages
+
+# run complex validators after the fields have been cleaned since they
+# need access to model_instance.
+for f in self._meta.fields:
+if f.name in errors:
+continue
+
+value = getattr(self, f.attname)
+for v in f.validators:
+if isinstance(v, validators.ComplexValidator):
+try:
+v(value, obj=self)
+except ValidationError, e:
+errors.setdefault(f.name, []).extend(e.messages)
 try:
 # TODO: run this only if not errors??
 self.validate()

Modified: 
django/branches/soc2009/model-validation/tests/modeltests/validation/__init__.py
===
--- 
django/branches/soc2009/model-validation/tests/modeltests/validation/__init__.py
2009-07-19 20:55:34 UTC (rev 11270)
+++ 
django/branches/soc2009/model-validation/tests/modeltests/validation/__init__.py
2009-07-19 20:55:58 UTC (rev 11271)
@@ -9,5 +9,13 @@
 clean()
 except ValidationError, e:
 self.assertEquals(sorted(failed_fields), 
sorted(e.message_dict.keys()))
+
+def assertFieldFailsValidationWithMessage(self, clean, field_name, 
message):
+self.assertRaises(ValidationError, clean)
+try:
+clean()
+except ValidationError, e:
+self.assertTrue(field_name in e.message_dict)
+self.assertEquals(message, e.message_dict[field_name])
 
 

Modified: 
django/branches/soc2009/model-validation/tests/modeltests/validation/models.py
===
--- 
django/branches/soc2009/model-validation/tests/modeltests/validation/models.py  
2009-07-19 20:55:34 UTC (rev 11270)
+++ 
django/branches/soc2009/model-validation/tests/modeltests/validation/models.py  
2009-07-19 20:55:58 UTC (rev 11271)
@@ -1,6 +1,7 @@
 from datetime import datetime
 
 from django.core.exceptions import ValidationError
+from django.core.validators import ComplexValidator
 from django.db import models
 from django.test import TestCase
 
@@ -8,13 +9,21 @@
 if value != 42:
 raise ValidationError('This is not the answer to life, universe and 
everything!')
 
+class ValidateFieldNotEqualsOtherField(ComplexValidator):
+def __init__(self, other_field):
+self.other_field = other_field
+
+def __call__(self, value, all_values={}, obj=None):
+if value == self.get_value(self.other_field, all_values, obj):
+raise ValidationError("Must not equal to %r's value" % 
self.other_field)
+
 class ModelToValidate(models.Model):
 name = models.CharField(max_length=100)
 created = models.DateTimeField(default=datetime.now)
 number = models.IntegerField()
 parent = models.ForeignKey('self', blank=True, null=True)
 email = models.EmailField(blank=True)
-f_with_custom_validator = models.IntegerField(blank=True, null=True, 
validators=[validate_answer_to_universe])
+f_with_custom_validator = models.IntegerField(blank=True, null=True, 
validators=[validate_answer_to_universe, 
ValidateFieldNotEqualsOtherField('number')])
 
 def validate(self):
 super(ModelToValidate, self).validate()

Modified: 

[Changeset] r11270 - django/branches/soc2009/model-validation/django/db/models

[noreply]

Author: Honza_Kral
Date: 2009-07-19 15:55:34 -0500 (Sun, 19 Jul 2009)
New Revision: 11270

Modified:
   django/branches/soc2009/model-validation/django/db/models/base.py
Log:
[soc2009/model-validation] Removed TODO - feeling more confident about the code

Modified: django/branches/soc2009/model-validation/django/db/models/base.py
===
--- django/branches/soc2009/model-validation/django/db/models/base.py   
2009-07-19 20:55:15 UTC (rev 11269)
+++ django/branches/soc2009/model-validation/django/db/models/base.py   
2009-07-19 20:55:34 UTC (rev 11270)
@@ -757,7 +757,6 @@
 if f.name in exclude:
 continue
 try:
-# TODO: is the [sg]etattr correct?
 setattr(self, f.attname, f.clean(getattr(self, f.attname), 
self))
 except ValidationError, e:
 errors[f.name] = e.messages


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

[Changeset] r11269 - django/branches/soc2009/model-validation/django/forms

[noreply]

Author: Honza_Kral
Date: 2009-07-19 15:55:15 -0500 (Sun, 19 Jul 2009)
New Revision: 11269

Modified:
   django/branches/soc2009/model-validation/django/forms/forms.py
Log:
[soc2009/model-valitaion] minor correction in comments

Modified: django/branches/soc2009/model-validation/django/forms/forms.py
===
--- django/branches/soc2009/model-validation/django/forms/forms.py  
2009-07-18 02:02:57 UTC (rev 11268)
+++ django/branches/soc2009/model-validation/django/forms/forms.py  
2009-07-19 20:55:15 UTC (rev 11269)
@@ -249,7 +249,7 @@
 if name in self.cleaned_data:
 del self.cleaned_data[name]
 
-# run all the validators after the fields have been cleaned since they
+# run complex validators after the fields have been cleaned since they
 # need access to all_values
 for name, field in self.fields.items():
 if not name in self.cleaned_data:


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

Re: [Django] #11506: session.flush should not delete the old session

[Django]

#11506: session.flush should not delete the old session
--+-
  Reporter:  Glenn| Owner:  nobody
Status:  new  | Milestone:
 Component:  django.contrib.sessions  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by Glenn):

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

Comment:

 As a followup: this will still fail if the delayed request modifies the
 session, since it'll refresh the cookie.

 A fix would be to update the cookie only when the session hasn't been
 updated in over some timeout (say, a minute); this is long enough to avoid
 this race condition.  This would have the nice side benefit of not sending
 a Set-Cookie header for each and every request that modifies the session.

 It's harder to implement cleanly, though, since the session rows hold an
 expiry date, not a last-saved date.  You can't reliably derive one from
 the other after the fact, since the session expiry setting might have
 changed.  I'll leave this for further discussion.

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

Re: [Django] #2203: TIME_FORMAT, DATE_FORMAT and DATETIME_FORMAT are ignored

[Django]

#2203: TIME_FORMAT, DATE_FORMAT and DATETIME_FORMAT are ignored
-+--
  Reporter:  marc...@elksoft.pl  | Owner:  nobody 
Status:  reopened| Milestone: 
 Component:  Internationalization|   Version:  SVN
Resolution:  |  Keywords:  i18n-rf
 Stage:  Design decision needed  | Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by gonz):

 * cc: gonz (added)

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

[Django] #11506: session.flush should not delete the old session

[Django]

#11506: session.flush should not delete the old session
-+--
 Reporter:  Glenn|   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.sessions  | Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 Flushing and cycling the session should empty the data in the session and
 create a new key, but should not delete the old key.

 Scenario:

 1: JS kicks off a periodic AJAX request to update something, which is
 delayed in transit.

 2: User submits an AJAX login form, which calls auth.login, calling
 session.flush or session.cycle_key.  The AJAX response sets a new session
 cookie for the user.

 3: The async request from #1 makes it to the server.  This still has the
 old cookie, since it started before #2 finished.  contrib.session doesn't
 recognize the cookie, since the previous request deleted it.  It thinks
 it's an expired or corrupt session cookie, and flushes the session again.

 #2 logs the user in, then #3 logs the user back out.  (I've seen this
 happen even without AJAX logins, when using django.views.static.serve in
 development.)

 session.flush should leave the old session in the database, and just clear
 its data.  That way, when #3 comes around, it won't be an unrecognized
 session, and it won't trigger a session flush.  Let the old session row
 expire on its own, like any idle session.

 This doesn't change the definition of the function: "Removes the current
 session data from the database and regenerates the key."

 This patch also fixes and tests session.cycle_key() raising an error if no
 session already existed; accessing self._session_cache raises
 AttributeError.  This was triggering while I was writing the main 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11487: Oracle encoding bug when saving more than 4000 characters

[Django]

#11487: Oracle encoding bug when saving more than 4000 characters
---+
  Reporter:  mdpetry   | Owner:  nobody 

Status:  new   | Milestone:  1.1

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

Resolution:|  Keywords:  oracle 
database
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  1  

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

 * cc: mboersma, ikelly (added)

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

Re: [Django] #11323: Updated Korean translation

[Django]

#11323: Updated Korean translation
---+
  Reporter:  daybreaker| Owner:  anonymous  
Status:  new   | Milestone:  1.1
 Component:  Translations  |   Version:  SVN
Resolution:|  Keywords:  i18n translation korean
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by daybreaker):

  * has_patch:  0 => 1
  * summary:  Updating Korean translation => Updated Korean translation

Comment:

 I've updated a new version.

 Another Korean reviewer suggested minor improvements in `timesince.py`.

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

Re: [Django] #11499: The default clean session will certainly not work with a huge session database

[Django]

#11499: The default clean session will certainly not work with a huge session
database
--+-
  Reporter:  batiste  | Owner:  nobody  
Status:  closed   | Milestone:  1.2 
 Component:  django-admin.py  |   Version:  SVN 
Resolution:  invalid  |  Keywords:  cleanup, session
 Stage:  Unreviewed   | Has_patch:  0   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Comment (by batiste):

 Thanks for the advice, I will give the default script a try.

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

Re: [Django] #11503: Cache backend should expose a flush method

[Django]

#11503: Cache backend should expose a flush method
---+
  Reporter:  andrewfong| Owner:  andrewfong
Status:  assigned  | Milestone:
 Component:  Cache system  |   Version:  SVN   
Resolution:|  Keywords:  flush 
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by andrewfong):

  * owner:  nobody => andrewfong
  * status:  new => assigned

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

Re: [Django] #11505: Django's TestCase should reset the cache

[Django]

#11505: Django's TestCase should reset the cache
+---
  Reporter:  andrewfong | Owner:  andrewfong 
Status:  assigned   | Milestone: 
 Component:  Testing framework  |   Version:  SVN
Resolution: |  Keywords:  cache testing flush
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Accepted

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

Re: [Django] #11505: Django's TestCase should reset the cache

[Django]

#11505: Django's TestCase should reset the cache
+---
  Reporter:  andrewfong | Owner:  andrewfong 
Status:  assigned   | Milestone: 
 Component:  Testing framework  |   Version:  SVN
Resolution: |  Keywords:  cache testing flush
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by andrewfong):

  * owner:  nobody => andrewfong
  * needs_better_patch:  => 0
  * status:  new => assigned
  * needs_tests:  => 0
  * needs_docs:  => 0

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

[Django] #11505: Django's TestCase should reset the cache

[Django]

#11505: Django's TestCase should reset the cache
-+--
 Reporter:  andrewfong   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Testing framework| Version:  SVN   
 Keywords:  cache testing flush  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 In between test cases, the cache should be flushed in order to prevent one
 test case from polluting another, similar to how the database is currently
 flushed (or transactions rolled back) in Django's test case.

 This will be easier to implement if #11503 is complete

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

[Django] #11504: Path saved in database, does not match path saved on the filesystem

[Django]

#11504: Path saved in database, does not match path saved on the filesystem
--+-
 Reporter:  rent  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  File uploads/storage  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 If you upload a file with a filename that has to be modified, fx from 'my
 image.png' to my_image.png', or to 'my_image_.png', if a file with that
 name already exists. Then the relative filename that is stored in the
 database will be the original, 'my image.png', while the file on the
 filesystem will have the new modified name.

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

Re: [Django] #11503: Cache backend should expose a flush method

[Django]

#11503: Cache backend should expose a flush method
---+
  Reporter:  andrewfong| Owner:  andrewfong
Status:  assigned  | Milestone:
 Component:  Cache system  |   Version:  SVN   
Resolution:|  Keywords:  flush 
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Unreviewed => Accepted

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

[Django] #11503: Cache backend should expose a flush method

[Django]

#11503: Cache backend should expose a flush method
+---
   Reporter:  andrewfong|Owner:  nobody
 Status:  new   |Milestone:
  Component:  Cache system  |  Version:  SVN   
   Keywords:  flush |Stage:  Unreviewed
  Has_patch:  0 |   Needs_docs:  0 
Needs_tests:  0 |   Needs_better_patch:  0 
+---
 The low level cache interface (django.core.cache.cache) should expose a
 method to flush out the entire cache. The primary use of this, off the top
 of my head, would be to make it easier to test caching by flushing out
 everything in between tests, although there are probably other use cases
 as well.

 Currently, in order to do this, you have to rely on different methods for
 each backend. For example, with the memcached backend, you call
 cache._cache.flush_all(), whereas with locmem, you set cache._cache = {}.
 Having backends implement a flush method would make this consistent across
 all supported backend options.

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

Re: [Django] #11369: verbose_name_plural not inherited if base class is abstract.

[Django]

#11369: verbose_name_plural not inherited if base class is abstract.
---+
  Reporter:  Beetle_B  | Owner: 
   
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.0
   
Resolution:|  Keywords:  
verbose_name_plural, inheritance, abstract
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 Replying to [comment:8 Beetle_B]:
 > OP here.
 >
 > Here's how I remember it (I have the code, but it may have been modified
 since then):
 > ...
 > The difference is that the intermediate abstract model
 (CategoryMarkup)'s Meta is subclassing the Meta of the parent. This was as
 per the docs...
 Correct.
 >
 > In any case, your examples are illuminating. So normally,
 verbose_name_plural ''is'' inherited from an abstract base class that
 defines it?
 Correct.
 >
 > The point of this bug report was that the docs should state explicitly
 what is or is not inherited.
 Oops, sorry. From the tracking of the ticket history I had understood this
 ticket was initially opened to report the mis-behavior and later changed
 to be about the docs, that's why I changed is component to ORM.

 > Your examples have, in a sense, confused me, and is suggesting an
 inconsistent behavior (in which case a separate ticket needs to be
 opened). On the one hand, it is inherited (if the immediate parent defines
 it). On the other, it is not (even when the intermediate abstract class's
 Meta is inheriting directly from the parent's Meta).

 Correct, and the patch solves it, the regression test case added shows
 this with an very similar example: It fails without the patch and works
 after applying it.

 Anyway, if the patch (or another solution) is committed to solve the
 problem that Django is treating the `verbose_name_plural` in a way
 different to `verbose_name` when abstract model inheritance is involved
 then there won't be any special cases to document (apart for the cases
 already covered: `abstract` is not inherited and `db_table` is but it
 won't make any sense). That is, all the meta model options are inherited
 just like in the non-abstract scenario and IMHO there won't be any need to
 explicitely list them.

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

Re: [Django] #11501: Punctuation error

[Django]

#11501: Punctuation error
+---
  Reporter:  pzero  | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  1.0
Resolution: |  Keywords:  punctuation
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

  * component:  Uncategorized => Documentation

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

Re: [Django] #9180: Low-level cache interface incorrectly tries to typecast bytestring

[Django]

#9180: Low-level cache interface incorrectly tries to typecast bytestring
---+
  Reporter:  p | Owner:  nobody
Status:  new   | Milestone:
 Component:  Cache system  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by gonz):

 * cc: gonz (added)

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

[Django] #11502: Wrong escaping in admin

[Django]

#11502: Wrong escaping in admin
-+--
 Reporter:  Tomasz Elendt   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.admin | Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 There are some places (I found two of them) in Django's admin where
 querystrings used in templates are marked as safe, which prevents them
 from auto-escaping. In effect there's unescaped ampersand, when there's
 more than one variable in querystring. It's hard for me to instruct how to
 reproduce this bug - IMHO the easiest way is to set your
 `DEFAULT_CONTENT_TYPE` to `'application/xhtml+xml'` and click through the
 change list page of the admin (date_hierarchy menu, paginator).

 There are also some formatting issues (e.g. some very long lines) in
 `admin_list.py`.

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

Re: [Django] #11499: The default clean session will certainly not work with a huge session database

[Django]

#11499: The default clean session will certainly not work with a huge session
database
--+-
  Reporter:  batiste  | Owner:  nobody  
Status:  closed   | Milestone:  1.2 
 Component:  django-admin.py  |   Version:  SVN 
Resolution:  invalid  |  Keywords:  cleanup, session
 Stage:  Unreviewed   | Has_patch:  0   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by JohnDoe):

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

Comment:

 Maybe you SHOULD have looked at the one in django-admin, because it is
 quite a bit more efficient than the one you got running there and is
 actually doing it the proper way.

 What is does is just tell the database to delete any data older than
 expire_date instead of loading it all into python and parsing it like
 you're doing.

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