Re: [Django] #13950: Add "post save" hook to ModelAdmin class

[Django]

#13950: Add "post save" hook to ModelAdmin class
---+
  Reporter:  3point2   | Owner:  pandres
Status:  reopened  | Milestone: 
 Component:  django.contrib.admin  |   Version:  1.2
Resolution:|  Keywords: 
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  1  
Needs_better_patch:  1 |  
---+
Changes (by 3point2):

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

Comment:

 I'll try explain the problem better.

 Let's start with the example I described above: the Invoice and
 InvoiceEntry models. I have registered the Invoice model with the admin
 and also registered the InvoiceEntry model as an inline (as you suggest).

 Let's say a user creates a new invoice, and adds several invoice entries
 using the inline forms. When the user clicks on "Save", there is no way to
 calculate the total of the invoice. This is why:

 * First, the invoice is saved. This calls the save_model method on the
 modeladmin, which calls the save() method on the Invoice model. At this
 point, none of the invoice entries have been saved yet, so it's not
 possible to calculate a total in save_model() or save()
 * The post_save signal is sent when save() completes. The invoice's
 invoiceentry_set manager still returns an empty list as the inlines have
 not been saved yet.
 * The inline invoice entries are now saved. At this point, it's no longer
 possible to hook into the save process to calculate the invoice's total.
 The only workaround would be to have each invoice entry update its parent
 invoice's total when it is saved, which will cause a lot of unnecessary
 save() calls on the invoice (one for each entry).

 My post_save hook allows the user to call a function *after* the inlines
 have been saved. This allows the total to be calculated using
 invoice.invoiceentry_set.all()

-- 
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] #14709: staticfiles app seems forced upon me

[Django]

#14709: staticfiles app seems forced upon me
---+
  Reporter:  jcscoobyrs| Owner:  nobody 
Status:  new   | Milestone: 
 Component:  Contrib apps  |   Version:  1.3-alpha  
Resolution:|  Keywords:  staticfiles
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by jcscoobyrs):

 I did figure out a good way to workaround this.  Since the only time I
 need Django to be involved in my static file serving is in DEBUG/developer
 mode, I was able to succumb to the new requirement and I set the
 STATICFILES_URL/STATICFILES_DIRS settings.  With those two settings in
 place, I was able to use the staticfiles_urlpatterns from
 django.contrib.staticfiles.urls.  Now, this all makes sense because of the
 following:

 * The default TEMPLATE_CONTEXT_PROCESSORS includes the
 django.contrib.staticfiles.context_processors.staticfiles processor
 * The STATICFILES_URL is only checked in DEBUG mode
 * My urls only include the staticfiles_urlpatterns url(s) in DEBUG mode

 I guess since there is a workaround this isn't that big of a deal, at
 least for me.  I still think there is a good bit of confusion around the
 staticfiles app when it comes to how this problem manifested.  The reason
 it's confusing is because I didn't enable any django.contrib.staticfiles
 app yet I'm getting errors related to this app.  The error makes you feel
 forced to use the staticfiles app and the only way to avoid it is using
 the workaround I documented earlier.  I even wonder if my workaround above
 is working by mistake.  While I know why this is happening and I have a
 working workaround (for now), I still can't tell if this should be
 happening the way it 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] #4027: Document how to make copies of model instances

[Django]

#4027: Document how to make copies of model instances
+---
  Reporter:  Marek Kubica   | Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  SVN 
Resolution: |  Keywords:  db, copy
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  1  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * summary:  ability to make a copies of model instances => Document how
  to make copies of model instances

Comment:

 In response to Forest and mitar: let's keep this a documentation ticket as
 Malcolm suggested, and move any deep/shallow copy feature additions to a
 new ticket (and probably start a mailing list discussion to make sure we
 have consensus on the feature).

 For the time being, a ticket this old really needs some kind of
 resolution, and documenting a simple and useful pattern that covers 90% of
 cases is a good idea, even if copy methods do get implemented at a later
 date.

 I would say that either docs/topics/db/models or docs/topics/db/queries is
 probably the place to put the docs for this. Despite the fact that
 topics/db/models is a more appropriate section, it actually fits better
 context-wise with topics/db/models near the sections of updating and
 deleting objects. A case for going into either one could be made, and
 ultimately there should probably be a cross-ref from one section to the
 other whichever way one it ends up in.

-- 
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] #14709: staticfiles app seems forced upon me

[Django]

#14709: staticfiles app seems forced upon me
---+
  Reporter:  jcscoobyrs| Owner:  nobody 
Status:  new   | Milestone: 
 Component:  Contrib apps  |   Version:  1.3-alpha  
Resolution:|  Keywords:  staticfiles
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by jcscoobyrs):

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

Comment:

 I've been looking through the sources and it seems that this is a result
 of AdminMediaHandler being a subclass of StaticFilesHandler.
 StaticFilesHandler.__init__ makes a call to
 django.contrib.staticfiles.utils.check_settings() in DEBUG mode and this
 is where the problem arises.

-- 
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] #14708: Document available mapping keys for form field error messages.

[Django]

#14708: Document available mapping keys for form field error messages.
+---
  Reporter:  adamv  | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * stage:  Unreviewed => Accepted
  * milestone:  => 1.3

Comment:

 Agreed with your recommendation, adam. I'll give the patch further review
 later on before I commit it, but so far it looks good.

-- 
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] #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:  SVN  
Resolution:  |  Keywords:  max_value
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by adamv):

  * has_patch:  0 => 1
  * 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] #8104: IntegerField max_value & min_value errors require a %s

[Django]

#8104: IntegerField max_value & min_value errors require a %s
--+-
  Reporter:  Chris Jones   | Owner:  nobody  
  
Status:  closed   | Milestone:  
  
 Component:  Forms|   Version:  
  
Resolution:  duplicate|  Keywords:  
IntegerField max_value min_value TypeError
 Stage:  Design decision needed   | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by gabrielhurley):

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

Comment:

 As adamv points out, the design decision seems to have been made (by
 standardizing the use of mapping keys for 1.3), so that would make this a
 docs ticket. And since adamv was kind enough to create #14708 with a
 complete patch (looks complete at least from a cursory review), I'm
 closing this as a duplicate.

-- 
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] #14709: staticfiles app seems forced upon me

[Django]

#14709: staticfiles app seems forced upon me
--+-
 Reporter:  jcscoobyrs|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Contrib apps  | Version:  1.3-alpha 
 Keywords:  staticfiles   |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I just updated my Django to the latest dev (14587) and I'm finding that
 the staticfiles app (django.contrib.staticfiles) seems to be forced upon
 me.  Prior to updating, my Django app was serving static files in
 development mode the way the documentation suggested which used MEDIA_ROOT
 and MEDIA_URL.  After I updated Django, I get the following:

 Validating models...

 0 errors found
 Django version 1.3 alpha 1 SVN-14587, using settings
 'singularity.settings'
 Development server is running at http://127.0.0.1:8000/
 Quit the server with CONTROL-C.
 Unhandled exception in thread started by >
 Traceback (most recent call last):
   File "/Library/Python/2.6/site-
 packages/django/core/management/commands/runserver.py", line 83, in
 inner_run
 handler = self.get_handler(*args, **options)
   File "/Library/Python/2.6/site-
 packages/django/core/management/commands/runserver.py", line 115, in
 get_handler
 return AdminMediaHandler(handler, options.get('admin_media_path', ''))
   File "/Library/Python/2.6/site-
 packages/django/contrib/staticfiles/handlers.py", line 23, in __init__
 utils.check_settings()
   File "/Library/Python/2.6/site-
 packages/django/contrib/staticfiles/utils.py", line 40, in check_settings
 raise ImproperlyConfigured("The MEDIA_URL and STATICFILES_URL "
 django.core.exceptions.ImproperlyConfigured: The MEDIA_URL and
 STATICFILES_URL settings must have individual values

 Now...my settings.py wasn't updated to have the staticfiles app installed
 so I'm confused.  Being a development version of Django, I go to the docs
 and I see serving static files is documented differently.  I also see that
 the TEMPLATE_CONTEXT_PROCESSORS includes the staticfiles context processor
 by default.  My first thought was to remove that by overriding the default
 for TEMPLATE_CONTEXT_PROCESSORS but I still get the error above.  I don't
 mind using the staticfiles app but it shouldn't be forced upon me like it
 appears to have been.  Existing Django apps shouldn't fail upon startup or
 there should at least be some documented way to completely turn off the
 new staticfiles app.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14492: Model proxy instance does not equal the respective model instance

[Django]

#14492: Model proxy instance does not equal the respective model instance
-+--
  Reporter:  bruth   | Owner:  bruth
Status:  assigned| Milestone:  1.3  
 Component:  Core framework  |   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by bruth):

  * 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-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] #8670: auth add_view should accept extra_context

[Django]

#8670: auth add_view should accept extra_context
---+
  Reporter:  sorl  | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by adamv):

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

Comment:

 This functionality is in place in trunk:
 
http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/admin.py#L84
 Was added in r12218.

-- 
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] #14708: Document available mapping keys for form field error messages.

[Django]

#14708: Document available mapping keys for form field error messages.
+---
  Reporter:  adamv  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by adamv):

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

Comment:

 Also: Recommend resolving #8104 as a duplicate of this issue.

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

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

Re: [Django] #8104: IntegerField max_value & min_value errors require a %s

[Django]

#8104: IntegerField max_value & min_value errors require a %s
--+-
  Reporter:  Chris Jones   | Owner:  nobody  
  
Status:  new  | Milestone:  
  
 Component:  Forms|   Version:  
  
Resolution:   |  Keywords:  
IntegerField max_value min_value TypeError
 Stage:  Design decision needed   | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Comment (by adamv):

 As of 1.3-alpha-1 (and possibly earlier), all form field error messages
 that have data available use mapping keys. I've opened a new ticket w/ a
 patch to document these keys: http://code.djangoproject.com/ticket/14708

 Recommend resolving this issue as a duplicate of that new issue.

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

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

[Django] #14708: Document available mapping keys for form field error messages.

[Django]

#14708: Document available mapping keys for form field error messages.
---+
 Reporter:  adamv  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 The error messages for some form fields have mapping keys that will be
 replaced into the provided error strings. The attached patch documents
 these keys.

-- 
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] #6739: How to add symbolic links in Windows Vista

[Django]

#6739: How to add symbolic links in Windows Vista
+---
  Reporter:  kwill  | Owner:  nobody
  
Status:  new| Milestone:
  
 Component:  Documentation  |   Version:  SVN   
  
Resolution: |  Keywords:  windows vista symbolic 
link installation development version svn
 Stage:  Accepted   | Has_patch:  0 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Comment (by adamv):

 mklink is available in Vista and later, but is not without problems. Share
 a folder containing links and then hit it with clients running XP, for
 instance. The Python docs ( http://docs.python.org/using/windows.html
 #finding-modules ) don't mention using mklinks on Windows either, so it is
 perhaps better to adhere to the tradition of installing directly into
 site-packages, using a .pth file, or adding a new folder to the
 PYTHONPATH, rather than suggest using mklinks.

-- 
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] #6730: postgresql_psycopg2 introspection includes views in generated models

[Django]

#6730: postgresql_psycopg2 introspection includes views in generated models
-+--
  Reporter:  Michael van der Westhuizen   | 
Owner:  nobody
Status:  new | 
Milestone:
 Component:  django-admin.py inspectdb   |   
Version:  SVN   
Resolution:  |  
Keywords:
 Stage:  Accepted| 
Has_patch:  1 
Needs_docs:  0   |   
Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Comment (by adamv):

 MySQL, at least version 5.1.x w/ Django 1.3.x, also returns views during
 inspectdb (which is the behavior I want). Though because views can be ill-
 defined in MySQL (refer to tables/columns that no longer exist), I filed
 this ticket: http://code.djangoproject.com/ticket/14098

-- 
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] #14320: MySQL documentation needs to note lack of support for timezone info...

[Django]

#14320: MySQL documentation needs to note lack of support for timezone info...
+---
  Reporter:  RantyDave  | Owner:  nobody
  
Status:  new| Milestone:
  
 Component:  Documentation  |   Version:  1.2   
  
Resolution: |  Keywords:  MySQL datetime 
DateTimeField
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by adamv):

  * has_patch:  0 => 1

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

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

[Changeset] r14587 - in django/branches/releases/1.2.X: django/db/models/sql tests/regressiontests/aggregation_regress

[noreply]

Author: Alex
Date: 2010-11-16 20:58:59 -0600 (Tue, 16 Nov 2010)
New Revision: 14587

Modified:
   django/branches/releases/1.2.X/django/db/models/sql/aggregates.py
   django/branches/releases/1.2.X/django/db/models/sql/query.py
   django/branches/releases/1.2.X/django/db/models/sql/subqueries.py
   
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
Log:
[1.2.X] Fixed #12687 -- fixed an issue with aggregates and counts in 
conjunction with annotations where the QuerySet was provably empty.  Backport 
of [14586].

Modified: django/branches/releases/1.2.X/django/db/models/sql/aggregates.py
===
--- django/branches/releases/1.2.X/django/db/models/sql/aggregates.py   
2010-11-17 02:57:14 UTC (rev 14586)
+++ django/branches/releases/1.2.X/django/db/models/sql/aggregates.py   
2010-11-17 02:58:59 UTC (rev 14587)
@@ -8,6 +8,7 @@
 """
 def __init__(self, internal_type):
 self.internal_type = internal_type
+
 def get_internal_type(self):
 return self.internal_type
 

Modified: django/branches/releases/1.2.X/django/db/models/sql/query.py
===
--- django/branches/releases/1.2.X/django/db/models/sql/query.py
2010-11-17 02:57:14 UTC (rev 14586)
+++ django/branches/releases/1.2.X/django/db/models/sql/query.py
2010-11-17 02:58:59 UTC (rev 14587)
@@ -337,7 +337,7 @@
 # information but retrieves only the first row. Aggregate
 # over the subquery instead.
 if self.group_by is not None:
-from subqueries import AggregateQuery
+from django.db.models.sql.subqueries import AggregateQuery
 query = AggregateQuery(self.model)
 
 obj = self.clone()
@@ -349,7 +349,13 @@
 query.aggregate_select[alias] = aggregate
 del obj.aggregate_select[alias]
 
-query.add_subquery(obj, using)
+try:
+query.add_subquery(obj, using)
+except EmptyResultSet:
+return dict(
+(alias, None)
+for alias in query.aggregate_select
+)
 else:
 query = self
 self.select = []
@@ -382,13 +388,19 @@
 # If a select clause exists, then the query has already started to
 # specify the columns that are to be returned.
 # In this case, we need to use a subquery to evaluate the count.
-from subqueries import AggregateQuery
+from django.db.models.sql.subqueries import AggregateQuery
 subquery = obj
 subquery.clear_ordering(True)
 subquery.clear_limits()
 
 obj = AggregateQuery(obj.model)
-obj.add_subquery(subquery, using=using)
+try:
+obj.add_subquery(subquery, using=using)
+except EmptyResultSet:
+# add_subquery evaluates the query, if it's an EmptyResultSet
+# then there are can be no results, and therefore there the
+# count is obviously 0
+return 0
 
 obj.add_count_column()
 number = obj.get_aggregation(using=using)[None]

Modified: django/branches/releases/1.2.X/django/db/models/sql/subqueries.py
===
--- django/branches/releases/1.2.X/django/db/models/sql/subqueries.py   
2010-11-17 02:57:14 UTC (rev 14586)
+++ django/branches/releases/1.2.X/django/db/models/sql/subqueries.py   
2010-11-17 02:58:59 UTC (rev 14587)
@@ -10,6 +10,7 @@
 from django.db.models.sql.query import Query
 from django.db.models.sql.where import AND, Constraint
 
+
 __all__ = ['DeleteQuery', 'UpdateQuery', 'InsertQuery', 'DateQuery',
 'AggregateQuery']
 

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
   2010-11-17 02:57:14 UTC (rev 14586)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
   2010-11-17 02:58:59 UTC (rev 14587)
@@ -641,6 +641,24 @@
 lambda: 
Book.objects.annotate(mean_age=Avg('authors__age')).annotate(Avg('mean_age'))
 )
 
+def test_empty_filter_count(self):
+self.assertEqual(
+
Author.objects.filter(id__in=[]).annotate(Count("friends")).count(),
+0
+)
+
+def test_empty_filter_aggregate(self):
+self.assertEqual(
+
Author.objects.filter(id__in=[]).annotate(Count("friends")).aggregate(Count("pk")),
+{"pk__count": None}
+)
+
+def test_annotate_and_join(self):
+self.assertEqual(
+

[Changeset] r14586 - in django/trunk: django/db/models/sql tests/regressiontests/aggregation_regress

[noreply]

Author: Alex
Date: 2010-11-16 20:57:14 -0600 (Tue, 16 Nov 2010)
New Revision: 14586

Modified:
   django/trunk/django/db/models/sql/aggregates.py
   django/trunk/django/db/models/sql/query.py
   django/trunk/django/db/models/sql/subqueries.py
   django/trunk/tests/regressiontests/aggregation_regress/tests.py
Log:
Fixed #12687 -- fixed an issue with aggregates and counts in conjunction with 
annotations where the QuerySet was provably empty.

Modified: django/trunk/django/db/models/sql/aggregates.py
===
--- django/trunk/django/db/models/sql/aggregates.py 2010-11-17 02:25:20 UTC 
(rev 14585)
+++ django/trunk/django/db/models/sql/aggregates.py 2010-11-17 02:57:14 UTC 
(rev 14586)
@@ -8,6 +8,7 @@
 """
 def __init__(self, internal_type):
 self.internal_type = internal_type
+
 def get_internal_type(self):
 return self.internal_type
 

Modified: django/trunk/django/db/models/sql/query.py
===
--- django/trunk/django/db/models/sql/query.py  2010-11-17 02:25:20 UTC (rev 
14585)
+++ django/trunk/django/db/models/sql/query.py  2010-11-17 02:57:14 UTC (rev 
14586)
@@ -337,7 +337,7 @@
 # information but retrieves only the first row. Aggregate
 # over the subquery instead.
 if self.group_by is not None:
-from subqueries import AggregateQuery
+from django.db.models.sql.subqueries import AggregateQuery
 query = AggregateQuery(self.model)
 
 obj = self.clone()
@@ -349,7 +349,13 @@
 query.aggregate_select[alias] = aggregate
 del obj.aggregate_select[alias]
 
-query.add_subquery(obj, using)
+try:
+query.add_subquery(obj, using)
+except EmptyResultSet:
+return dict(
+(alias, None)
+for alias in query.aggregate_select
+)
 else:
 query = self
 self.select = []
@@ -382,13 +388,19 @@
 # If a select clause exists, then the query has already started to
 # specify the columns that are to be returned.
 # In this case, we need to use a subquery to evaluate the count.
-from subqueries import AggregateQuery
+from django.db.models.sql.subqueries import AggregateQuery
 subquery = obj
 subquery.clear_ordering(True)
 subquery.clear_limits()
 
 obj = AggregateQuery(obj.model)
-obj.add_subquery(subquery, using=using)
+try:
+obj.add_subquery(subquery, using=using)
+except EmptyResultSet:
+# add_subquery evaluates the query, if it's an EmptyResultSet
+# then there are can be no results, and therefore there the
+# count is obviously 0
+return 0
 
 obj.add_count_column()
 number = obj.get_aggregation(using=using)[None]

Modified: django/trunk/django/db/models/sql/subqueries.py
===
--- django/trunk/django/db/models/sql/subqueries.py 2010-11-17 02:25:20 UTC 
(rev 14585)
+++ django/trunk/django/db/models/sql/subqueries.py 2010-11-17 02:57:14 UTC 
(rev 14586)
@@ -11,6 +11,7 @@
 from django.db.models.sql.query import Query
 from django.db.models.sql.where import AND, Constraint
 
+
 __all__ = ['DeleteQuery', 'UpdateQuery', 'InsertQuery', 'DateQuery',
 'AggregateQuery']
 

Modified: django/trunk/tests/regressiontests/aggregation_regress/tests.py
===
--- django/trunk/tests/regressiontests/aggregation_regress/tests.py 
2010-11-17 02:25:20 UTC (rev 14585)
+++ django/trunk/tests/regressiontests/aggregation_regress/tests.py 
2010-11-17 02:57:14 UTC (rev 14586)
@@ -622,6 +622,24 @@
 lambda: 
Book.objects.annotate(mean_age=Avg('authors__age')).annotate(Avg('mean_age'))
 )
 
+def test_empty_filter_count(self):
+self.assertEqual(
+
Author.objects.filter(id__in=[]).annotate(Count("friends")).count(),
+0
+)
+
+def test_empty_filter_aggregate(self):
+self.assertEqual(
+
Author.objects.filter(id__in=[]).annotate(Count("friends")).aggregate(Count("pk")),
+{"pk__count": None}
+)
+
+def test_annotate_and_join(self):
+self.assertEqual(
+
Author.objects.annotate(c=Count("friends__name")).exclude(friends__name="Joe").count(),
+Author.objects.count()
+)
+
 @skipUnlessDBFeature('supports_stddev')
 def test_stddev(self):
 self.assertEqual(

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to 

Re: [Django] #14662: auth and contenttypes post-syncdb handlers ignore 'db' option

[Django]

#14662: auth and contenttypes post-syncdb handlers ignore 'db' option
---+
  Reporter:  marcop| Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:  management muti_db
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by adamv):

 Somewhat related to this issue, I think:
 http://code.djangoproject.com/ticket/12767

-- 
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] r14584 - django/branches/releases/1.2.X/docs/intro

[noreply]

Author: SmileyChris
Date: 2010-11-16 20:24:58 -0600 (Tue, 16 Nov 2010)
New Revision: 14584

Modified:
   django/branches/releases/1.2.X/docs/intro/tutorial01.txt
Log:
[1.2.X] Remove an obsolete admonition in tutorial one (referencing 0.96 
functionality)

Modified: django/branches/releases/1.2.X/docs/intro/tutorial01.txt
===
--- django/branches/releases/1.2.X/docs/intro/tutorial01.txt2010-11-17 
01:57:23 UTC (rev 14583)
+++ django/branches/releases/1.2.X/docs/intro/tutorial01.txt2010-11-17 
02:24:58 UTC (rev 14584)
@@ -566,22 +566,6 @@
 def __unicode__(self):
 return self.choice
 
-.. admonition:: If :meth:`~django.db.models.Model.__unicode__` doesn't seem to 
work
-
-   If you add the :meth:`~django.db.models.Model.__unicode__` method to your
-   models and don't see any change in how they're represented, you're most
-   likely using an old version of Django. (This version of the tutorial is
-   written for the latest development version of Django.) If you're using a
-   Subversion checkout of Django's development version (see :doc:`the
-   installation docs ` for more information), you shouldn't 
have
-   any problems.
-
-   If you want to stick with an older version of Django, you'll want to switch
-   to `the Django 0.96 tutorial`_, because this tutorial covers several 
features
-   that only exist in the Django development version.
-
-.. _the Django 0.96 tutorial: 
http://www.djangoproject.com/documentation/0.96/tutorial01/
-
 It's important to add :meth:`~django.db.models.Model.__unicode__` methods to
 your models, not only for your own sanity when dealing with the interactive
 prompt, but also because objects' representations are used throughout Django's

-- 
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] r14585 - django/trunk/docs/intro

[noreply]

Author: SmileyChris
Date: 2010-11-16 20:25:20 -0600 (Tue, 16 Nov 2010)
New Revision: 14585

Modified:
   django/trunk/docs/intro/tutorial01.txt
Log:
Remove an obsolete admonition in tutorial one (referencing 0.96 functionality)

Modified: django/trunk/docs/intro/tutorial01.txt
===
--- django/trunk/docs/intro/tutorial01.txt  2010-11-17 02:24:58 UTC (rev 
14584)
+++ django/trunk/docs/intro/tutorial01.txt  2010-11-17 02:25:20 UTC (rev 
14585)
@@ -566,22 +566,6 @@
 def __unicode__(self):
 return self.choice
 
-.. admonition:: If :meth:`~django.db.models.Model.__unicode__` doesn't seem to 
work
-
-   If you add the :meth:`~django.db.models.Model.__unicode__` method to your
-   models and don't see any change in how they're represented, you're most
-   likely using an old version of Django. (This version of the tutorial is
-   written for the latest development version of Django.) If you're using a
-   Subversion checkout of Django's development version (see :doc:`the
-   installation docs ` for more information), you shouldn't 
have
-   any problems.
-
-   If you want to stick with an older version of Django, you'll want to switch
-   to `the Django 0.96 tutorial`_, because this tutorial covers several 
features
-   that only exist in the Django development version.
-
-.. _the Django 0.96 tutorial: 
http://www.djangoproject.com/documentation/0.96/tutorial01/
-
 It's important to add :meth:`~django.db.models.Model.__unicode__` methods to
 your models, not only for your own sanity when dealing with the interactive
 prompt, but also because objects' representations are used throughout Django's

-- 
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] r14583 - django/trunk/docs/releases

[noreply]

Author: Alex
Date: 2010-11-16 19:57:23 -0600 (Tue, 16 Nov 2010)
New Revision: 14583

Modified:
   django/trunk/docs/releases/1.3.txt
Log:
Fixed #14706 -- corrected a stray backtick in the docs.  Thanks to Adam for the 
patch.

Modified: django/trunk/docs/releases/1.3.txt
===
--- django/trunk/docs/releases/1.3.txt  2010-11-16 23:48:08 UTC (rev 14582)
+++ django/trunk/docs/releases/1.3.txt  2010-11-17 01:57:23 UTC (rev 14583)
@@ -284,7 +284,7 @@
 
 For more details, see the documentation :doc:`Django's release process
 ` and our :doc:`deprecation timeline
-`.`
+`.
 
 ``mod_python`` support
 ~~

-- 
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] #14706: Stray tick in 1.3 release notes

[Django]

#14706: Stray tick in 1.3 release notes
+---
  Reporter:  adamv  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

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

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

[Django] #14707: Allow an annotation to match a field name when using .values on a query set.

[Django]

#14707: Allow an annotation to match a field name when using .values on a query
set.
---+
 Reporter:  andymckay  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.3-alpha 
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Ticket http://code.djangoproject.com/ticket/11256 has the unfortunate
 effect of stopping a values query from working.

 {{{
 class Author(models.Model):
   last_updated = models.DateField()

 class Book(models.Model):
   author = models.ForeignKey(Author, related_name='books')
   pubdate = models.DateField()
 }}}


 {{{
 authors =
 Author.objects.values("id").annotate(last_updated=Max('books__pubdate'))
 }}}

 In this case we are using values to only use that one field and
 last_updated is no longer overriding anything.

-- 
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] #14706: Stray tick in 1.3 release notes

[Django]

#14706: Stray tick in 1.3 release notes
---+
 Reporter:  adamv  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Stray tick in 1.3 release notes

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14705: Model Field Order not influenced by MRO of superclasses

[Django]

#14705: Model Field Order not influenced by MRO of superclasses
+---
  Reporter:  vanschelven| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by lrekucki):

 One thing that I don't understand is why does field order matter to you ?
 Maybe your problem can be solved easier on a different level.

-- 
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] r14582 - in django/trunk/django/conf: . project_template

[noreply]

Author: adrian
Date: 2010-11-16 17:48:08 -0600 (Tue, 16 Nov 2010)
New Revision: 14582

Modified:
   django/trunk/django/conf/global_settings.py
   django/trunk/django/conf/project_template/settings.py
Log:
Small grammar fix in 'user-uploaded files' comment from [14560]

Modified: django/trunk/django/conf/global_settings.py
===
--- django/trunk/django/conf/global_settings.py 2010-11-16 22:17:51 UTC (rev 
14581)
+++ django/trunk/django/conf/global_settings.py 2010-11-16 23:48:08 UTC (rev 
14582)
@@ -255,7 +255,7 @@
 # Default file storage mechanism that holds media.
 DEFAULT_FILE_STORAGE = 'django.core.files.storage.FileSystemStorage'
 
-# Absolute filesystem path to the directory that will hold user uploaded files.
+# Absolute filesystem path to the directory that will hold user-uploaded files.
 # Example: "/home/media/media.lawrence.com/"
 MEDIA_ROOT = ''
 

Modified: django/trunk/django/conf/project_template/settings.py
===
--- django/trunk/django/conf/project_template/settings.py   2010-11-16 
22:17:51 UTC (rev 14581)
+++ django/trunk/django/conf/project_template/settings.py   2010-11-16 
23:48:08 UTC (rev 14582)
@@ -43,7 +43,7 @@
 # calendars according to the current locale
 USE_L10N = True
 
-# Absolute filesystem path to the directory that will hold user uploaded files.
+# Absolute filesystem path to the directory that will hold user-uploaded files.
 # Example: "/home/media/media.lawrence.com/media/"
 MEDIA_ROOT = ''
 

-- 
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] #14705: Model Field Order not influenced by MRO of superclasses

[Django]

#14705: Model Field Order not influenced by MRO of superclasses
+---
  Reporter:  vanschelven| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by lrekucki):

 * cc: lreku...@gmail.com (added)

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

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

Re: [Django] #14705: Model Field Order not influenced by MRO of superclasses

[Django]

#14705: Model Field Order not influenced by MRO of superclasses
+---
  Reporter:  vanschelven| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by vanschelven):

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

Comment:

 The attached file "failed_attempt" shows an initial stab at the problem.
 Running the tests quickly shows that this indeed does not solve it (other
 tests regress); but this is where my understanding of the ORM ends for
 now.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14705: Model Field Order not influenced by MRO of superclasses

[Django]

#14705: Model Field Order not influenced by MRO of superclasses
---+
 Reporter:  vanschelven|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Looking at the two definitions below,

 {{{
 class OneTwo(AbstractModelOne, AbstractModelTwo):
 pass

 class TwoOne(AbstractModelTwo, AbstractModelOne):
 pass
 }}}

 one (I?) would expect the order of the fields in the second definition to
 be the opposite of the order in the first one. (Since the base classes are
 referenced in the opposite order). This is, however, not the case.

 Django only uses creation_counter to determine the order of the fields.
 Therefor the actual field order is determined by the order in which the
 containing abstract classes are evaluated (i.e. their python code is
 read). If these classes come from multiple sources (apps) the field order
 may end up to be pretty much random (though deterministic).

 The general use case is heavy use of abstract models to mix in information
 from various sources into actual models. In real apps the two above models
 are not very likely, but being able to have control over the field order
 (other than placing the abstract models in a certain order) is important.
 I make heavy use abstract models to be able to make my apps reusable. The
 above situation is an important roadblock to efficient use.

 A patch with a failing test is attached.
 Haven't yet been able to fix this in a non-intrusive way.
 I would be very much obliged if someone can come up with a solution.

-- 
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] r14581 - in django/branches/releases/1.2.X: django/db/models/fields tests/regressiontests/multiple_database

[noreply]

Author: ramiro
Date: 2010-11-16 16:17:51 -0600 (Tue, 16 Nov 2010)
New Revision: 14581

Modified:
   django/branches/releases/1.2.X/django/db/models/fields/related.py
   
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py
Log:
[1.2.X] Fixed #14691 -- Made ForeignKey.validate() use the right database. 
Thanks Marco Paolini for the report.

Backport of [14580] from trunk

Modified: django/branches/releases/1.2.X/django/db/models/fields/related.py
===
--- django/branches/releases/1.2.X/django/db/models/fields/related.py   
2010-11-16 22:09:13 UTC (rev 14580)
+++ django/branches/releases/1.2.X/django/db/models/fields/related.py   
2010-11-16 22:17:51 UTC (rev 14581)
@@ -829,7 +829,10 @@
 if value is None:
 return
 
-qs = self.rel.to._default_manager.filter(**{self.rel.field_name:value})
+using = router.db_for_read(model_instance.__class__, 
instance=model_instance)
+qs = self.rel.to._default_manager.using(using).filter(
+**{self.rel.field_name: value}
+ )
 qs = qs.complex_filter(self.rel.limit_choices_to)
 if not qs.exists():
 raise exceptions.ValidationError(self.error_messages['invalid'] % {

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py 
2010-11-16 22:09:13 UTC (rev 14580)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py 
2010-11-16 22:17:51 UTC (rev 14581)
@@ -580,6 +580,12 @@
 self.assertEquals(Person.objects.using('other').count(), 0)
 self.assertEquals(Pet.objects.using('other').count(), 0)
 
+def test_foreign_key_validation(self):
+"ForeignKey.validate() uses the correct database"
+mickey = Person.objects.using('other').create(name="Mickey")
+pluto = Pet.objects.using('other').create(name="Pluto", owner=mickey)
+self.assertEquals(None, pluto.full_clean())
+
 def test_o2o_separation(self):
 "OneToOne fields are constrained to a single database"
 # Create a user and profile on the default database

-- 
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] r14580 - in django/trunk: django/db/models/fields tests/regressiontests/multiple_database

[noreply]

Author: ramiro
Date: 2010-11-16 16:09:13 -0600 (Tue, 16 Nov 2010)
New Revision: 14580

Modified:
   django/trunk/django/db/models/fields/related.py
   django/trunk/tests/regressiontests/multiple_database/tests.py
Log:
Fixed #14691 -- Made ForeignKey.validate() use the right database. Thanks Marco 
Paolini for the report.

Modified: django/trunk/django/db/models/fields/related.py
===
--- django/trunk/django/db/models/fields/related.py 2010-11-16 21:34:53 UTC 
(rev 14579)
+++ django/trunk/django/db/models/fields/related.py 2010-11-16 22:09:13 UTC 
(rev 14580)
@@ -835,7 +835,10 @@
 if value is None:
 return
 
-qs = self.rel.to._default_manager.filter(**{self.rel.field_name:value})
+using = router.db_for_read(model_instance.__class__, 
instance=model_instance)
+qs = self.rel.to._default_manager.using(using).filter(
+**{self.rel.field_name: value}
+ )
 qs = qs.complex_filter(self.rel.limit_choices_to)
 if not qs.exists():
 raise exceptions.ValidationError(self.error_messages['invalid'] % {

Modified: django/trunk/tests/regressiontests/multiple_database/tests.py
===
--- django/trunk/tests/regressiontests/multiple_database/tests.py   
2010-11-16 21:34:53 UTC (rev 14579)
+++ django/trunk/tests/regressiontests/multiple_database/tests.py   
2010-11-16 22:09:13 UTC (rev 14580)
@@ -581,6 +581,12 @@
 self.assertEquals(Person.objects.using('other').count(), 0)
 self.assertEquals(Pet.objects.using('other').count(), 0)
 
+def test_foreign_key_validation(self):
+"ForeignKey.validate() uses the correct database"
+mickey = Person.objects.using('other').create(name="Mickey")
+pluto = Pet.objects.using('other').create(name="Pluto", owner=mickey)
+self.assertEquals(None, pluto.full_clean())
+
 def test_o2o_separation(self):
 "OneToOne fields are constrained to a single database"
 # Create a user and profile on the default database

-- 
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] #14704: USE_THOUSAND_SEPARATOR poorly documented

[Django]

#14704: USE_THOUSAND_SEPARATOR poorly documented
+---
  Reporter:  vanschelven| Owner:  nobody
Status:  closed | Milestone:  1.3   
 Component:  Documentation  |   Version:  1.2   
Resolution:  fixed  |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14704: USE_THOUSAND_SEPARATOR poorly documented

[Django]

#14704: USE_THOUSAND_SEPARATOR poorly documented
+---
  Reporter:  vanschelven| Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by SmileyChris):

 Fixed in r14578 (and backport r14579)

-- 
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] r14579 - django/branches/releases/1.2.X/docs/ref

[noreply]

Author: SmileyChris
Date: 2010-11-16 15:34:53 -0600 (Tue, 16 Nov 2010)
New Revision: 14579

Modified:
   django/branches/releases/1.2.X/docs/ref/settings.txt
Log:
[1.2.X] Better cross-referencing of the USE_THOUSAND_SEPARATOR setting in 
documentation. Thanks to Klaas van Schelven for the patch.

Modified: django/branches/releases/1.2.X/docs/ref/settings.txt
===
--- django/branches/releases/1.2.X/docs/ref/settings.txt2010-11-16 
21:33:48 UTC (rev 14578)
+++ django/branches/releases/1.2.X/docs/ref/settings.txt2010-11-16 
21:34:53 UTC (rev 14579)
@@ -1179,7 +1179,7 @@
 setting :setting:`THOUSAND_SEPARATOR` will be used as the separator between 
those
 groups.
 
-See also :setting:`THOUSAND_SEPARATOR`.
+See also :setting:`THOUSAND_SEPARATOR` and :setting:`USE_THOUSAND_SEPARATOR`.
 
 .. setting:: PASSWORD_RESET_TIMEOUT_DAYS
 
@@ -1555,9 +1555,10 @@
 Default ``,`` (Comma)
 
 Default thousand separator used when formatting numbers. This setting is
-used only when ``NUMBER_GROUPING`` is set.
+used only when ``NUMBER_GROUPING`` and ``USE_THOUSAND_SEPARATOR`` are set.
 
-See also ``NUMBER_GROUPING``, ``DECIMAL_SEPARATOR``
+See also :setting:`NUMBER_GROUPING`, :setting:`DECIMAL_SEPARATOR` and
+:setting:`USE_THOUSAND_SEPARATOR`.
 
 .. setting:: TIME_FORMAT
 

-- 
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] r14578 - django/trunk/docs/ref

[noreply]

Author: SmileyChris
Date: 2010-11-16 15:33:48 -0600 (Tue, 16 Nov 2010)
New Revision: 14578

Modified:
   django/trunk/docs/ref/settings.txt
Log:
Better cross-referencing of the USE_THOUSAND_SEPARATOR setting in 
documentation. Thanks to Klaas van Schelven for the patch.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2010-11-16 15:15:47 UTC (rev 14577)
+++ django/trunk/docs/ref/settings.txt  2010-11-16 21:33:48 UTC (rev 14578)
@@ -1220,7 +1220,7 @@
 setting :setting:`THOUSAND_SEPARATOR` will be used as the separator between 
those
 groups.
 
-See also :setting:`THOUSAND_SEPARATOR`.
+See also :setting:`THOUSAND_SEPARATOR` and :setting:`USE_THOUSAND_SEPARATOR`.
 
 .. setting:: PASSWORD_RESET_TIMEOUT_DAYS
 
@@ -1593,9 +1593,10 @@
 Default ``,`` (Comma)
 
 Default thousand separator used when formatting numbers. This setting is
-used only when ``NUMBER_GROUPING`` is set.
+used only when ``NUMBER_GROUPING`` and ``USE_THOUSAND_SEPARATOR`` are set.
 
-See also ``NUMBER_GROUPING``, ``DECIMAL_SEPARATOR``
+See also :setting:`NUMBER_GROUPING`, :setting:`DECIMAL_SEPARATOR` and
+:setting:`USE_THOUSAND_SEPARATOR`.
 
 .. setting:: TIME_FORMAT
 

-- 
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] #14704: USE_THOUSAND_SEPARATOR poorly documented

[Django]

#14704: USE_THOUSAND_SEPARATOR poorly documented
---+
 Reporter:  vanschelven|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 The USE_THOUSAND_SEPARATOR is poorly documented. It is not referenced in
 any of the related settings (NUMBER_GROUPING and THOUSAND_SEPARATOR)

-- 
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] #14703: memcached.set_many() should not special case unicode data

[Django]

#14703: memcached.set_many() should not special case unicode data
--+-
 Reporter:  gsakkis   |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Cache system  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 memcached.set_many() tries to be "smart" by explicitly checking for
 unicode values and encoding them as utf-8; that's not even a default
 value, it is actually hardcoded.  The memcached.set() on the other hand
 just passes the value to the underlying memcached client. The bottom line
 is that the basic assumption that ''cache.set_many() is equivalent to
 calling cache.set() multiple times (but usually faster)'' is broken.

 FWIW I was bitten by this in real-world code, it's not a theoretical
 problem without actual use cases.

-- 
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] #11675: [patch] Support new memcached wrapper pylibmc

[Django]

#11675: [patch] Support new memcached wrapper pylibmc
--+-
  Reporter:  pipp...@yahoo.co.jp  | Owner:  otherjacob  
  
Status:  assigned | Milestone:  1.3 
  
 Component:  Cache system |   Version:  SVN 
  
Resolution:   |  Keywords:  cache pylibmc 
memcached.py
 Stage:  Accepted | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by elus):

 * cc: tomasz.ele...@gmail.com (added)

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

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

Re: [Django] #14702: Add a "needs info" state to tickets

[Django]

#14702: Add a "needs info" state to tickets
--+-
  Reporter:  dmoisset | Owner:  nobody
Status:  new  | Milestone:  1.3   
 Component:  Django Web site  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  1|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by dmoisset):

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

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

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

[Django] #14702: Add a "needs info" state to tickets

[Django]

#14702: Add a "needs info" state to tickets
-+--
 Reporter:  dmoisset |   Owner:  nobody
   Status:  new  |   Milestone:  1.3   
Component:  Django Web site  | Version:  1.2   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 After [wiki:Sprint201011Argentina a recent sprint] a
 [http://groups.google.com/group/django-
 developers/browse_thread/thread/b6d007ee842bde04 proposal was discussed in
 django-developers] asking for an explicit "Needs more information" state
 to Django tickets. This allows triagers to flag a common situation in
 unreviewed tickets, instead of leaving them as unreviewed (which clutters
 the review queue for triagers and duplicates work when tickets are
 reviewed twice).

 Two proposals were discussed in the mailing list:
  * Adding a "needs information" state to triage status
  * Adding a "needs info" close status

 Any of this looks reasonable (adding a close status keeps trac "cleaner"
 and avoids having another triage task, but might be off-putting to
 contributors).

 Whatever is chosen, The trac setting should be added, and the
 documentation updated

-- 
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] #14701: Meta attributes from abstract class

[Django]

#14701: Meta attributes from abstract class
--+-
 Reporter:  sneakywombat  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:  meta  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 {{{
 class CommonInfo(models.Model):
 name = models.IntegerField(default=1)
 class Meta:
 abstract = True
 ordering = ['name']

 class Student(CommonInfo):
 class Meta(CommonInfo.Meta):
 db_table = 'student_info'
 ordering = []
 }}}

 When instantiating Student as s,
 {{{
 |4>s=Student()
 |5>s.Meta.
 s.Meta.__doc__ s.Meta.__module__  s.Meta.abstracts.Meta.ordering

 |6>s.Meta.ordering
 Out[6]: ['name']

 }}}

 The ordering attribute from the parent abstract base class is not
 overwritten as described at:
 http://docs.djangoproject.com/en/dev/topics/db/models/#meta-and-multi-
 table-inheritance

 I may understand this behavior wrong, but i'd expect to be able to
 override the ordering attribute or clear it entirely (ordering=[]).  Is
 this working as designed or is this an issue?

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

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

Re: [Django] #14693: staticfiles app doesn't work with form media framework and 3rd party asset managers

[Django]

#14693: staticfiles app doesn't work with form media framework and 3rd party 
asset
managers
---+
  Reporter:  jezdez| Owner:  nobody   
Status:  new   | Milestone:  1.3  
 Component:  Contrib apps  |   Version:  1.3-alpha
Resolution:|  Keywords:   
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by alek):

 * cc: oleg.lom...@gmail.com (added)

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

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

Re: [Django] #361: Some Basic Math Filters

[Django]

#361: Some Basic Math Filters
-+--
  Reporter:  ilikepriv...@gmail.com  | Owner:  adrian 
Status:  closed  | Milestone: 
 Component:  Template system |   Version: 
Resolution:  wontfix |  Keywords:  filter math
 Stage:  Unreviewed  | Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Comment (by diramazioni):

 As newcomer to django I find really weird there is no math operations or
 the elseif operator in the template system. They are so common in
 others... Nobody willing to explain why there are such limitation?

-- 
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] #5612: Signals for login / logout

[Django]

#5612: Signals for login / logout
+---
  Reporter:  pterk  | Owner:  SmileyChris
Status:  new| Milestone:  1.3
 Component:  Core framework |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Ready for checkin  | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

  * stage:  Accepted => Ready for checkin
  * milestone:  => 1.3

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

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

[Changeset] r14577 - django/branches/releases/1.2.X/tests/regressiontests/model_inheritance_regress

[noreply]

Author: russellm
Date: 2010-11-16 09:15:47 -0600 (Tue, 16 Nov 2010)
New Revision: 14577

Added:
   
django/branches/releases/1.2.X/tests/regressiontests/model_inheritance_regress/tests.py
Modified:
   
django/branches/releases/1.2.X/tests/regressiontests/model_inheritance_regress/models.py
Log:
[1.2.X] Migrated model_inheritance_regress doctests. Thanks to Gregor 
M?\195?\188llegger for the patch.

Backport of r14576 from trunk.

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/model_inheritance_regress/models.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/model_inheritance_regress/models.py
2010-11-16 15:14:04 UTC (rev 14576)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/model_inheritance_regress/models.py
2010-11-16 15:15:47 UTC (rev 14577)
@@ -1,7 +1,3 @@
-"""
-Regression tests for Model inheritance behaviour.
-"""
-
 import datetime
 
 from django.db import models
@@ -136,255 +132,3 @@
 
 class MessyBachelorParty(BachelorParty):
 pass
-
-__test__ = {'API_TESTS':"""
-# Regression for #7350, #7202
-# Check that when you create a Parent object with a specific reference to an
-# existent child instance, saving the Parent doesn't duplicate the child. This
-# behaviour is only activated during a raw save - it is mostly relevant to
-# deserialization, but any sort of CORBA style 'narrow()' API would require a
-# similar approach.
-
-# Create a child-parent-grandparent chain
->>> place1 = Place(name="Guido's House of Pasta", address='944 W. Fullerton')
->>> place1.save_base(raw=True)
->>> restaurant = Restaurant(place_ptr=place1, serves_hot_dogs=True, 
serves_pizza=False)
->>> restaurant.save_base(raw=True)
->>> italian_restaurant = ItalianRestaurant(restaurant_ptr=restaurant, 
serves_gnocchi=True)
->>> italian_restaurant.save_base(raw=True)
-
-# Create a child-parent chain with an explicit parent link
->>> place2 = Place(name='Main St', address='111 Main St')
->>> place2.save_base(raw=True)
->>> park = ParkingLot(parent=place2, capacity=100)
->>> park.save_base(raw=True)
-
-# Check that no extra parent objects have been created.
->>> Place.objects.all()
-[, ]
-
->>> dicts = Restaurant.objects.values('name','serves_hot_dogs')
->>> [sorted(d.items()) for d in dicts] == [[('name', u"Guido's House of 
Pasta"), ('serves_hot_dogs', True)]]
-True
-
->>> dicts = 
ItalianRestaurant.objects.values('name','serves_hot_dogs','serves_gnocchi')
->>> [sorted(d.items()) for d in dicts] == [[('name', u"Guido's House of 
Pasta"), ('serves_gnocchi', True), ('serves_hot_dogs', True)]]
-True
-
->>> dicts = ParkingLot.objects.values('name','capacity')
->>> [sorted(d.items()) for d in dicts]
-[[('capacity', 100), ('name', u'Main St')]]
-
-# You can also update objects when using a raw save.
->>> place1.name = "Guido's All New House of Pasta"
->>> place1.save_base(raw=True)
-
->>> restaurant.serves_hot_dogs = False
->>> restaurant.save_base(raw=True)
-
->>> italian_restaurant.serves_gnocchi = False
->>> italian_restaurant.save_base(raw=True)
-
->>> place2.name='Derelict lot'
->>> place2.save_base(raw=True)
-
->>> park.capacity = 50
->>> park.save_base(raw=True)
-
-# No extra parent objects after an update, either.
->>> Place.objects.all()
-[, ]
-
->>> dicts = Restaurant.objects.values('name','serves_hot_dogs')
->>> [sorted(d.items()) for d in dicts] == [[('name', u"Guido's All New House 
of Pasta"), ('serves_hot_dogs', False)]]
-True
-
->>> dicts = 
ItalianRestaurant.objects.values('name','serves_hot_dogs','serves_gnocchi')
->>> [sorted(d.items()) for d in dicts] == [[('name', u"Guido's All New House 
of Pasta"), ('serves_gnocchi', False), ('serves_hot_dogs', False)]]
-True
-
->>> dicts = ParkingLot.objects.values('name','capacity')
->>> [sorted(d.items()) for d in dicts]
-[[('capacity', 50), ('name', u'Derelict lot')]]
-
-# If you try to raw_save a parent attribute onto a child object,
-# the attribute will be ignored.
-
->>> italian_restaurant.name = "Lorenzo's Pasta Hut"
->>> italian_restaurant.save_base(raw=True)
-
-# Note that the name has not changed
-# - name is an attribute of Place, not ItalianRestaurant
->>> dicts = 
ItalianRestaurant.objects.values('name','serves_hot_dogs','serves_gnocchi')
->>> [sorted(d.items()) for d in dicts] == [[('name', u"Guido's All New House 
of Pasta"), ('serves_gnocchi', False), ('serves_hot_dogs', False)]]
-True
-
-# Regressions tests for #7105: dates() queries should be able to use fields
-# from the parent model as easily as the child.
->>> obj = Child.objects.create(name='child', created=datetime.datetime(2008, 
6, 26, 17, 0, 0))
->>> Child.objects.dates('created', 'month')
-[datetime.datetime(2008, 6, 1, 0, 0)]
-
-# Regression test for #7276: calling delete() on a model with multi-table
-# inheritance should delete the associated rows from any ancestor tables, as
-# well as any descendent objects.
-
->>> ident = ItalianRestaurant.objects.all()[0].id
->>> 

[Changeset] r14576 - django/trunk/tests/regressiontests/model_inheritance_regress

[noreply]

Author: russellm
Date: 2010-11-16 09:14:04 -0600 (Tue, 16 Nov 2010)
New Revision: 14576

Added:
   django/trunk/tests/regressiontests/model_inheritance_regress/tests.py
Modified:
   django/trunk/tests/regressiontests/model_inheritance_regress/models.py
Log:
Migrated model_inheritance_regress doctests. Thanks to Gregor 
M?\195?\188llegger for the patch.

Modified: django/trunk/tests/regressiontests/model_inheritance_regress/models.py
===
--- django/trunk/tests/regressiontests/model_inheritance_regress/models.py  
2010-11-16 14:48:52 UTC (rev 14575)
+++ django/trunk/tests/regressiontests/model_inheritance_regress/models.py  
2010-11-16 15:14:04 UTC (rev 14576)
@@ -1,7 +1,3 @@
-"""
-Regression tests for Model inheritance behaviour.
-"""
-
 import datetime
 
 from django.db import models
@@ -136,255 +132,3 @@
 
 class MessyBachelorParty(BachelorParty):
 pass
-
-__test__ = {'API_TESTS':"""
-# Regression for #7350, #7202
-# Check that when you create a Parent object with a specific reference to an
-# existent child instance, saving the Parent doesn't duplicate the child. This
-# behaviour is only activated during a raw save - it is mostly relevant to
-# deserialization, but any sort of CORBA style 'narrow()' API would require a
-# similar approach.
-
-# Create a child-parent-grandparent chain
->>> place1 = Place(name="Guido's House of Pasta", address='944 W. Fullerton')
->>> place1.save_base(raw=True)
->>> restaurant = Restaurant(place_ptr=place1, serves_hot_dogs=True, 
serves_pizza=False)
->>> restaurant.save_base(raw=True)
->>> italian_restaurant = ItalianRestaurant(restaurant_ptr=restaurant, 
serves_gnocchi=True)
->>> italian_restaurant.save_base(raw=True)
-
-# Create a child-parent chain with an explicit parent link
->>> place2 = Place(name='Main St', address='111 Main St')
->>> place2.save_base(raw=True)
->>> park = ParkingLot(parent=place2, capacity=100)
->>> park.save_base(raw=True)
-
-# Check that no extra parent objects have been created.
->>> Place.objects.all()
-[, ]
-
->>> dicts = Restaurant.objects.values('name','serves_hot_dogs')
->>> [sorted(d.items()) for d in dicts] == [[('name', u"Guido's House of 
Pasta"), ('serves_hot_dogs', True)]]
-True
-
->>> dicts = 
ItalianRestaurant.objects.values('name','serves_hot_dogs','serves_gnocchi')
->>> [sorted(d.items()) for d in dicts] == [[('name', u"Guido's House of 
Pasta"), ('serves_gnocchi', True), ('serves_hot_dogs', True)]]
-True
-
->>> dicts = ParkingLot.objects.values('name','capacity')
->>> [sorted(d.items()) for d in dicts]
-[[('capacity', 100), ('name', u'Main St')]]
-
-# You can also update objects when using a raw save.
->>> place1.name = "Guido's All New House of Pasta"
->>> place1.save_base(raw=True)
-
->>> restaurant.serves_hot_dogs = False
->>> restaurant.save_base(raw=True)
-
->>> italian_restaurant.serves_gnocchi = False
->>> italian_restaurant.save_base(raw=True)
-
->>> place2.name='Derelict lot'
->>> place2.save_base(raw=True)
-
->>> park.capacity = 50
->>> park.save_base(raw=True)
-
-# No extra parent objects after an update, either.
->>> Place.objects.all()
-[, ]
-
->>> dicts = Restaurant.objects.values('name','serves_hot_dogs')
->>> [sorted(d.items()) for d in dicts] == [[('name', u"Guido's All New House 
of Pasta"), ('serves_hot_dogs', False)]]
-True
-
->>> dicts = 
ItalianRestaurant.objects.values('name','serves_hot_dogs','serves_gnocchi')
->>> [sorted(d.items()) for d in dicts] == [[('name', u"Guido's All New House 
of Pasta"), ('serves_gnocchi', False), ('serves_hot_dogs', False)]]
-True
-
->>> dicts = ParkingLot.objects.values('name','capacity')
->>> [sorted(d.items()) for d in dicts]
-[[('capacity', 50), ('name', u'Derelict lot')]]
-
-# If you try to raw_save a parent attribute onto a child object,
-# the attribute will be ignored.
-
->>> italian_restaurant.name = "Lorenzo's Pasta Hut"
->>> italian_restaurant.save_base(raw=True)
-
-# Note that the name has not changed
-# - name is an attribute of Place, not ItalianRestaurant
->>> dicts = 
ItalianRestaurant.objects.values('name','serves_hot_dogs','serves_gnocchi')
->>> [sorted(d.items()) for d in dicts] == [[('name', u"Guido's All New House 
of Pasta"), ('serves_gnocchi', False), ('serves_hot_dogs', False)]]
-True
-
-# Regressions tests for #7105: dates() queries should be able to use fields
-# from the parent model as easily as the child.
->>> obj = Child.objects.create(name='child', created=datetime.datetime(2008, 
6, 26, 17, 0, 0))
->>> Child.objects.dates('created', 'month')
-[datetime.datetime(2008, 6, 1, 0, 0)]
-
-# Regression test for #7276: calling delete() on a model with multi-table
-# inheritance should delete the associated rows from any ancestor tables, as
-# well as any descendent objects.
-
->>> ident = ItalianRestaurant.objects.all()[0].id
->>> Place.objects.get(pk=ident)
-
->>> xx = Restaurant.objects.create(name='a', address='xx', 
serves_hot_dogs=True, serves_pizza=False)
-
-# This 

[Django] #14700: Speed up RawQuerySet iterator

[Django]

#14700: Speed up RawQuerySet iterator
+---
 Reporter:  akaariai|   Owner:  nobody
   Status:  new |   Milestone:  1.3   
Component:  Database layer (models, ORM)| Version:  SVN   
 Keywords:  rawqueryset, iterator, performance  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 Currently `RawQuerySet` uses a lot of cycles doing repeatedly the same
 calculations inside the iterator loop. The attached patch corrects this
 problem with the following results, using the test found in #14697 (with
 Test2.objects.all() replaced by Test2.objects.raw('select * from
 test`__`test2'):

 Before patch: 0.9 seconds to 1.0 seconds.

 After patch 0.195 seconds to 0.205 seconds. (This is just slightly faster
 than using Test2.objects.all(), with #14697 applied)

 There is another patch, which is unfortunately most likely backwards
 incompatible. The idea of the another patch is to speed up model instance
 initialization by passing in a dict(attname->val) containing all the
 values needed, and then using self.`__`dict`__`.update(attname, val). This
 however adds a new keyword argument to the `__`init`__`. Before the patch,
 all the kwargs were attr -> value, but after that there can be a kwarg
 '`_`use_dict', which contains a dict of attname -> val. The patch cuts off
 another 0.06 seconds (or 30%) from the test case, leaving around 0.14
 seconds left. There might be some other incompatibilities, too... The same
 amount of performance increase could be achieved for standard `QuerySet`
 iterator using the same hack.

 Just fetching the data from db, creating 1 raw objects and updating 10
 attributes for each of those objects results in 0.01 seconds used. Hence
 there is just 0.04, or 40% overhead left when using the second patch, and
 100% overhead when using the first patch.

 I will try to find the time to write django-bench benchmark for this case.

-- 
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] #14683: FormWizard done() method doesn't get the last form in form_list

[Django]

#14683: FormWizard done() method doesn't get the last form in form_list
-+--
  Reporter:  Luke Sneeringer   | 
Owner:  nobody   
Status:  closed  | 
Milestone:   
 Component:  django.contrib.formtools|   
Version:  1.3-alpha
Resolution:  duplicate   |  
Keywords:   
 Stage:  Unreviewed  | 
Has_patch:  0
Needs_docs:  0   |   
Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by lukeplant):

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

Comment:

 Duplicate of #14576

-- 
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] r14574 - in django/trunk/django/contrib/formtools: . tests

[noreply]

Author: lukeplant
Date: 2010-11-16 08:37:00 -0600 (Tue, 16 Nov 2010)
New Revision: 14574

Modified:
   django/trunk/django/contrib/formtools/tests/__init__.py
   django/trunk/django/contrib/formtools/wizard.py
Log:
Fixed #14576 - FormWizard.done() method doesn't get passed the last form in the 
list

Thanks to cyberdelia for report and test, and steph for the initial patch.

Modified: django/trunk/django/contrib/formtools/tests/__init__.py
===
--- django/trunk/django/contrib/formtools/tests/__init__.py 2010-11-16 
14:00:38 UTC (rev 14573)
+++ django/trunk/django/contrib/formtools/tests/__init__.py 2010-11-16 
14:37:00 UTC (rev 14574)
@@ -360,3 +360,27 @@
 "wizard_step": "1"}
 wizard(DummyRequest(POST=data))
 
+def test_14576(self):
+"""
+Regression test for ticket #14576.
+
+The form of the last step is not passed to the done method.
+"""
+reached = [False]
+that = self
+
+class Wizard(WizardClass):
+def done(self, request, form_list):
+reached[0] = True
+that.assertTrue(len(form_list) == 2)
+
+wizard = Wizard([WizardPageOneForm,
+ WizardPageTwoForm])
+
+data = {"0-field": "test",
+"1-field": "test2",
+"hash_0": "2fdbefd4c0cad51509478fbacddf8b13",
+"wizard_step": "1"}
+wizard(DummyRequest(POST=data))
+self.assertTrue(reached[0])
+

Modified: django/trunk/django/contrib/formtools/wizard.py
===
--- django/trunk/django/contrib/formtools/wizard.py 2010-11-16 14:00:38 UTC 
(rev 14573)
+++ django/trunk/django/contrib/formtools/wizard.py 2010-11-16 14:37:00 UTC 
(rev 14574)
@@ -116,9 +116,9 @@
 # Since the hashes only take into account values, and not other
 # other validation the form might do, we must re-do validation
 # now for security reasons.
-current_form_list = [self.get_form(i, request.POST) for i in 
range(current_step)]
+previous_form_list = [self.get_form(i, request.POST) for i in 
range(current_step)]
 
-for i, f in enumerate(current_form_list):
+for i, f in enumerate(previous_form_list):
 if not self._check_security_hash(request.POST.get("hash_%d" % 
i, ''), request, f):
 return self.render_hash_failure(request, i)
 
@@ -132,7 +132,7 @@
 next_step = current_step + 1
 
 if next_step == self.num_steps():
-return self.done(request, current_form_list)
+return self.done(request, previous_form_list + [form])
 else:
 form = self.get_form(next_step)
 self.step = current_step = next_step

-- 
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] #14699: FormWizard tests are scattered between two test modules

[Django]

#14699: FormWizard tests are scattered between two test modules
---+
 Reporter:  lukeplant  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Tests for these classes are found in regressiontests/formwizard and in
 django/contrib/formtools/tests with significant overlap, which appears to
 be an accident - from [10316] it seems that Jacob didn't realise that
 there were already some `FormWizard` tests added in [8603].

 All the tests should be moved to django/contrib/formtools to make it easy
 to find them.

 The only difficult thing is deciding how to merge them - they overlap
 significantly.  It is probably best to:

  * copy some of the details of the regressiontests/forms.py to the contrib
 tests (the `NullBooleanField` is required to check #9473)
  * bulk out the contrib tests to do a complete walk-though like the
 regressiontests.

-- 
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] r14573 - django/trunk/docs/howto

[noreply]

Author: lukeplant
Date: 2010-11-16 08:00:38 -0600 (Tue, 16 Nov 2010)
New Revision: 14573

Modified:
   django/trunk/docs/howto/error-reporting.txt
Log:
Added info about using logging to the 'Error reporting' howto.

Modified: django/trunk/docs/howto/error-reporting.txt
===
--- django/trunk/docs/howto/error-reporting.txt 2010-11-16 13:32:07 UTC (rev 
14572)
+++ django/trunk/docs/howto/error-reporting.txt 2010-11-16 14:00:38 UTC (rev 
14573)
@@ -39,6 +39,14 @@
 To disable this behavior, just remove all entries from the :setting:`ADMINS`
 setting.
 
+.. seealso::
+
+   .. versionadded:: 1.3
+
+   Server error e-mails are sent using the logging framework, so you can
+   customize this behaviour by :doc:`customizing your logging configuration
+   `.
+
 404 errors
 --
 
@@ -76,3 +84,12 @@
 :ref:`exception middleware `. If you do write custom
 error handling, it's a good idea to emulate Django's built-in error 
handling
 and only report/log errors if :setting:`DEBUG` is ``False``.
+
+.. seealso::
+
+   .. versionadded:: 1.3
+
+   404 errors are logged using the logging framework. By default, these log
+   records are ignored, but you can use them for error reporting by writing a
+   handler and :doc:`configuring logging ` appropriately.
+

-- 
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] #14698: django.utils.module_loading.module_has_submodule yields false positives

[Django]

#14698: django.utils.module_loading.module_has_submodule yields false positives
+---
  Reporter:  lrekucki   | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by lrekucki):

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

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

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

[Django] #14698: django.utils.module_loading.module_has_submodule yields false positives

[Django]

#14698: django.utils.module_loading.module_has_submodule yields false positives
---+
 Reporter:  lrekucki   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The way I found this is a bit crazy, so I'm not going to describe it all,
 but the 2 important things are:

   # I have some explicit relative imports.
   # I wanted to make a template library named the same as the application
 it contains.

 This generally should work (tried on a fresh project), but failed with a
 weird error in my project: "'currencies' is not a valid tag library:
 ImportError raised loading company.templatetags.currencies: No module
 named currencies". Of course there is no such module, because it's on
 "currencies.templatags" application.

 So after some debuging it turned out that module_has_submodule returns a
 false positive. This is because it checks {{{ if name in sys.modules }}}.
 To be honest, I didn't know about this, but it seems that Python sometimes
 also stores import misses by puting a None in to that dictionary. See
 [http://mail.python.org/pipermail/python-dev/2009-July/090780.html this
 python-dev thread].

-- 
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] r14572 - django/branches/releases/1.2.X/docs/howto

[noreply]

Author: lukeplant
Date: 2010-11-16 07:32:07 -0600 (Tue, 16 Nov 2010)
New Revision: 14572

Modified:
   django/branches/releases/1.2.X/docs/howto/error-reporting.txt
Log:
[1.2.X] Corrected 'email' to 'e-mail' in error reporting docs.

Backport of [14571] from trunk.

Modified: django/branches/releases/1.2.X/docs/howto/error-reporting.txt
===
--- django/branches/releases/1.2.X/docs/howto/error-reporting.txt   
2010-11-16 13:30:31 UTC (rev 14571)
+++ django/branches/releases/1.2.X/docs/howto/error-reporting.txt   
2010-11-16 13:32:07 UTC (rev 14572)
@@ -9,7 +9,7 @@
 However, running with :setting:`DEBUG` set to ``False`` means you'll never see
 errors generated by your site -- everyone will just see your public error 
pages.
 You need to keep track of errors that occur in deployed sites, so Django can be
-configured to email you details of those errors.
+configured to e-mail you details of those errors.
 
 Server errors
 -
@@ -32,8 +32,8 @@
documentation ` for a full list of email-related
settings.
 
-By default, Django will send email from r...@localhost. However, some mail
-providers reject all email from this address. To use a different sender
+By default, Django will send e-mail from r...@localhost. However, some mail
+providers reject all e-mail from this address. To use a different sender
 address, modify the :setting:`SERVER_EMAIL` setting.
 
 To disable this behavior, just remove all entries from the :setting:`ADMINS`
@@ -42,8 +42,8 @@
 404 errors
 --
 
-Django can also be configured to email errors about broken links (404 "page
-not found" errors). Django sends emails about 404 errors when:
+Django can also be configured to e-mail errors about broken links (404 "page
+not found" errors). Django sends e-mails about 404 errors when:
 
 * :setting:`DEBUG` is ``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] r14571 - django/trunk/docs/howto

[noreply]

Author: lukeplant
Date: 2010-11-16 07:30:31 -0600 (Tue, 16 Nov 2010)
New Revision: 14571

Modified:
   django/trunk/docs/howto/error-reporting.txt
Log:
Corrected 'email' to 'e-mail' in error reporting docs.

Modified: django/trunk/docs/howto/error-reporting.txt
===
--- django/trunk/docs/howto/error-reporting.txt 2010-11-16 13:20:56 UTC (rev 
14570)
+++ django/trunk/docs/howto/error-reporting.txt 2010-11-16 13:30:31 UTC (rev 
14571)
@@ -9,7 +9,7 @@
 However, running with :setting:`DEBUG` set to ``False`` means you'll never see
 errors generated by your site -- everyone will just see your public error 
pages.
 You need to keep track of errors that occur in deployed sites, so Django can be
-configured to email you details of those errors.
+configured to e-mail you details of those errors.
 
 Server errors
 -
@@ -32,8 +32,8 @@
documentation ` for a full list of email-related
settings.
 
-By default, Django will send email from r...@localhost. However, some mail
-providers reject all email from this address. To use a different sender
+By default, Django will send e-mail from r...@localhost. However, some mail
+providers reject all e-mail from this address. To use a different sender
 address, modify the :setting:`SERVER_EMAIL` setting.
 
 To disable this behavior, just remove all entries from the :setting:`ADMINS`
@@ -42,8 +42,8 @@
 404 errors
 --
 
-Django can also be configured to email errors about broken links (404 "page
-not found" errors). Django sends emails about 404 errors when:
+Django can also be configured to e-mail errors about broken links (404 "page
+not found" errors). Django sends e-mails about 404 errors when:
 
 * :setting:`DEBUG` is ``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.

Re: [Django] #12320: Translations hints in HTML are lost in PO file

[Django]

#12320: Translations hints in HTML are lost in PO file
---+
  Reporter:  bronger   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Internationalization  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by claudep):

  * has_patch:  0 => 1
  * milestone:  => 1.3

Comment:

 Proposed patch uploaded. Note that it properly applies only on top of
 #10004 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] #14697: Speeding up queryset model instance creation

[Django]

#14697: Speeding up queryset model instance creation
---+
  Reporter:  akaariai  | Owner:  nobody 

Status:  new   | Milestone:  1.3

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

Resolution:|  Keywords:  
performance, queryset, iterator
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

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

 Yes, I will look into transforming the test to django-bench. However I
 can't promise when. I have already used too much work time for this, but
 if nobody tells my boss I might be able to transform that benchmark into
 django-bench test tomorrow...

-- 
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] #10004: Enable -c switch in xgettext call to collect translator comments

[Django]

#10004: Enable -c switch in xgettext call to collect translator comments
---+
  Reporter:  claudep   | Owner:  
Status:  new   | Milestone:  1.3 
 Component:  Internationalization  |   Version:  1.0 
Resolution:|  Keywords:  makemessages
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by jezdez):

 Looks good to me, maby "l10n" for the keyword would be better, e.g. Pootle
 uses it here:
 
https://translate.svn.sourceforge.net/svnroot/translate/src/trunk/Pootle/local_apps/pootle_app/management/commands/makepropermessages.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-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] #14697: Speeding up queryset model instance creation

[Django]

#14697: Speeding up queryset model instance creation
---+
  Reporter:  akaariai  | Owner:  nobody 

Status:  new   | Milestone:  1.3

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

Resolution:|  Keywords:  
performance, queryset, iterator
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

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

 Just as a pointer, if you wanted to create that benchmark - I think you
 could call the benchmark 'query_all', use the 'query_get' benchmark as an
 example, and use the 'setup' keyword argument to the 'run_benchmark'
 utility to create your objects rather than using a fixture. You should
 find it very straightforward.

-- 
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] #14697: Speeding up queryset model instance creation

[Django]

#14697: Speeding up queryset model instance creation
---+
  Reporter:  akaariai  | Owner:  nobody 

Status:  new   | Milestone:  1.3

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

Resolution:|  Keywords:  
performance, queryset, iterator
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 It's not a requirement for a patch being accepted, but it would really
 help me and possibly others to have your example as part of
 [https://github.com/jacobian/djangobench django-bench].  Jacob usually
 accepts pull requests for that fairly quickly. It should help you do more
 optimisations as well.

 Or, if there is an existing benchmark which shows similar stats for your
 patch, just point us to that one.

 Thanks!

-- 
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] #5494: javascript_catalog generic view only search catalogs in application/locale and not in project/locale

[Django]

#5494: javascript_catalog generic view only search catalogs in 
application/locale
and not in project/locale
---+
  Reporter:  anonymous | Owner: 
Status:  new   | Milestone:  1.3
 Component:  Internationalization  |   Version:  SVN
Resolution:|  Keywords:  javascript i18n
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by jezdez):

  * needs_docs:  0 => 1

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

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

Re: [Django] #8217: Alphabetical sorted FilePathField

[Django]

#8217: Alphabetical sorted FilePathField
+---
  Reporter:  bernd  | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Forms  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

  * stage:  Accepted => Ready for checkin

Comment:

 I could reproduce this on a Debian Lenny server.

-- 
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] #14415: Multiple aliases for one database: testing problems

[Django]

#14415: Multiple aliases for one database: testing problems
-+--
  Reporter:  shai| Owner:  nobody   

Status:  new | Milestone:   

 Component:  Testing framework   |   Version:  1.2  

Resolution:  |  Keywords:  multidb, 
multiple databases, multiple aliases
 Stage:  Design decision needed  | Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

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

  * has_patch:  0 => 1

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

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

Re: [Django] #14415: Multiple aliases for one database: testing problems

[Django]

#14415: Multiple aliases for one database: testing problems
-+--
  Reporter:  shai| Owner:  nobody   

Status:  new | Milestone:   

 Component:  Testing framework   |   Version:  1.2  

Resolution:  |  Keywords:  multidb, 
multiple databases, multiple aliases
 Stage:  Design decision needed  | Has_patch:  0

Needs_docs:  0   |   Needs_tests:  0

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

  * stage:  Accepted => Design decision needed

Comment:

 This is what I've found:

 I think the maximum that Django can provide is what I've tried to
 implement in the patch:

  * Make sure no cross pollution of `DATABASES['alias']['NAME']` and
 `DATABASES['alias']['TEST_NAME']` happens between DB aliases/connections,
 even when they are described by the same Python dict so in no event the
 production `DATABASES['alias']['NAME']` DB gets removed.
  * Don't report an error if the test database doesn't exist when trying to
 drop it (or, for SQLite3, don't try to remove the DB file).

 What's described above is generally applicable to Postgres, MySQL and
 SQlite3.

 But after fixing that, there are other problems (at test DB teardown
 time): In Postgres and MySQL the test databases are removed by using the
 production one as a pivot (a connection is made to the production DB and
 from there the test one is DROPped). If you get the setup you describe, it
 might happen (It happens to me) that 'default' will get is test DB
 ('test_main') dropped and when 'other' tries to connect to its production
 one to do the same (remove it 'test_test_main' DB) it won't find it.

 Solving this means Django would need to detect and keep track of the fact
 that one alias' test DB name is the same as other alias' production DB,
 and DATABASES being a dict, there is no guaranteed order of
 creation/removal of DBs.

 The conclusion I get is this is what you describe as the ''The more
 dangerous case'' and ''one may expect this to be the common use case in a
 multiple-aliases-for-one-database approach'' is enough of an edge case
 that can't be completely solved by Django. If you really need to create
 more that one DATABASES aliases to the same database and you decide to
 represent them by pointing them to the same dict, then maybe you will need
 to implement your own test runner that will need to have some inside
 knowledge of this and e.g. will need to setup/tear down the test DBs in
 the right order, etc.

 The Oracle backed has its own tools so (again) the user, not Django, tries
 to implement a workaround to the scenarios you describe (see
 wiki:OracleTestSetup ''Understanding the database test setup'' section.)

-- 
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] #14443: Oracle backend returns wrong test database name

[Django]

#14443: Oracle backend returns wrong test database name
---+
  Reporter:  gruszczy  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  wontfix   |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Comment:

 After learning a bit about how the Oracle backend handles the test
 environment preparation, I've found this:

  * The backend implements its own tablespace-based scheme (not a database-
 based one) so the value returned by `DatabaseCreation._create_test_db()`
 isn't really the one used to create/remove any test database like is done
 by the other Django DB backends. For more details please refer to the
 wiki:OracleTestSetup document (''Understanding the database test setup''
 section.)

  * This changes actually breaks test environment setup, because the
 backend actually tries to connect to the DB returned by this method:

 {{{
 Creating test database 'default'...
 Creating test user...
 Creating test database 'other'...
 Creating test user...
 Traceback (most recent call last):
   File "./runtests.py", line 314, in 
 failures = django_tests(int(options.verbosity), options.interactive,
 options.failfast, args)
   File "./runtests.py", line 183, in django_tests
 failures = test_runner.run_tests(test_labels, extra_tests=extra_tests)
   File "django/final/django/test/simple.py", line 276, in run_tests
 old_config = self.setup_databases()
   File "django/final/django/test/simple.py", line 232, in setup_databases
 connection.creation.create_test_db(self.verbosity, autoclobber=not
 self.interactive)
   File "django/final/django/db/backends/creation.py", line 352, in
 create_test_db
 self.connection.features.confirm()
   File "django/final/django/db/backends/__init__.py", line 169, in confirm
 self.supports_transactions = self._supports_transactions()
   File "django/final/django/db/backends/__init__.py", line 174, in
 _supports_transactions
 cursor = self.connection.cursor()
   File "django/final/django/db/backends/__init__.py", line 77, in cursor
 cursor = self._cursor()
   File "django/final/django/db/backends/oracle/base.py", line 367, in
 _cursor
 self.connection = Database.connect(conn_string,
 **self.settings_dict['OPTIONS'])
 cx_Oracle.DatabaseError: ORA-12154: TNS:could not resolve the connect
 identifier specified
 }}}

 So, I'm going to close this ticket, please reopen it if you further Oracle
 and Oracle backend hindsight and can implement the proposed change but
 accompanied by others so the above breakage doesn't happen.

-- 
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] #9213: PasswordResetForm should not reset passwords for inactive users

[Django]

#9213: PasswordResetForm should not reset passwords for inactive users
---+
  Reporter:  john_scott| Owner:  anonymous
Status:  assigned  | Milestone:   
 Component:  Contrib apps  |   Version:  1.3-alpha
Resolution:|  Keywords:   
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * owner:  nobody => anonymous
  * status:  new => assigned
  * version:  1.0 => 1.3-alpha

-- 
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] #14697: Speeding up queryset model instance creation

[Django]

#14697: Speeding up queryset model instance creation
-+--
 Reporter:  akaariai |   Owner:  nobody
   Status:  new  |   Milestone:  1.3   
Component:  Database layer (models, ORM) | Version:  SVN   
 Keywords:  performance, queryset, iterator  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 The attached patch does some easy optimizations to speed up iteration and
 thus model instance creation when using querysets.

 The tests are run using the following code:

 {{{
 models.py:

 from django.db import models

 class Test1(models.Model):
 pass

 # Create your models here.
 class Test2(models.Model):
 field1 = models.CharField(max_length=20)
 field2 = models.ForeignKey(Test1)
 field3 = models.CharField(max_length=20)
 field4 = models.CharField(max_length=20)
 field5 = models.CharField(max_length=20)
 field6 = models.CharField(max_length=20)
 field7 = models.CharField(max_length=20)
 field8 = models.CharField(max_length=20)
 field9 = models.CharField(max_length=20)
 field10 = models.CharField(max_length=20)
 field11 = models.CharField(max_length=20)
 field12 = models.CharField(max_length=20)
 field13 = models.CharField(max_length=20)

 test.py:
 from test_.models import *
 """
 Uncomment for first run to create objects...
 t2 = Test1(pk=1)
 t2.save()
 for i in range(0, 1000):
 t = Test2(pk=i, field1='value', field2=t2)
 t.save()
 for i in range(0, 1000):
 t = Test1(pk=i)
 t.save()
 """
 from datetime import datetime
 from django.conf import settings
 # dummy read of settings to avoid weird results in timing:
 # first read of settings changes timezone...
 t = settings.INSTALLED_APPS

 def fetch_objs():
 for i in range(0, 10):
 #for obj in Test1.objects.all():
 for obj in Test2.objects.all():
 pass

 import hotshot, hotshot.stats
 prof = hotshot.Profile("test.prof")
 prof.runcall(fetch_objs)
 prof.close()
 stats = hotshot.stats.load("test.prof")
 # stats.strip_dirs()
 stats.sort_stats('time', 'calls')
 stats.print_stats(50)
 start = datetime.now()
 fetch_objs()
 print '%s' % (datetime.now() - start)
 # What is the absolute maximum that can be achieved?
 from django.db import connection
 cursor = connection.cursor()
 start = datetime.now()
 for i in range(0, 10):
 cursor.execute('select * from test__test2')
 for obj in cursor.fetchall():
 pass
 print '%s' % (datetime.now() - start)
 }}}

 The results on my computer are as follows:

 When fetching 1 test1 objects:
 0.085 seconds with patch, 0.145 seconds without patch

 When fetching 1 test2 objects:
 0.200 seconds with patch, 0.27 seconds without patch

 So, this should result in 20-40% speed up for these simple cases.

 The absolute maximum that can be achieved is somewhere around 0.015
 seconds for the Test1 case (0.007 for fetching from DB, and 0.07 for
 creating a python object and setting attributes for it). Add in signals
 and ModelState creation, and you land in somewhere between 0.02-0.03. So,
 there is still some ground for optimizations, but going further doesn't
 seem too easy. Possible optimizations: pass to
 base.py/BaseModel.`__init__` a dict containing attr_name: val, so that one
 can update the model `__dict__` directly. This results in around 20%
 speedup, but is backwards incompatible (either init *args or **kwargs need
 to contain that dict and existing code does not expect that). and for that
 reason not included here. Another possibility is to include a different
 method (qs.as_list()) to fetch the list without any caching (just fetch
 all the results from cursor and create a list from that). I think that
 would result in around 20% more speedup, but would require maintaining two
 different implementations for fetching objects.

 Just as a datapoint: Doing the same using Test2.object.raw("select * from
 test`__`test2") results in about 1 second run time. I am going to look
 into that next, as that is _really_ bad.

-- 
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] #13546: Easier handling of localize field options in ModelForm

[Django]

#13546: Easier handling of localize field options in ModelForm
---+
  Reporter:  hsk   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Forms |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by wogan):

 * cc: wogan (added)

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

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