Re: [Django] #14572: Minor fix for generic inline formsets

[Django]

#14572: Minor fix for generic inline formsets
---+
  Reporter:  simon29   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by simon29):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * version:  1.2 => SVN
  * needs_tests:  => 0
  * milestone:  => 1.3

Comment:

 Note this also adds **kwargs support to GenericInlineModelAdmin, as per
 InlineModelAdmin.

-- 
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] #14572: Minor fix for generic inline formsets

[Django]

#14572: Minor fix for generic inline formsets
--+-
 Reporter:  simon29   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Contrib apps  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Following on from #13095, generic_inlineformset_factory also needs a minor
 patch.

 () got an unexpected keyword argument 'widget'

-- 
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] #14571: Update jQuery to v1.4.3

[Django]

#14571: Update jQuery to v1.4.3
---+
  Reporter:  robhudson | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:  jquery
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by robhudson):

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

Comment:

 Trac wouldn't accept my patch because of the file size (278k?). You can
 find a diff on my github repo:
 http://github.com/robhudson/django/tree/jquery-1.4.3

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

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

Re: [Django] #8054: Move method properties for admin list customisation to ModelAdmin

[Django]

#8054: Move method properties for admin list customisation to ModelAdmin
+---
  Reporter:  Daniel Pope   | Owner:  
brosner
Status:  assigned   | Milestone:  
1.3
 Component:  django.contrib.admin   |   Version:  
SVN
Resolution: |  Keywords:
 
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  1  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by buriy):

  * needs_docs:  0 => 1

Comment:

 Patch is looking good, except few small things:

 1) value_map is not a function what can be read from its name, but a dict.
 If it is used mostly for choices, it should be named so.

 2) There's no line in docs mentioning value_map is applied *before*
 filters?

 3) I'm not sure if we need 200 Kb fixture file called listcolumns.json
 Can we strip it to few lines, showcasing all the features?
 Tests themselves are very good!

 4)
 This is backward compatibility hack one copied from
 django.contrib.admin.util.label_for_field, but it's completely
 undocumented (and i'm not sure if it's required in django 1.3!):
 {{{
 145 if self.field_name == '__unicode__':
 146 self.header =
 force_unicode(model._meta.verbose_name)
 147 elif self.field_name == '__str__':
 148 self.header =
 smart_str(model._meta.verbose_name)
 }}}
 Why can't you just reuse label_for_field to always provide header info for
 you?

 5) Wiki docs don't mention how ListColumn can be used together with
 list_display_links.

 6) list_display_links should take ListColumn, or some special instance,
 but not its field_name attribute, or you might have 2 fields selected if
 they just have different filters applied to the same model or modeladmin
 attribute.
 However this might be mention in docs as a known limitation and workaround
 shown.

 7) Typos in wiki docs: 'tagging_autocomplite_tags' ->
 'tagging_autocomplete_tags', 'calable' -> 'callable'

 8) Wiki docs don't list admin filters that can be used now (boolean_icon)

-- 
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] #14571: Update jQuery to v1.4.3

[Django]

#14571: Update jQuery to v1.4.3
--+-
 Reporter:  robhudson |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:  jquery|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 A new jQuery has been released with some nice performance improvements:
 http://blog.jquery.com/2010/10/16/jquery-143-released/

 Note: 1.4.4 is planned to be released early November, so possibly it is
 worthwhile to wait for that release?  See:
 http://blog.jquery.com/2010/10/24/community-updates-2610/

-- 
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] #14570: New format character to represent locale-specifc alternative month names

[Django]

#14570: New format character to represent locale-specifc alternative month names
--+-
 Reporter:  shell_dweller |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Internationalization  | Version:  SVN   
 Keywords:  month, format |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 == Why this is required ==

 In certain locales "F" is not enough to represent full month name in long
 date formats. The reason is that "F Y" (e.g., "October 2010") and "F j Y"
 (e.g., "October 1 2010") will require two different grammatical forms for
 month name.

 This patch is useful for Greek and the majority of Slavic languages. Other
 languages may find use of it too.

 == Solution ==

 New format character is introduced to represent alternative locale
 specific month names. The choice of character is "E". Rationale:
 alphabetically it is the closest one to "F" that represents full month
 name.

 == TODO ==

 After this patch is committed to trunk I will create a patch for
 documentation and will notify translators.

 == Historical note ==

 This is a duplicate of ticket 12309 that was created and subsequently
 closed by me. At the time I reckoned that it would be better to use Babel
 for locale specific date representations. However, after careful
 consideration I changed my mind and I do believe this is a useful addition
 to Django because it follows batteries included principle, specially in
 view of new format localization rules introduced in 1.2

-- 
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] #14569: Raw query for date field returns unicode instead of datetime object in sqlite

[Django]

#14569: Raw query for date field returns unicode instead of datetime object in
sqlite
--+-
 Reporter:  robin |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:  raw query date sqlite postgresql  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Using sqlite
 {{{
 >>> m = MyModel.objects.raw('select id,max(date_added) as d from
 app_modelname group by id')
 >>> m[0].d
 u'2010-10-26 04:11:33.123513'
 }}}
 Whereas with postgresql
 {{{
 >>> m[0].d
 datetime.datetime(2010, 10, 26, 4, 11, 33)
 }}}

 I believe the result returning a datetime object by postgresql is correct,
 whereas sqlite is not.

-- 
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] #14568: FormMixin.get_form should use keyword arguments for data & files

[Django]

#14568: FormMixin.get_form should use keyword arguments for data & files
+---
  Reporter:  mattmcc| Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Generic views  |   Version:  SVN   
Resolution: |  Keywords:  forms 
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mattmcc):

  * 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] #14568: FormMixin.get_form should use keyword arguments for data & files

[Django]

#14568: FormMixin.get_form should use keyword arguments for data & files
---+
 Reporter:  mattmcc|   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Generic views  | Version:  SVN   
 Keywords:  forms  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 django.forms.BaseForm's constructor defines all its arguments as keyword
 arguments, but generic views have always passed data and files as
 positional arguments.  The switch to class-based views makes for a nice
 opportunity to change that.

-- 
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] #14425: Unused imports in contrib.admin

[Django]

#14425: Unused imports in contrib.admin
---+
  Reporter:  robhudson | Owner:  SmileyChris
Status:  reopened  | Milestone: 
 Component:  django.contrib.admin  |   Version:  1.2
Resolution:|  Keywords: 
 Stage:  Ready for checkin | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by clong):

 * cc: clong (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] #14425: Unused imports in contrib.admin

[Django]

#14425: Unused imports in contrib.admin
---+
  Reporter:  robhudson | Owner:  SmileyChris
Status:  reopened  | Milestone: 
 Component:  django.contrib.admin  |   Version:  1.2
Resolution:|  Keywords: 
 Stage:  Ready for checkin | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by clong):

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

Comment:

 This change breaks the example given in the admin actions documentation:
 http://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/,
 specifically this line: selected =
 request.POST.getlist(admin.ACTION_CHECKBOX_NAME)

 Should either add the line back to __init__.py: from
 django.contrib.admin.helpers import ACTION_CHECKBOX_NAME

 Or change the documentation.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #12687: Using exclude on a queryset with an annotate field give attribute error.

[Django]

#12687: Using exclude on a queryset with an annotate field give attribute error.
--+-
  Reporter:  AsgeirM  | Owner:  
   
Status:  new  | Milestone:  1.3 
   
 Component:  ORM aggregation  |   Version:  1.2 
   
Resolution:   |  Keywords:  annotate exclude 
AttributeError
 Stage:  Accepted | Has_patch:  0   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by Petr Marhoun ):

 Ticket #13356 was closed as duplicate of this patch - It is true that is
 seems to be quite similar and there is more information here. But I think
 that it has more simple example of the problem and it could be also here.

 Following code works :

 {{{
 #!python
 from django.contrib.auth.models import User
 from django.db.models import Count
 User.objects.filter(id__in=[]).annotate(Count('groups'))
 []
 User.objects.filter(id__in=[]).count()
 0
 }}}

 But following code raise !EmptyResultSet:

 {{{
 #!python
 User.objects.filter(id__in=[]).annotate(Count('groups')).count()
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13769: ModelForm: override default field attributes

[Django]

#13769: ModelForm: override default field attributes
-+--
  Reporter:  darkrho | Owner:  asenchi  
 
Status:  reopened| Milestone:   
 
 Component:  Forms   |   Version:  SVN  
 
Resolution:  |  Keywords:  modelform 
fields_attrs
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by Petr Marhoun ):

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

Comment:

 Ticket reopened: New meta attribute "widgets" was really implemented in
 1.2, but it is only for overriding of one attribute "widget". This ticket
 is about overriding of general attributes (for example label, required or
 something specific for given field) without total replacement of the
 field.

 Added new version of patch which could be applied against trunk. And it is
 again with doctests - model_forms tests have not been ported to unittest
 yet.

-- 
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] #10557: FormWizard should not output raw HTML for previous_fields

[Django]

#10557: FormWizard should not output raw HTML for previous_fields
+---
  Reporter:  Matthew Flanagan   | 
Owner:  nobody
Status:  new| 
Milestone:  1.3   
 Component:  django.contrib.formtools   |   
Version:  SVN   
Resolution: |  
Keywords:  wizard
 Stage:  Ready for checkin  | 
Has_patch:  1 
Needs_docs:  0  |   
Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by lrekucki):

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

Comment:

 It's 1.3 now and apart from not being backwards compatible, looks good to
 me. This also helps writing tests, because you don't have to parse the raw
 HTML to get the security_hash for the next step.

-- 
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] #12068: The {% url %} parser can fail with StopIteration

[Django]

#12068: The {% url %} parser can fail with StopIteration
-+--
  Reporter:  emulbreh| Owner:  smoluf 
Status:  closed  | Milestone:  1.3
 Component:  Template system |   Version:  1.1
Resolution:  fixed   |  Keywords:  url tag
 Stage:  Design decision needed  | Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by lrekucki):

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

Comment:

 This is fixed on 1.2.x and trunk, probably for a while 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] #14567: ModelMultipleChoiceField inconsistently returns a list if empty.

[Django]

#14567: ModelMultipleChoiceField inconsistently returns a list if empty.
--+-
 Reporter:  melinath  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Forms | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 The ModelMultipleChoiceField is described as "A MultipleChoiceField whose
 choices are a model QuerySet." If some models have been selected, then the
 cleaned value of this field is a queryset. However, if the field is not
 required and the value is empty, the cleaned value returned is a list.

 This is inconsistent and causes problems if, say, you want to check that
 the value passed to a method is a queryset and, if so, access
 queryset.model. The attached patch replaces [] with self.queryset.none().
 I'll work on tests tomorrow if nobody beats me to it.

-- 
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] #9964: Transaction middleware closes the transaction only when it's marked as dirty

[Django]

#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---+
  Reporter:  ishirav   | Owner:  
mtredinnick 
Status:  assigned  | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
 
Resolution:|  Keywords:  
transactions
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by shai):

 Jeez, people. What's required here is a design decision by core
 committers, which I called for   [comment:21 more than 7 months ago]:
 >
 > Since transactions are deep, and changing their behavior might break
 user applications, I suggested (...) a three-step path towards correct
 behavior (...) If you'd consider a patch which just always closes
 transactions, just say so, and I'll provide one.
 >

 The expressions of disbelief and ridicule, accompanied by repetition of
 obviously correct statements about the right way to manage transactions,
 are not helpful.

-- 
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] #14558: Generic View http_method bug

[Django]

#14558: Generic View http_method bug
+---
  Reporter:  pyrou  | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Generic views  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by lrekucki):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This is a problem. Personally, I'm not very happy with either way of
 aliasing, because there is no way to get rid of the alias. With the alias
 always there, you can't create a view that deletes on DELETE and creates a
 child resource on POST (which is the original meaning of that HTTP verb).

 There is also an slight inconsistency in UpdateView, which aliases POST to
 PUT, but IMHO this is a part of a larger 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] #11864: Relationship backreference documentation is hard to find

[Django]

#11864: Relationship backreference documentation is hard to find
+---
  Reporter:  anonymous  | Owner:  dwillis
Status:  assigned   | Milestone: 
 Component:  Documentation  |   Version:  1.1
Resolution: |  Keywords:  relationships foreigkey
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  1  |  
+---
Changes (by danielr):

  * needs_better_patch:  0 => 1

Comment:

 I don't think that belongs there at all. It goes straight from providing
 the syntax for ForeignKey to talking about following backwards
 relationships - it hasn't even shown how to follow forwards ones yet. I
 think this would be better off with a simple link from there to the
 Related objects documentation (topics/db/queries/#related-objects),
 perhaps replacing the existing See Also box which unhelpfully goes to the
 FK doctests.

-- 
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] #14504: Generic ListView pagination broken

[Django]

#14504: Generic ListView pagination broken
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Generic views  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by lrekucki):

  * has_patch:  0 => 1
  * needs_tests:  1 => 0
  * stage:  Unreviewed => Accepted

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14566: Multiple database issue v1.2.3 - Django reading the wrong database

[Django]

#14566: Multiple database issue v1.2.3 - Django reading the wrong database
---+
  Reporter:  stodge| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by emulbreh):

 Is that a typo in the description or have you really swapped `get` and
 `using` ?
 {{{
 #!python
 Scene.objects.get(id=3).using('scenes')
 # vs
 Scene.objects.using('scenes').get(id=3)
 }}}

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

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

Re: [Django] #8054: Move method properties for admin list customisation to ModelAdmin

[Django]

#8054: Move method properties for admin list customisation to ModelAdmin
+---
  Reporter:  Daniel Pope   | Owner:  
brosner
Status:  assigned   | Milestone:  
1.3
 Component:  django.contrib.admin   |   Version:  
SVN
Resolution: |  Keywords:
 
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by alexkoshelev):

 * cc: alexkoshelev (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] #9964: Transaction middleware closes the transaction only when it's marked as dirty

[Django]

#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---+
  Reporter:  ishirav   | Owner:  
mtredinnick 
Status:  assigned  | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
 
Resolution:|  Keywords:  
transactions
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by linuxpoet):

 Replying to [comment:33 andrewsk]:

 Replying to [comment:33 andrewsk]:

 Perhaps I can help. It seems people have made this a lot more complicated
 than it needs to be. There really is zero argument here on how this should
 work. The only argument is implementation.

 If you open a transaction to PostgreSQL, you must close that transaction
 when you are done with it. Either via commit or rollback. In short, if
 your code returns success, commit. If the code returns an exception
 rollback. The only excuse to have an idle transaction is if you are
 processing data within your user layer to send back via the same
 connection. That type of idle transaction is short lived and follows the
 same semantics of success/commit, exception/rollback.

 Anything else is broken. Period. Talk of backward compatibility for a
 broken implementation is ridiculous.

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

[noreply]

Author: Alex
Date: 2010-10-26 13:44:11 -0500 (Tue, 26 Oct 2010)
New Revision: 14358

Modified:
   django/trunk/docs/intro/tutorial04.txt
Log:
Corrected some typos in the tutorial, thanks to Brandon Height for the report.

Modified: django/trunk/docs/intro/tutorial04.txt
===
--- django/trunk/docs/intro/tutorial04.txt  2010-10-26 18:11:22 UTC (rev 
14357)
+++ django/trunk/docs/intro/tutorial04.txt  2010-10-26 18:44:11 UTC (rev 
14358)
@@ -238,16 +238,16 @@
 urlpatterns = patterns('',
 (r'^$',
 ListView.as_view(
-models=Poll,
+model=Poll,
 context_object_name='latest_poll_list',
 template_name='polls/index.html')),
 (r'^(?P\d+)/$',
 DetailView.as_view(
-models=Poll,
+model=Poll,
 template_name='polls/detail.html')),
 url(r'^(?P\d+)/results/$',
 DetailView.as_view(
-models=Poll,
+model=Poll,
 template_name='polls/results.html'),
 name='poll_results'),
 (r'^(?P\d+)/vote/$', 'polls.views.vote'),

-- 
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] r14357 - django/branches/releases/1.2.X/django/views

[noreply]

Author: lukeplant
Date: 2010-10-26 13:11:22 -0500 (Tue, 26 Oct 2010)
New Revision: 14357

Modified:
   django/branches/releases/1.2.X/django/views/defaults.py
Log:
[1.2.X] Fixed #14565 - No csrf_token on 404 pages

Thanks to gvangool for report and patch.

Backport of [14356] from trunk.

Modified: django/branches/releases/1.2.X/django/views/defaults.py
===
--- django/branches/releases/1.2.X/django/views/defaults.py 2010-10-26 
18:09:20 UTC (rev 14356)
+++ django/branches/releases/1.2.X/django/views/defaults.py 2010-10-26 
18:11:22 UTC (rev 14357)
@@ -1,6 +1,8 @@
 from django import http
 from django.template import Context, RequestContext, loader
+from django.views.decorators.csrf import csrf_protect
 
+...@csrf_protect
 def page_not_found(request, template_name='404.html'):
 """
 Default 404 handler.
@@ -13,6 +15,7 @@
 t = loader.get_template(template_name) # You need to create a 404.html 
template.
 return http.HttpResponseNotFound(t.render(RequestContext(request, 
{'request_path': request.path})))
 
+...@csrf_protect
 def server_error(request, template_name='500.html'):
 """
 500 error handler.

-- 
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] r14356 - django/trunk/django/views

[noreply]

Author: lukeplant
Date: 2010-10-26 13:09:20 -0500 (Tue, 26 Oct 2010)
New Revision: 14356

Modified:
   django/trunk/django/views/defaults.py
Log:
Fixed #14565 - No csrf_token on 404 pages

Thanks to gvangool for report and patch.

Modified: django/trunk/django/views/defaults.py
===
--- django/trunk/django/views/defaults.py   2010-10-26 12:32:35 UTC (rev 
14355)
+++ django/trunk/django/views/defaults.py   2010-10-26 18:09:20 UTC (rev 
14356)
@@ -1,6 +1,8 @@
 from django import http
 from django.template import Context, RequestContext, loader
+from django.views.decorators.csrf import csrf_protect
 
+...@csrf_protect
 def page_not_found(request, template_name='404.html'):
 """
 Default 404 handler.
@@ -13,6 +15,7 @@
 t = loader.get_template(template_name) # You need to create a 404.html 
template.
 return http.HttpResponseNotFound(t.render(RequestContext(request, 
{'request_path': request.path})))
 
+...@csrf_protect
 def server_error(request, template_name='500.html'):
 """
 500 error handler.

-- 
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] #14566: Multiple database issue v1.2.3 - Django reading the wrong database

[Django]

#14566: Multiple database issue v1.2.3 - Django reading the wrong database
---+
  Reporter:  stodge| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Old description:

> I have two PostgreSQL (postgresql_psycopg2) databases defined in my
> settings; default and scenes.
>
> If I perform a filter using the 'scenes' DB I get the expected results:
>
> Scene.objects.filter(name__contains='ME').using('scenes')
> [, ]
>
> If I perform a get(), Django seems to get completely confused and appears
> to read the data from the default database:
>
> Scene.objects.get(id=3).using('scenes')
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.6/site-packages/django/db/models/manager.py",
> line 132, in get
> return self.get_query_set().get(*args, **kwargs)
>   File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line
> 336, in get
> num = len(clone)
>   File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line
> 81, in __len__
> self._result_cache = list(self.iterator())
>   File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line
> 269, in iterator
> for row in compiler.results_iter():
>   File "/usr/lib/python2.6/site-
> packages/django/db/models/sql/compiler.py", line 672, in results_iter
> for rows in self.execute_sql(MULTI):
>   File "/usr/lib/python2.6/site-
> packages/django/db/models/sql/compiler.py", line 727, in execute_sql
> cursor.execute(sql, params)
>   File "/usr/lib/python2.6/site-packages/django/db/backends/util.py",
> line 15, in execute
> return self.cursor.execute(sql, params)
>   File "/usr/lib/python2.6/site-
> packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in
> execute
> return self.cursor.execute(query, args)
> DatabaseError: relation "scene" does not exist
> LINE 1: ...le", "scene"."datasets", "scene"."transform" FROM "scene"
> WH...
>

> Anyone else seen this?
>
> Thanks

New description:

 I have two PostgreSQL (postgresql_psycopg2) databases defined in my
 settings; default and scenes.

 If I perform a filter using the 'scenes' DB I get the expected results:
 {{{
 Scene.objects.filter(name__contains='ME').using('scenes')
 [, ]
 }}}
 If I perform a get(), Django seems to get completely confused and appears
 to read the data from the default database:
 {{{
 Scene.objects.get(id=3).using('scenes')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/python2.6/site-packages/django/db/models/manager.py",
 line 132, in get
 return self.get_query_set().get(*args, **kwargs)
   File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line
 336, in get
 num = len(clone)
   File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line
 81, in __len__
 self._result_cache = list(self.iterator())
   File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line
 269, in iterator
 for row in compiler.results_iter():
   File "/usr/lib/python2.6/site-
 packages/django/db/models/sql/compiler.py", line 672, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/usr/lib/python2.6/site-
 packages/django/db/models/sql/compiler.py", line 727, in execute_sql
 cursor.execute(sql, params)
   File "/usr/lib/python2.6/site-packages/django/db/backends/util.py", line
 15, in execute
 return self.cursor.execute(sql, params)
   File "/usr/lib/python2.6/site-
 packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in
 execute
 return self.cursor.execute(query, args)
 DatabaseError: relation "scene" does not exist
 LINE 1: ...le", "scene"."datasets", "scene"."transform" FROM "scene" WH...
 }}}

 Anyone else seen this?

 Thanks

Comment:

 Reformatted description, please use preview.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14566: Multiple database issue v1.2.3 - Django reading the wrong database

[Django]

#14566: Multiple database issue v1.2.3 - Django reading the wrong database
--+-
 Reporter:  stodge|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I have two PostgreSQL (postgresql_psycopg2) databases defined in my
 settings; default and scenes.

 If I perform a filter using the 'scenes' DB I get the expected results:

 Scene.objects.filter(name__contains='ME').using('scenes')
 [, ]

 If I perform a get(), Django seems to get completely confused and appears
 to read the data from the default database:

 Scene.objects.get(id=3).using('scenes')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/python2.6/site-packages/django/db/models/manager.py",
 line 132, in get
 return self.get_query_set().get(*args, **kwargs)
   File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line
 336, in get
 num = len(clone)
   File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line
 81, in __len__
 self._result_cache = list(self.iterator())
   File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line
 269, in iterator
 for row in compiler.results_iter():
   File "/usr/lib/python2.6/site-
 packages/django/db/models/sql/compiler.py", line 672, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/usr/lib/python2.6/site-
 packages/django/db/models/sql/compiler.py", line 727, in execute_sql
 cursor.execute(sql, params)
   File "/usr/lib/python2.6/site-packages/django/db/backends/util.py", line
 15, in execute
 return self.cursor.execute(sql, params)
   File "/usr/lib/python2.6/site-
 packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in
 execute
 return self.cursor.execute(query, args)
 DatabaseError: relation "scene" does not exist
 LINE 1: ...le", "scene"."datasets", "scene"."transform" FROM "scene" WH...


 Anyone else seen this?

 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] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
--+-
  Reporter:  mtredinnick  | Owner:  mtredinnick
Status:  new  | Milestone: 
 Component:  ORM aggregation  |   Version:  SVN
Resolution:   |  Keywords: 
 Stage:  Accepted | Has_patch:  1  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by Alex):

 The patch looks like it's probably correct (I'll need to think more to be
 sure), however I'm concerned about the tests, they poke at some pretty
 deep internals.  I'd prefer if we tested this by just looking at the SQL
 (as some of the other tests like this do).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  brunobraga
Status:  assigned  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by Kronuz):

 Replying to [comment:62 brunobraga]:
 > Additionally, the newest django 1.2.3 (which has been put to the
 official Ubuntu repository 10.10) requires modification in the patch in
 order to work properly. As soon as we receive a positive message from
 committers, we can work on updating it to add to the main stream code.
 >
 > Thank you,
 brunobraga, please, what modifications does it need? because the patch
 applies fine on django tagged 1.2.3

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

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

Re: [Django] #2626: Datetime handling is broken when dealing with more than one time zone

[Django]

#2626: Datetime handling is broken when dealing with more than one time zone
-+--
  Reporter:  Tom Tobin   | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jedie):

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

-- 
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] #2626: Datetime handling is broken when dealing with more than one time zone

[Django]

#2626: Datetime handling is broken when dealing with more than one time zone
-+--
  Reporter:  Tom Tobin   | Owner:  jedie
Status:  assigned| Milestone:   
 Component:  Core framework  |   Version:   
Resolution:  |  Keywords:   
 Stage:  Accepted| Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by chrischambers):

 * cc: chrischambers (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] #14565: No csrf_token on 404 pages

[Django]

#14565: No csrf_token on 404 pages
+---
  Reporter:  gvangool   | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:  csrf  
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gvangool):

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

Comment:

 Note that it's fixed the same way as #12358.

-- 
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] #14565: No csrf_token on 404 pages

[Django]

#14565: No csrf_token on 404 pages
---+
 Reporter:  gvangool   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords:  csrf   |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 You can't use % csrf_token % on a 404 page.

 I've also posted this on [http://groups.google.com/group/django-
 developers/browse_thread/thread/86898adc8c9573ee# django-developers].

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

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

Re: [Django] #14491: ability to place inlines between fieldsets in admin

[Django]

#14491: ability to place inlines between fieldsets in admin
-+--
  Reporter:  massivefu...@gmail.com  | Owner:  nobody
Status:  new | Milestone:
 Component:  django.contrib.admin|   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

  * needs_better_patch:  => 0
  * component:  Uncategorized => django.contrib.admin
  * needs_tests:  => 0
  * needs_docs:  => 0

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

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

[Django] #14564: case insensitive unique_together

[Django]

#14564: case insensitive unique_together
---+
 Reporter:  anonymous  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Should it be possible to specify a case insensitive match for unique-
 together fields? I have a field I'm using for abbreviations of index terms
 in a library catalogue, and it would be helpful to constrain new additions
 to be unique without regard to case.

 replicate -

 1. Create a model with a slugfield
 2. Add a unique_together constraint on it
 3. Add items with field set to "A" and "a" without an error (although
 obviously sometime this is the desired behaviour)

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

[noreply]

Author: gabrielhurley
Date: 2010-10-26 07:32:35 -0500 (Tue, 26 Oct 2010)
New Revision: 14355

Modified:
   django/trunk/docs/howto/static-files.txt
Log:
Fixed #14562 -- corrected a typo in the static-files howto. Thanks to stephaner 
for the report and patch.

Modified: django/trunk/docs/howto/static-files.txt
===
--- django/trunk/docs/howto/static-files.txt2010-10-26 01:16:22 UTC (rev 
14354)
+++ django/trunk/docs/howto/static-files.txt2010-10-26 12:32:35 UTC (rev 
14355)
@@ -26,7 +26,7 @@
 ``django.contrib.staticfiles`` will look very familiar. That's because
 they're essentially the same code: ``django.contrib.staticfiles`` started
 its life as `django-staticfiles`_ and was merged into Django 1.3.
-
+
 If you're upgrading from ``django-staticfiles``, please see `Upgrading from
 django-staticfiles`_, below, for a few minor changes you'll need to make.
 
@@ -252,7 +252,7 @@
 
 Below, and in the following sections, we'll show off a few example fabfiles
 (i.e. Fabric scripts) that automate these media deployment options. The syntax
-of a fabfile is fairly streightforward but won't be covered here; consult
+of a fabfile is fairly straightforward but won't be covered here; consult
 `Fabric's documentation`__, for a complete explanation of the syntax..
 
 __ http://docs.fabfile.org/
@@ -385,14 +385,14 @@
 * The settings ``STATICFILES_PREPEND_LABEL_APPS``,
   ``STATICFILES_MEDIA_DIRNAMES`` and ``STATICFILES_EXCLUDED_APPS`` were
   removed.
-  
+
 * The setting ``STATICFILES_RESOLVERS`` was removed, and replaced by the 
new
   :setting:`STATICFILES_FINDERS`.
-  
+
 * The default for :setting:`STATICFILES_STORAGE` was renamed from
   ``staticfiles.storage.StaticFileStorage`` to
   ``staticfiles.storage.StaticFilesStorage``
-  
+
 Learn more
 ==
 

-- 
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] #14563: Add Turkey to localflavors

[Django]

#14563: Add Turkey to localflavors
-+--
  Reporter:  serkank | Owner:  serkank
Status:  new | Milestone:  1.3
 Component:  django.contrib.localflavor  |   Version:  1.2
Resolution:  |  Keywords:  turkey 
 Stage:  Unreviewed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by serkank):

  * owner:  anonymous => serkank
  * status:  assigned => new

Comment:

 Replying to [comment:1 anonymous]:

-- 
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] #14563: Add Turkey to localflavors

[Django]

#14563: Add Turkey to localflavors
-+--
  Reporter:  serkank | Owner:  anonymous
Status:  assigned| Milestone:  1.3  
 Component:  django.contrib.localflavor  |   Version:  1.2  
Resolution:  |  Keywords:  turkey   
 Stage:  Unreviewed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

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

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

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

[Django]

#14563: Add Turkey to localflavors
+---
 Reporter:  serkank |   Owner:  nobody
   Status:  new |   Milestone:  1.3   
Component:  django.contrib.localflavor  | Version:  1.2   
 Keywords:  turkey  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 I have prepared localflavors for Turkey. The form helpers include
 TRZipCodeField, TRPhoneNumberField, TRIdentificationNumberField and
 TRProvinceSelect.
 Please apply the attached 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] #9964: Transaction middleware closes the transaction only when it's marked as dirty

[Django]

#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---+
  Reporter:  ishirav   | Owner:  
mtredinnick 
Status:  assigned  | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
 
Resolution:|  Keywords:  
transactions
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by danfairs):

 * cc: danfairs (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] #8391: slugify template filter poorly encodes non-English strings

[Django]

#8391: slugify template filter poorly encodes non-English strings
-+--
  Reporter:  bjornkri| Owner:  nobody
Status:  reopened| Milestone:
 Component:  Template system |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by hejsan):

 * cc: hr.bjarni+dja...@gmail.com (added)

Comment:

 Hi, this ticket is way to old for a trivial feature (for non-English-
 speaking-country based programmers).

 When slugifying characters in my language, some of them are properly
 downgraded to ascii lookalikes but some of them get lost. That's pretty
 irritating for such a trivial feature.

 There seems to be a consensus in other web frameworks on slugifying
 international characters, and that is to have a map.

 Did you (core programmers) take a look at harkal's suggestion above? This
 is the way i.e. WordPress and others go about solving this problem.
 I also found this ready made function: [http://trac.django-
 fr.org/browser/site/trunk/project/links/slughifi.py?rev=47 slughify]

 It is small, concise and it works.

 If you decide you don't want/need to fix/upgrade the slugify function, or
 if you think it will take a very long time before you decide, then I'd
 like to suggest that it be made into a setting as soon as possible:
 SLUGIFY_FUNCTION = myown_slugify

 with django.template.defaultfilters.slugify as the default

 But optimally the function provided by django should work for all
 languages in my opinion.

 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] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

[Django]

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
---+
  Reporter:  Leo   | Owner:  Leo
Status:  assigned  | Milestone:  1.3
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by sirex):

 Same here. Instead of getting normal form validation error, I getting
 unhandled exception, what leads to 500 error.

 Why this error is not already 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] #14507: Static file serving is broken after rev 14293

[Django]

#14507: Static file serving is broken after rev 14293
-+--
  Reporter:  mbi | Owner:  jezdez  
Status:  closed  | Milestone:  1.3 
 Component:  Core framework  |   Version:  1.2 
Resolution:  fixed   |  Keywords:  static, static_serve
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by jnns):

 I'm sorry for reopening the ticket. It seemed apropriate as this behaviour
 has nothing to do with a missing context_processor but with this specific
 commit. All previous commits work fine and following commits cause a
 KeyError rather than an ImproperlyConfigured Exception which is what this
 Changeset was about, no?

 Sorry again.

-- 
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] #14562: Typo streightforward

[Django]

#14562: Typo streightforward
---+
 Reporter:  stephaner  |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Typo in word "streightforward".

-- 
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] #11900: commit_on_success: Handle Exception in commit()

[Django]

#11900: commit_on_success: Handle Exception in commit()
---+
  Reporter:  guettli   | Owner:  
gabrielhurley
Status:  closed| Milestone:  1.2
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:  fixed |  Keywords: 
  
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by guettli):

 * cc: h...@tbz-pariv.de (removed)

-- 
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] #14559: Minor docstring corrections

[Django]

#14559: Minor docstring corrections
+---
  Reporter:  gabrielhurley  | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by wogan):

  * stage:  Unreviewed => Ready for checkin

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #11010: Add a foundation for rowlevel permissions in Django

[Django]

#11010: Add a foundation for rowlevel permissions in Django
+---
  Reporter:  apollo13   | Owner:  jezdez
Status:  closed | Milestone:  1.2   
 Component:  Authentication |   Version:  SVN   
Resolution:  fixed  |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by guettli):

 * cc: h...@tbz-pariv.de (removed)

-- 
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] #10758: sys.exc_info() should not be stored on a local variable

[Django]

#10758: sys.exc_info() should not be stored on a local variable
+---
  Reporter:  piotr.findei...@azouk.com  | Owner:  lukeplant
Status:  closed | Milestone:   
 Component:  HTTP handling  |   Version:  SVN  
Resolution:  fixed  |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by guettli):

 * cc: h...@tbz-pariv.de (removed)

-- 
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] #10880: Link to 1.0 docs has two trailing slashes

[Django]

#10880: Link to 1.0 docs has two trailing slashes
--+-
  Reporter:  guettli  | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Django Web site  |   Version:  1.0   
Resolution:  fixed|  Keywords:
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by guettli):

 * cc: h...@tbz-pariv.de (removed)

-- 
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] #10355: add support for email backends

[Django]

#10355: add support for email backends
---+
  Reporter:  wkornewald| Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  django.core.mail  |   Version:  1.0   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by guettli):

 * cc: h...@tbz-pariv.de (removed)

-- 
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] #9103: django.contrib.admin is not listed on http://docs.djangoproject.com/en/dev/modindex/

[Django]

#9103: django.contrib.admin is not listed on
http://docs.djangoproject.com/en/dev/modindex/
--+-
  Reporter:  guettli  | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Django Web site  |   Version:  1.0   
Resolution:  fixed|  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by guettli):

 * cc: h...@tbz-pariv.de (removed)

-- 
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] #7282: Integrated ldap for contrib.auth

[Django]

#7282: Integrated ldap for contrib.auth
-+--
  Reporter:  programmerq | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Contrib apps|   Version:  SVN   
Resolution:  wontfix |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  1   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by guettli):

 * cc: h...@tbz-pariv.de (removed)

-- 
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] #7282: Integrated ldap for contrib.auth

[Django]

#7282: Integrated ldap for contrib.auth
-+--
  Reporter:  programmerq | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Contrib apps|   Version:  SVN   
Resolution:  wontfix |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  1   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by guettli):

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

Comment:

 Like #2507 this feature can live outside of django.

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

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

Re: [Django] #13731: Missing docs how to emulate "ON DELETE SET NULL"

[Django]

#13731: Missing docs how to emulate "ON DELETE SET NULL"
+---
  Reporter:  guettli| Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

 * cc: h...@tbz-pariv.de (removed)

-- 
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] #10899: easier manipulation of sessions by test client

[Django]

#10899: easier manipulation of sessions by test client
+---
  Reporter:  tallfred   | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by russellm):

 I think the patch is on the right track. The currently documented behavior
 needs to continue to work for backwards compatibility purposes, but I
 don't see the proposed behavior affecting that.

 I have two comments on the patch:

 Firstly, can the call to _session_save() be pushed further down the stack
 into request()? That would removes some code duplication, and I can't see
 any obvious reason why it wouldn't work the same (feel free to prove me
 wrong!)

 Secondly, there is some loss of cookie properties from the login method.
 This needs to be checked to make sure there aren't any backwards
 incompatible changes to the way the login cookie is being set during
 testing.

 Regarding docs -- you're correct that this new behavior is less explicit,
 so explaining exactly how and when the session is persisted will be an
 important thing to explain well.

-- 
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] #9964: Transaction middleware closes the transaction only when it's marked as dirty

[Django]

#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---+
  Reporter:  ishirav   | Owner:  
mtredinnick 
Status:  assigned  | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
 
Resolution:|  Keywords:  
transactions
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by Tuxie):

 I'm not a Django user but I am a PostgreSQL DBA and I must say that I'm
 fascinated by how you have handled this bug. Still open after 11 months
 because people are actually defending leaving dangling transactions? Just
 wow!

 These dangling transactions will prevent the autovacuum daemon from doing
 its job, writes will slow to a crawl after a while and tables will just
 grow and grow, never being able to reuse the disk space after previous
 deletes and updates.

 Always COMMIT, ROLLBACK or disconnect after starting a transaction or
 never open the transaction in the first place. The current behaviour is
 not an optimization, it has serious performance implications for apps with
 any amount of regular writes, so bad it practically makes
 Django+PostgreSQL unusable for any long running dynamic applications of
 non-trivial size.

-- 
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] #9964: Transaction middleware closes the transaction only when it's marked as dirty

[Django]

#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---+
  Reporter:  ishirav   | Owner:  
mtredinnick 
Status:  assigned  | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
 
Resolution:|  Keywords:  
transactions
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by andrewsk):

 * cc: andrewsk (added)

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

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

Re: [Django] #9964: Transaction middleware closes the transaction only when it's marked as dirty

[Django]

#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---+
  Reporter:  ishirav   | Owner:  
mtredinnick 
Status:  assigned  | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
 
Resolution:|  Keywords:  
transactions
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by shai):

 Replying to [comment:31 Xof]:
 >
 > The current behavior is not a documented, reliable behavior
 >

 This is not exactly accurate; the current behavior w.r.t. "modifying
 without telling Django" is in fact
 [http://docs.djangoproject.com/en/1.2/topics/db/sql/#transactions-and-raw-
 sql documented]. Granted, this is one piece of documentation I will be all
 for removing.

 >
 > behavior that we need to continue to support.
 >

 The change has performance implications. Of course, performance is not a
 "documented behavior", but it is not behavior you're free to modify at
 will either. I grant you that the performance implications are unclear,
 and doing the right thing may actually perform better in most places where
 it matters (though evidence for this should be provided); I also agree
 that, if forced to choose, the correctness considerations outweigh the
 performance issues here by far.

 I was just not convinced that forcing this choice is the best option.

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