[Django] #13695: Django Comments Loses Ajax Headers When Redirecting (request.is_ajax() === True --> request.is_ajax() === False)

[Django]

#13695: Django Comments Loses Ajax Headers When Redirecting (request.is_ajax() 
===
True --> request.is_ajax() === False)
---+
 Reporter:  jacobstr   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 If you redirect what was originally a request that:

 request.is_ajax() === True

 On the redirected page

 request.is_ajax() === False

 IMHO It should retain the Ajax headers. In my particular use case I'm
 submitting to django.contrib.comments via an ajax submission. I'm also
 providing the `next` parameter, hoping that my custom view can respond
 differently depending on whether or not the original form posting was Ajax
 or not (i.e. the comment form gracefully degrades to a non-ajax version if
 your js is borken). Unfortunately, the request never shows up as an Ajax
 request.

-- 
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] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+--
  Reporter:  svetlyak40wt| Owner:  nobody   

Status:  new | Milestone:  1.3  

 Component:  Core framework  |   Version:  1.0  

Resolution:  |  Keywords:  model inheritance, 
signals, dispatch, proxy, subclass
 Stage:  Accepted| Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

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

 * cc: DrMeers (added)
  * keywords:  model inheritance, signals, dispatch => model inheritance,
   signals, dispatch, proxy, subclass
  * milestone:  => 1.3

Comment:

 Same problem with proxy models

-- 
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] #10284: ModelFormSet - objects are deleted even if commit=False

[Django]

#10284: ModelFormSet - objects are deleted even if commit=False
-+--
  Reporter:  laureline.gue...@makina-corpus.org  | Owner:  
nobody
Status:  new | Milestone:   
 
 Component:  Forms   |   Version:  SVN  
 
Resolution:  |  Keywords:   
 
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  1   |   Needs_tests:  1
 
Needs_better_patch:  0   |  
-+--
Changes (by Wedg):

  * needs_docs:  0 => 1
  * version:  1.0 => SVN

Comment:

 So... hopefully I did this right. The current trunk fails the regression
 test (deletes the model even though commit=False), but with the patch
 applied it passes. Please let me know if I need to make any
 corrections/whatever. :D

 Oh, and I'll try to get a doc patch for the behavior too, unless someone
 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.

[Changeset] r13318 - django/trunk/django/core/handlers

[noreply]

Author: lukeplant
Date: 2010-06-03 13:50:04 -0500 (Thu, 03 Jun 2010)
New Revision: 13318

Modified:
   django/trunk/django/core/handlers/base.py
Log:
Fixed #10758 - sys.exc_info() should not be stored on a local variable

Thanks piotr.findeisen for report, kevinh for patch.


Modified: django/trunk/django/core/handlers/base.py
===
--- django/trunk/django/core/handlers/base.py   2010-06-02 23:49:27 UTC (rev 
13317)
+++ django/trunk/django/core/handlers/base.py   2010-06-03 18:50:04 UTC (rev 
13318)
@@ -137,9 +137,8 @@
 raise
 except: # Handle everything else, including SuspiciousOperation, 
etc.
 # Get the exception info now, in case another exception is 
thrown later.
-exc_info = sys.exc_info()
 receivers = 
signals.got_request_exception.send(sender=self.__class__, request=request)
-return self.handle_uncaught_exception(request, resolver, 
exc_info)
+return self.handle_uncaught_exception(request, resolver, 
sys.exc_info())
 finally:
 # Reset URLconf for this thread on the way out for complete
 # isolation of request.urlconf

-- 
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] #56: MySQL id columns should be UNSIGNED

[Django]

#56: MySQL id columns should be UNSIGNED
---+
  Reporter:  Manuzhai    | Owner:  
glassresistor
Status:  new   | Milestone:  1.3
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  mysql  
  
 Stage:  Design decision needed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by ssspiochld):

 The patch from http://code.djangoproject.com/ticket/1500 extended the byte
 size of field
 used for AutoField (mediumint->int) however by omitting UNSIGNED field
 from definition the id-space
 is not used in the most efficient way.  More about the MySQL field
 definitions and id-space can be found at
 http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

 By applying the patch two profits are met (thats what tests in
 test_proj.zip check):
  - negative values (invalid) for AutoField wont be permitted
  - the usable id-space will become exceeded two times (from 2**31 to
 2**32)

-- 
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] #13400: model.DoesNotExist exception raised by QuerySet.get() should include the same nice description of parameters that the MultipleObjectsReturned exception does.

[Django]

#13400: model.DoesNotExist exception raised by QuerySet.get() should include the
same nice description of parameters that the MultipleObjectsReturned
exception does.
---+
  Reporter:  aaron | Owner:  trentm 
 
Status:  new   | Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version: 
 
Resolution:|  Keywords:  
model.DoesNotExist, ObjectDoesNotExist, QuerySet.get error message kwargs 
parameters
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Changes (by adamnelson):

  * needs_better_patch:  0 => 1

Comment:

 Noting that patch needs improvement, as per Trentm

-- 
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] #5663: markdown 1.6b unicodedecodeerror

[Django]

#5663: markdown 1.6b unicodedecodeerror
---+
  Reporter:  Koen Biermans   | 
Owner:  
Status:  closed| 
Milestone:  
 Component:  Contrib apps  |   
Version:  SVN 
Resolution:  wontfix   |  
Keywords:  markdown
 Stage:  Accepted  | 
Has_patch:  1   
Needs_docs:  0 |   
Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by adamnelson):

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

Comment:

 Markdown is now in the 2 series, which ships with Ubuntu Lucid, and the
 unicode issue was fixed 2 years ago - I think this ticket is no longer
 applicable.  Reopen if that's not the 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] #5425: Incorrect plurals in admin pagination template

[Django]

#5425: Incorrect plurals in admin pagination template
+---
  Reporter:  Petr Marhoun   | Owner:  
nobody 
Status:  reopened   | Milestone:
 
 Component:  django.contrib.admin   |   Version:
 
Resolution: |  Keywords:  
admin, internationalization
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  1  |  
+---
Changes (by adamnelson):

  * needs_better_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] #5416: Add assertNumQueries() to testing framework

[Django]

#5416: Add assertNumQueries() to testing framework
+---
  Reporter:  adrian | Owner:  alexkoshelev   
Status:  assigned   | Milestone: 
 Component:  Testing framework  |   Version:  SVN
Resolution: |  Keywords:  feature_request
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  1  |  
+---
Changes (by adamnelson):

  * needs_better_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] #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:  assigned   | Milestone:   
 Component:  HTTP handling  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by Alex):

 err, looks like not.  FWIW there's no potential for a memory leak here,
 the GC will eventually reclaim this memory.

-- 
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:  assigned   | Milestone:   
 Component:  HTTP handling  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by Alex):

 Maybe not actually... , I'm not totally sure.

-- 
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:  assigned   | Milestone:   
 Component:  HTTP handling  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by Alex):

 This patch isn't technically correct IMO, if an exception is raised in
 that signal, at any poinit, exc_info() will return that exception's info I
 think.

-- 
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:  assigned   | Milestone:   
 Component:  HTTP handling  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by lukeplant):

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

Comment:

 Tests for this are probably going to be very hard or very fragile, so I'll
 commit without tests, given that you say this is causing real world
 problems.  I'll it as "except:" for reasons of possible legacy libraries,
 as already noted.

-- 
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] #13694: SafeMIMEText argument names incompatible with those from MIMEText

[Django]

#13694: SafeMIMEText argument names incompatible with those from MIMEText
--+-
 Reporter:  davenaff  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.core.mail  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 This has the impact of breaking legacy calls that used the argument names
 to assign a value.  For example:

 txt=SafeMIMEText(message, _subtype ='plain', _charset=charset)

-- 
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] #13693: error_messages for fields in Model don't carry over to ModelForm

[Django]

#13693: error_messages for fields in Model don't carry over to ModelForm
---+
 Reporter:  Aleks  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  1.2   
 Keywords:  error_messages, forms, models  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 When having the optional error_messages parameter added to a field for
 some model, the errors don't get carried over to a ModelForm using that
 Model. For example:

 MODEL:


 {{{
 class Contact(models.Model):

 ...

 first_name = models.CharField(max_length=30, verbose_name=u"first
 name", error_messages={'required':'A contact needs a first name.'})

 ...

 }}}


 FORM:


 {{{
 class ContactQuickAddForm(ModelForm):
 class Meta:
 model = Contact
 fields = ["first_name" ... ]

 }}}

 When validating, the error message doesn't change and it's default is
 shown: "this field is required."

 A workaround (thanks to subsume on IRC) is to override your ModelForm's
 __init__.


 {{{
 def __init__(self,*args,**kwargs):
  super(ContactQuickAddForm,self).__init__(*args,**kwargs)
  self.fields['first_name'].error_messages = {'required':
 'FAS:DJFASKL:DJF'}
 }}}

-- 
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] #9015: Signal Connection Decorators

[Django]

#9015: Signal Connection Decorators
-+--
  Reporter:  zvoase  | Owner:  brosner
Status:  assigned| Milestone: 
 Component:  Core framework  |   Version:  SVN
Resolution:  |  Keywords:  signals
 Stage:  Accepted| Has_patch:  1  
Needs_docs:  1   |   Needs_tests:  1  
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

 * cc: john+djangoproj...@sneeu.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] #494: Collapse in admin interface for inline related objects

[Django]

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

  * needs_better_patch:  0 => 1

Comment:

 In that case, reverting needs_better_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] #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:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kevinh):

 "Off the top of my head - if there's a delay in the gc collecting the
 cycle and you get a few tracebacks it could spike the memory usage of the
 process and if it's python 2.4 it could result in that memory not being
 freed resulting in it looking like a memory leak?"

 Yes we are seeing this in production, though with python 2.5.  It only
 occurs under heavy load (we get around 10 million page views/month), and
 only if we push pages out that throw 500 errors.  Though it is fairly
 consistent.

 "As for the memory-leak, I really would like to see some tests, that cause
 it. AFAIK, the cycle will be garbage collected by Python sooner or later."

 I would love to see some tests too.  Though this is beyond me.

-- 
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] #12359: db/models/fields/related.py hardcodes m2m help_text for select widget

[Django]

#12359: db/models/fields/related.py hardcodes m2m help_text for select widget
+---
  Reporter:  olau   | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by crucialfe...@gmail.com):

 +1 : its not the domain of the database field

 but trey says above that it should be the admin that does it.  IMO it
 should be the widget that adds advice as to how to operate its own widget.
 it should never be assumed that the admin is present

-- 
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] #13691: install instructions are unclear about creation of db tables

[Django]

#13691: install instructions are unclear about creation of db tables
+---
  Reporter:  webcomm| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by webcomm):

 I was seeing this...

 no such table: django_session

 I wish I could tell you exactly when I saw that.  It may be that my
 workflow was a little unusual, but I'm not sure.

 The "Get Your Database Running" section was confusing to me.  I wanted to
 use sqlite3, since that seems to be the easiest way to get started in the
 dev server and that's what I had remembered using in past experiments with
 Django.  Under sqlite3, the instructions say "you don't need to do
 anything extra" but I wasn't sure what "extra" was in relation to.  In
 fact, it turns out I didn't need to do *anything* to get the db running,
 in the case of sqlite3, but I don't think the instructions give that
 impression.  The instructions seem to assume that the user knows to create
 a flat file to hold the db, and that beyond that there is nothing to run,
 per se.  None of this is very explicit in the instructions.

 I found installing the code pretty easy this time around.  I think when I
 got the message about "no such table: django_session" was after running
 manage.py runserver.

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

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

Re: [Django] #494: Collapse in admin interface for inline related objects

[Django]

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

 For the record (and I thought I'd left this comment before, but apparently
 not) I'm opposed to formsets having some knowledge of "classes", there's
 no precedent for it in the forms API, and it further munges the output
 with the server side issues.

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

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

Re: [Django] #494: Collapse in admin interface for inline related objects

[Django]

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

  * needs_better_patch:  1 => 0

Comment:

 The patch itself seems to satisfy people's comments, but tests are still
 needed.

-- 
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] #13691: install instructions are unclear about creation of db tables

[Django]

#13691: install instructions are unclear about creation of db tables
+---
  Reporter:  webcomm| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

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

Comment:

 But...you don't have to create the tables. That's what syncdb does, and
 it's generally expected you'll use syncdb unless you have pre-existing
 tables that you are looking to access via Django. So manually creating the
 tables as part of installation of the DB is not at all the expected
 workflow: either you'll have them already, or you'll use syncdb to create
 them. Perhaps if you explained exactly what snag you ran into we'd have a
 better idea of how to improve the doc.

-- 
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] #13692: Wrong ORM in complex filter

[Django]

#13692: Wrong ORM in complex filter
---+
 Reporter:  myneur |   Owner:
   Status:  new|   Milestone:
Component:  ORM aggregation| Version:  1.1   
 Keywords:  filter, Q objects  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 == With Models: ==
 {{{
 class Professional(models.Model):
 hits = models.PositiveIntegerField()

 class Article(models.Model):
 hits = models.PositiveIntegerField()
 authors = models.ManyToManyField(Professional)

 class Query(models.Model):
 hits = models.PositiveIntegerField()
 author = models.ForeignKey(Professional, blank = True, null =
 True)
 }}}
 == A Query: ==
 {{{
 Professional.objects.annotate(article_hits=Sum("article__hits"),
 query_hits=Sum("query__hits")).exclude(Q(article_hits=None)(query_hits=None))
 }}}
 Produces exactly the same SQL as:
 {{{
 ...exclude(Q(article_hits=None)|Q(advice_hits=None))
 ...filter(Q(article_hits=None)(advice_hits=None))
 ...filter(Q(article_hits=None)|Q(advice_hits=None))
 }}}

 All of these queries produces a SQL with exactly the same last clause:
 {{{
  HAVING (SUM("articles_article"."hits") IS NULL AND
 SUM("solutions_query"."hits") IS NULL)
 }}}
 It doesn't respond to filter/exclude or &| operator.

 (and also the result is the same)

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

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

[Django] #13691: install instructions are unclear about creation of db tables

[Django]

#13691: install instructions are unclear about creation of db tables
---+
 Reporter:  webcomm|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The installation guide at
 http://docs.djangoproject.com/en/1.2/topics/install/#get-your-database-
 running  doesn't tell you that you need to create database tables as part
 of the install (if you want to use a database).  The closest it comes is
 when it says "If you plan to use Django’s manage.py syncdb command to
 automatically create database tables...".  But that statement is
 meaningless to people who are new to Django.  Unless I'm missing
 something, there is nothing in the instructions to tell you that creating
 the tables is a required step (for anyone who wants to use a database).

-- 
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] #12323: add support for STATIC_URL and STATIC_ROOT

[Django]

#12323: add support for STATIC_URL and STATIC_ROOT
-+--
  Reporter:  nagyv   | Owner:  nobody   
   
Status:  new | Milestone:   
   
 Component:  Core framework  |   Version:   
   
Resolution:  |  Keywords:  settings, media_url, 
media_root, static_url, static_root
 Stage:  Accepted| Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Comment (by jezdez):

 I've also started to implement a slightly different approach that was
 discussed at the DjagnoCon Europe sprint at
 http://github.com/jezdez/django/tree/staticfiles

-- 
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:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Skaffen):

 Off the top of my head - if there's a delay in the gc collecting the cycle
 and you get a few tracebacks it could spike the memory usage of the
 process and if it's python 2.4 it could result in that memory not being
 freed resulting in it looking like a memory leak?

 Regardless of whether it's demonstrable as a cause of a memory leak, the
 python documentation surrounding the sys.exc_info/local variable reference
 cycle says "Beginning with Python 2.2, such cycles are automatically
 reclaimed when garbage collection is enabled and they become unreachable,
 but it remains more efficient to avoid creating cycles." - i.e. to me it
 suggests avoiding such cycles where possible, and as it seems a simple
 change in the code to avoid that cycle in this case then even if there's
 no test case proving a memory leak it would seem worthy to improve the
 code to make it more efficient. Perhaps a regression test (if one doesn't
 exist for that section of code) would be sufficient for that change?

 This is, of course, separate from the question of whether the exception
 handling should just catch exceptions derived from BaseException - I don't
 think that should be in this ticket as although it's the same area of code
 it's a different issue (and I'm not sure a strong case has been made for
 why just things derived from BaseException should be caught - is there
 actually a problem?).

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

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

Re: [Django] #7993: Admin complains about a missing field even if it is not missing

[Django]

#7993: Admin complains about a missing field even if it is not missing
---+
  Reporter:  kratorius | Owner:  nobody 

Status:  closed| Milestone: 

 Component:  django.contrib.admin  |   Version:  SVN

Resolution:  invalid   |  Keywords:  admin, 
improperlyconfigured
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 Replying to [comment:2 batiste]:
 > That would be still useful to be able to display the field in the admin.
 Maybe in a disabled input, ie: 

 This is possible now (new in 1.2) with
 
[http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.readonly_fields
 readonly fields] in the admin, though it does not actually used disabled
 inputs.

-- 
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] #7993: Admin complains about a missing field even if it is not missing

[Django]

#7993: Admin complains about a missing field even if it is not missing
---+
  Reporter:  kratorius | Owner:  nobody 

Status:  closed| Milestone: 

 Component:  django.contrib.admin  |   Version:  SVN

Resolution:  invalid   |  Keywords:  admin, 
improperlyconfigured
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 That would be still useful to be able to display the field in the admin.
 Maybe in a disabled input, ie: 

-- 
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] #13690: django admin use 102 SQL querys when i set the permission of a user!

[Django]

#13690: django admin use 102 SQL querys when i set the permission of a user!
---+
  Reporter:  lsc20051...@163.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 |  
---+
Comment (by lsc20051426):

 ok,I have submit it .
 BTW ,i register an user for attaching a jpg.
 3Q.

-- 
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:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by lrekucki):

 The real problem with exception handling is that older versions of Python
 allowed any object to be raised as an exception. Python 2.5 still allows
 raising strings, see:
 http://docs.python.org/release/2.5.4/whatsnew/pep-352.html. While no one
 sane, would write new code that does that, I can imagine working with some
 legacy libraries.

 As for the memory-leak, I really would like to see some tests, that cause
 it. AFAIK, the cycle will be garbage collected by Python sooner or later.

-- 
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] #13690: django admin use 102 SQL querys when i set the permission of a user!

[Django]

#13690: django admin use 102 SQL querys when i set the permission of a user!
---+
  Reporter:  lsc20051...@163.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 d0ugal):

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

Comment:

 I think you intended to add file to this ticket - but there isn't one.
 Also, can you provide the code or more explication about this problem.

 At present we have very little to go on and depending what your doing it
 may be the expected 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.

Re: [Django] #13541: Proposition to add a humanized date diff template filter

[Django]

#13541: Proposition to add a humanized date diff template filter
---+
  Reporter:  batiste   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Contrib apps  |   Version:  1.1   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by batiste):

 I renamed the filter in fuzzy_date because it describe it in a more
 appropriate way. And now it also handle future dates:

 http://github.com/batiste/date-diff

 I believe the use case is a little more different than with the timeslice.
 Timeslice provide a quite precise time difference. And it doesn't work for
 a date in the future (although it should be easy to add).

 I am not gonna argue more about this feature if nobody else need something
 like that.

 Cheers,
 Batiste

-- 
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] #13690: django admin use 102 SQL querys when i set the permission of a user!

[Django]

#13690: django admin use 102 SQL querys when i set the permission of a user!
--+-
 Reporter:  lsc20051...@163.com   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 django admin use 102 SQL querys when I set the permissions for a user!
 see the picture !

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