Re: [Django] #9376: Support initial values for clean() not just for FileField

[Django]

#9376: Support initial values for clean() not just for FileField
-+--
  Reporter:  aszlig  | Owner:  nobody 
Status:  closed  | Milestone: 
 Component:  Forms   |   Version:  SVN
Resolution:  wontfix |  Keywords:  form fields
 Stage:  Unreviewed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

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

Comment:

 !FileFields are a special case where the HTML widget doesn't render any
 initial value, so we have to handle them specially. All other HTML form
 fields render initial values without problems, so they're different at
 that level.

 This seems like an edge case and it's easy enough to implement it in a
 custom form field (just override `__init__` and wipe out the value of
 `self.initial`), so I don't think it's worth adding to Django's core.

 Thanks for the patch anyway (in future, though, a patch like this would
 also need tests and documentation to explain 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-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9376: Support initial values for clean() not just for FileField

[Django]

#9376: Support initial values for clean() not just for FileField
-+--
 Reporter:  aszlig   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Forms| Version:  SVN   
 Keywords:  form fields  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 hi,

 i appended a patch that adds a sneaky_initial attribute for custom form
 fields
 (and for FileField, too) so that it is possible to write form fields/model
 fields that contain values that could only be changed by submitting a new
 value
 but to change them ad-hoc.

 a! :-)

 PS: a better name for the attr except "sneaky_initial" would be great :-D

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

[Django] #9375: Minor Documentation Suggestion (Serialization Page)

[Django]

#9375: Minor Documentation Suggestion (Serialization Page)
---+
 Reporter:  jordy  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 You might consider adding a link to the "dumpdata" command to the
 serialization page.

 The page:
 http://docs.djangoproject.com/en/dev/topics/serialization/

 A potential link:
 http://docs.djangoproject.com/en/dev/ref/django-admin/#dumpdata

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

[Django] #9374: Minor punctuation - Missing Closing Paren

[Django]

#9374: Minor punctuation - Missing Closing Paren
---+
 Reporter:  jordy  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 There's a line in the docs that's missing a closing parenthesis.

 Here's the page (and anchor):
 http://docs.djangoproject.com/en/dev/topics/serialization/#serializing-
 data

 Here's the line:
 "This is useful if you want to serialize data directly to a file-like
 object (which includes an HttpResponse"

 Patch: Add closing parenthesis.  ;)

 PS - Django rules!

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

Re: [Django] #3615: Can't define forward references in fixtures using MySQL with InnoDB

[Django]

#3615: Can't define forward references in fixtures using MySQL with InnoDB
---+
  Reporter:  russellm  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  mysql 
innodb myisam reference fixture
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 Replying to [comment:4 matthew]:
 > Ummm, I might be crazy but is this really an issue?

 Yes - it is. Think of circular references: a refers to b, and b refers to
 a. There is no order that you can use for that fixture that will will not
 have a forward reference.

 Even if there wasn't the circular reference problem, there is the issue
 that Django doesn't roll out fixtures so as to avoid forward references -
 i.e., even if there is a clear order that will work, Django doesn't
 attempt to discover or use it. Yes, you can manually modify a fixture, but
 the point is that you shouldn't have to.

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

Re: [Django] #9061: formsets with can_delete=True shouldn't add delete field to extra forms

[Django]

#9061: formsets with can_delete=True shouldn't add delete field to extra forms
---+
  Reporter:  gsf   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Forms |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by gsf):

 Having lived with this for a while, I can see the case where one might
 want a delete field on extra forms.  I'd still argue that it shouldn't be
 the default, but it could be another option on formsets.  Perhaps
 delete_extra or extra_delete?

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

Re: [Django] #3615: Can't define forward references in fixtures using MySQL with InnoDB

[Django]

#3615: Can't define forward references in fixtures using MySQL with InnoDB
---+
  Reporter:  russellm  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  mysql 
innodb myisam reference fixture
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by matthew):

 Ummm, I might be crazy but is this really an issue? When I ran into the
 error message "Cannot add or update a child row: a foreign key constraint
 fails" I just switched the order of the applications in my settings.py
 config. By putting the fixture with the data that is referenced before the
 fixture that is referencing it, everything just worked. Maybe others have
 a more complex scenario than I have...

 Later,

 Matthew Purdon

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

Re: [Django] #8898: `required` validation bypassed when using `DateTimeField` with `SplitDateTimeWidget`.

[Django]

#8898: `required` validation bypassed when using `DateTimeField` with
`SplitDateTimeWidget`.
-+--
  Reporter:  mrmachine   | Owner:  nobody   

Status:  new | Milestone:   

 Component:  Forms   |   Version:  SVN  

Resolution:  |  Keywords:  DateTimeField 
SplitDateTimeWidget
 Stage:  Design decision needed  | Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

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

 * cc: [EMAIL PROTECTED] (added)

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

Re: [Django] #8110: Admin interface: 'long' object has no attribute 'isdigit'

[Django]

#8110: Admin interface: 'long' object has no attribute 'isdigit'
---+
  Reporter:  anonymous | Owner:  nobody
Status:  reopened  | Milestone:  1.0   
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by SmileyChris):

 Yeah, this is a bug in the admin template tag which is notable when
 caching templates. The patch in #9154 fixes it (but really, it should be a
 separate ticket). There are also other issues around things like the cycle
 tag which store state on the node rather than the context.

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

[Django] #9373: "This field is required" error even on empty inlines formsets in the admin model page, when hiding a choice field of a custom form.

[Django]

#9373: "This field is required" error even on empty inlines formsets in the 
admin
model page, when hiding a choice field of a custom form.
-+--
 Reporter:  [EMAIL PROTECTED]  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Forms| Version:  1.0   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 I have a custom Form for one of my models (in the example !SecondModel)
 that adds one choice field with an initial value.
 If I use that model/form as an inline formset and I exclude the extra
 field using the "fields" attribute of the !ModelAdmin, I got "This Field
 is required" on all the forms of the formset, including those who where
 left blank. Here a simple example:
 {{{
 #!python
 # models.py
 from django.db import models

 class FirstModel(models.Model):
 a = models.CharField(max_length=10)
 b = models.CharField(max_length=10)

 class SecondModel(models.Model):
 link = models.ForeignKey(FirstModel)
 c = models.CharField(max_length=10)

 # admin.py
 from django.contrib import admin
 from bug.bugged import models, forms

 class SecondAdmin(admin.TabularInline):
 model = models.SecondModel
 form = forms.SecondForm
 fields = ['c']
 extra = 3

 class FirstAdmin(admin.ModelAdmin):
 inlines = [SecondAdmin]

 admin.site.register(models.FirstModel, FirstAdmin)

 # forms.py
 from django import forms
 from bug.bugged import models

 DUMMY_CHOICES = (
 (0, 'a'),
 (1, 'b'),
 (2, 'c')
 )

 class SecondForm(forms.ModelForm):
 d = forms.IntegerField(label='d', initial=0,
 widget=forms.Select(choices=DUMMY_CHOICES))
 class Meta:
 model = models.SecondModel
 }}}

 The problem is {{{fields = ['c']}}}, commenting out that line I get no
 errors.
 I guess, this is beacuse of the {{{has_changed}}} check, called by the
 {{{full_clean}}} method of {{{forms.Form}}}. It happens that
 {{{changed_data}}} compares the initial "d" value that had been set to 0
 with the result of "field.widget.value_from_datadict(self.data,..." that
 is None because we have not a key for "d" in self.data. So changed_data
 will contain "d" even if the form has not been changed.

 From django/forms/forms.py
 {{{
 #!python
 prefixed_name = self.add_prefix(name)
 data_value = field.widget.value_from_datadict(self.data,
 self.files, prefixed_name)
 if not field.show_hidden_initial:
 initial_value = self.initial.get(name, field.initial)

 }}}

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

[Django] #9372: Updated Slovak (sk) translation

[Django]

#9372: Updated Slovak (sk) translation
--+-
 Reporter:  mandre|   Owner:  nobody
   Status:  new   |   Milestone:  post-1.0  
Component:  Translations  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Updated Slovak translation 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-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9368: Clean up code for getting columns for select query

[Django]

#9368: Clean up code for getting columns for select query
---+
  Reporter:  adunar| Owner:  mtredinnick
Status:  assigned  | Milestone:  post-1.0   
 Component:  Database layer (models, ORM)  |   Version: 
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by adunar):

 * cc: adunar (added)

Comment:

 Great, thanks for the feedback.

 As for #2, _new_from_select_values does actually call __init__ on the
 model (I realize my docstring was confusing about that). It makes sense
 though if you want to put that functionality inline in QuerySet, since
 it's only used twice and (as you mentioned) isn't very complicated.

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

[Django] #9371: Fixtures combined with inherited models causing constraint violations/possible double entry of data

[Django]

#9371: Fixtures combined with inherited models causing constraint
violations/possible double entry of data
---+
 Reporter:  terpsquared|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Using a model descended from the provided User model (as described in
 http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-
 with-inheritance/), in combination with using a fixture, seems to attempt
 to load the same data twice, resulting in the following:


 {{{
 $ python ./manage.py syncdb
 Creating table auth_permission
 Creating table auth_group
 Creating table auth_user
 Creating table auth_message
 Creating table django_content_type
 Creating table django_session
 Creating table django_admin_log
 Creating table testapp_customuser

 You just installed Django's auth system, which means you don't have any
 superusers defined.
 Would you like to create one now? (yes/no): no
 Installing index for auth.Permission model
 Installing index for auth.Message model
 Installing index for admin.LogEntry model
 Installing json fixture 'initial_data' from absolute path.
 Problem installing fixture 'initial_data.json': Traceback (most recent
 call last):
   File "/usr/lib/python2.4/site-
 packages/django/core/management/commands/loaddata.py", line 116, in handle
 obj.save()
   File "/usr/lib/python2.4/site-packages/django/core/serializers/base.py",
 line 163, in save
 models.Model.save_base(self.object, raw=True)
   File "/usr/lib/python2.4/site-packages/django/db/models/base.py", line
 379, in save_base
 result = manager._insert(values, return_id=update_pk)
   File "/usr/lib/python2.4/site-packages/django/db/models/manager.py",
 line 138, in _insert
 return insert_query(self.model, values, **kwargs)
   File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line
 894, in insert_query
 return query.execute_sql(return_id)
   File "/usr/lib/python2.4/site-
 packages/django/db/models/sql/subqueries.py", line 309, in execute_sql
 cursor = super(InsertQuery, self).execute_sql(None)
   File "/usr/lib/python2.4/site-packages/django/db/models/sql/query.py",
 line 1724, in execute_sql
 cursor.execute(sql, params)
   File "/usr/lib/python2.4/site-packages/django/db/backends/util.py", line
 19, in execute
 return self.cursor.execute(sql, params)
   File "/usr/lib/python2.4/site-
 packages/django/db/backends/sqlite3/base.py", line 168, in execute
 return Database.Cursor.execute(self, query, params)
 IntegrityError: column username is not unique

 }}}

 Same thing with a postgres db:

 {{{
 python ./manage.py syncdb
 Installing json fixture 'initial_data' from absolute path.
 Problem installing fixture 'initial_data.json': Traceback (most recent
 call last):
   File "/usr/lib/python2.4/site-
 packages/django/core/management/commands/loaddata.py", line 116, in handle
 obj.save()
   File "/usr/lib/python2.4/site-packages/django/core/serializers/base.py",
 line 163, in save
 models.Model.save_base(self.object, raw=True)
   File "/usr/lib/python2.4/site-packages/django/db/models/base.py", line
 379, in save_base
 result = manager._insert(values, return_id=update_pk)
   File "/usr/lib/python2.4/site-packages/django/db/models/manager.py",
 line 138, in _insert
 return insert_query(self.model, values, **kwargs)
   File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line
 894, in insert_query
 return query.execute_sql(return_id)
   File "/usr/lib/python2.4/site-
 packages/django/db/models/sql/subqueries.py", line 309, in execute_sql
 cursor = super(InsertQuery, self).execute_sql(None)
   File "/usr/lib/python2.4/site-packages/django/db/models/sql/query.py",
 line 1724, in execute_sql
 cursor.execute(sql, params)
   File "/usr/lib/python2.4/site-packages/django/db/backends/util.py", line
 19, in execute
 return self.cursor.execute(sql, params)
 IntegrityError: duplicate key value violates unique constraint
 "testapp_customuser_username_key"

 }}}

 Note: This does not happen when only one record exists in the fixture
 data.  The sample data I provide has two unique records that should not
 clash.

 The following is the model definition that seems to not be handled:

 {{{
 from django.db import models
 from django.contrib.auth.models import User, UserManager
 from django.utils.translation import ugettext_lazy as _
 from datetime import datetime


 class Customuser(User):
 username = models.CharField(_('customer id'), max_length=30,
 unique=True, help_text=_("Required. 30 characters or fewer. Alphanumeric
 characters only (letters, digits and underscores)."))
 email_id = models.EmailField(_('e-mail address'), blank=True,

Re: [Django] #9366: date and time filters do not use localized strings, missing datetime filter

[Django]

#9366: date and time filters do not use localized strings, missing datetime 
filter
---+
  Reporter:  bthomas   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Internationalization  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by bthomas):

  * component:  Uncategorized => Internationalization

Comment:

 I think this is somewhat related to #2203 (the bug part of it, anyway).
 However that ticket is fixed will affect this, since the admin interface's
 date display should be consistent with the date filters.

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

Re: [Django] #9204: Google Maps Marker to change the Icon

[Django]

#9204: Google Maps Marker to change the Icon
-+--
  Reporter:  qingfeng| Owner:  jbronn   
  
Status:  new | Milestone:  post-1.0 
  
 Component:  GIS |   Version:  1.0  
  
Resolution:  |  Keywords:  geodjango google map icon 
gicon
 Stage:  Unreviewed  | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by qingfeng):

 * cc: [EMAIL PROTECTED] (added)

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

Re: [Django] #8110: Admin interface: 'long' object has no attribute 'isdigit'

[Django]

#8110: Admin interface: 'long' object has no attribute 'isdigit'
---+
  Reporter:  anonymous | Owner:  nobody
Status:  reopened  | Milestone:  1.0   
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 I run several Django sites and have *only* hit this bug on my Byteflow
 blog.

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

Re: [Django] #8110: Admin interface: 'long' object has no attribute 'isdigit'

[Django]

#8110: Admin interface: 'long' object has no attribute 'isdigit'
---+
  Reporter:  anonymous | Owner:  nobody
Status:  reopened  | Milestone:  1.0   
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 OK, has anyone hit this WITHOUT having byteflow installed?  Because after
 looking into byteflow I understand why it happens there: byteflow replaces
 Django's django.template.loader.get_template with its own
 cached_get_template which re-uses compiled templates:

 {{{
 #!python

 TEMPLATE_CACHE = {}
 def cached_get_template(template_name):
 global TEMPLATE_CACHE
 t = TEMPLATE_CACHE.get(template_name, None)
 if not t or settings.DEBUG:
 source, origin = loader.find_template_source(template_name)
 t = loader.get_template_from_string(source, origin, template_name)
 TEMPLATE_CACHE[template_name] = t
 return t
 }}}

 That code also explains why this has only been observed with DEBUG set to
 False.

 So, there is no mysterious re-use of compiled templates within Django
 itself, it's being done by the app.  Assuming that's a legit thing for an
 app to do (?) the simple fix of avoiding changing self within render fixes
 it.

 (Actually it strikes me as not a very legit thing to be doing because if
 multiple apps do what byteflow does:

 {{{
 #!python
 from django import template
 from lib.template_loaders import cached_get_template
 template.loader.get_template = cached_get_template
 }}}

 the last one "wins" and the custom code of the others gets ignored.  But
 there it is doing it, and the result is the admin interface generates a
 500 error, which is ugly.  Also if/when some form of "supported" template
 caching does get implemented, that would also run into trouble here.  So I
 do think it has exposed a real bug in the render() function that we need
 to fix, despite not particularly liking what byteflow has done here.  And
 I wonder how many other template tags may have similar issues with re-use
 of compiled versions.)

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

Re: [Django] #5253: serializer for csv format for loaddata and dumpdata

[Django]

#5253: serializer for csv format for loaddata and dumpdata
+---
  Reporter:  Adam Schmideg <[EMAIL PROTECTED]>  | Owner:  
Mnewman   
Status:  assigned   | Milestone:

 Component:  Serialization  |   Version:  SVN   

Resolution: |  Keywords:  csv, 
foreign keys, feature
 Stage:  Accepted   | Has_patch:  1 

Needs_docs:  1  |   Needs_tests:  1 

Needs_better_patch:  1  |  
+---
Changes (by Mnewman):

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

Comment:

 I am adding a version of the current patch that works with current trunk.
 I need csv serialization for a vendor and would like to see this get into
 django at some point, so I will accept it, create some tests, address
 russellm's concerns and bring it up when all those things are ready to see
 if anyone else likes the idea.

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

Re: [Django] #8874: problem with URLs on FastCGI after update to 1.0

[Django]

#8874: problem with URLs on FastCGI after update to 1.0
-+--
  Reporter:  kyprizel| Owner:  kyprizel
Status:  assigned| Milestone:  
 Component:  Core framework  |   Version:  1.0 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by qingfeng):

  * has_patch:  0 => 1

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

Re: [Django] #8874: problem with URLs on FastCGI after update to 1.0

[Django]

#8874: problem with URLs on FastCGI after update to 1.0
-+--
  Reporter:  kyprizel| Owner:  kyprizel
Status:  assigned| Milestone:  
 Component:  Core framework  |   Version:  1.0 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by qingfeng):

 * cc: [EMAIL PROTECTED] (added)
  * has_patch:  1 => 0

Comment:

 Django+nginx+prefork is problem too

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

Re: [Django] #9371: Fixtures combined with inherited models causing constraint violations/possible double entry of data

[Django]

#9371: Fixtures combined with inherited models causing constraint
violations/possible double entry of data
+---
  Reporter:  terpsquared| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 I have a feeling that this could be related to #8886 - the fact that your
 child model duplicates a field name in the parent model (username). I'll
 need to look a little closer to be certain.

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

[Django] #9370: UnicodeDecodeError when serving binary static files through GZipMiddleWare

[Django]

#9370: UnicodeDecodeError when serving binary static files through 
GZipMiddleWare
+---
 Reporter:  kikko   |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.0   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 When serving binary static files (for example images) using
 django.views.static.serve and using GZipMiddleware a traceback is returned
 instead of the image:


 {{{
 Traceback (most recent call last):

   File "/lib/python2.5/site-packages/Django-1.0_final-
 py2.5.egg/django/core/servers/basehttp.py", line 277, in run
 self.result = application(self.environ, self.start_response)

   File "/lib/python2.5/site-packages/Django-1.0_final-
 py2.5.egg/django/core/servers/basehttp.py", line 634, in __call__
 return self.application(environ, start_response)

   File "/lib/python2.5/site-packages/Django-1.0_final-
 py2.5.egg/django/core/handlers/wsgi.py", line 243, in __call__
 response = middleware_method(request, response)

   File "/lib/python2.5/site-packages/Django-1.0_final-
 py2.5.egg/django/middleware/gzip.py", line 16, in process_response
 if response.status_code != 200 or len(response.content) < 200:

   File "/lib/python2.5/site-packages/Django-1.0_final-
 py2.5.egg/django/http/__init__.py", line 359, in _get_content
 return smart_str(''.join(self._container), self._charset)

   File "/lib/python2.5/site-packages/Django-1.0_final-
 py2.5.egg/django/utils/encoding.py", line 97, in smart_str
 return s.decode('utf-8', errors).encode(encoding, errors)

   File "/usr/lib/python2.5/encodings/utf_8.py", line 16, in decode
 return codecs.utf_8_decode(input, errors, True)

 UnicodeDecodeError: 'utf8' codec can't decode byte 0x89 in position 0:
 unexpected code byte
 }}}

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

Re: [Django] #3624: Syndication could be friendlier to non Django templating languages

[Django]

#3624: Syndication could be friendlier to non Django templating languages
-+--
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  new | Milestone:
 Component:  Contrib apps|   Version:  0.96  
Resolution:  |  Keywords:
 Stage:  Someday/Maybe   | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by seemant):

 This would help me, personally, in the case of syndication feeds on the
 new comment model.   The __unicode__() function in comments makes the
 title of each comment into the first 50 words of the comment itself.  I'd
 prefer to override that in the feed (akin to the old 0.96 behaviour of "By
  on " instead.

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

Re: [Django] #3624: Syndication could be friendlier to non Django templating languages

[Django]

#3624: Syndication could be friendlier to non Django templating languages
-+--
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  new | Milestone:
 Component:  Contrib apps|   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Someday/Maybe   | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by seemant):

  * version:  0.96 => 1.0

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

Re: [Django] #8931: Queries on datetimefields return incorrect results in mysql

[Django]

#8931: Queries on datetimefields return incorrect results in mysql
---+
  Reporter:  ElliottM  | Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  1.0
 
Resolution:  invalid   |  Keywords:  datetime 
mysql query
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 Replying to [comment:1 ElliottM]:
 > Turns out this was a problem with mysql and not with django.

 Some details of the mysql problem could be helpful for when the next
 person to hit this searches the tracker, finds this report, and re-opens
 this as a bug in Django.  Is is a mysql bug logged in their bug system?  A
 configuration problem?

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

Re: [Django] #3583: cookie-based modpython / apache authentication

[Django]

#3583: cookie-based modpython / apache authentication
+---
  Reporter:  midfield <[EMAIL PROTECTED]>  | Owner:  
SmileyChris
Status:  new| Milestone:
 
 Component:  Contrib apps   |   Version:  SVN   
 
Resolution: |  Keywords:  
authentication modpython apache
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by andybak):

 * cc: [EMAIL PROTECTED] (added)

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

Re: [Django] #8110: Admin interface: 'long' object has no attribute 'isdigit'

[Django]

#8110: Admin interface: 'long' object has no attribute 'isdigit'
---+
  Reporter:  anonymous | Owner:  nobody
Status:  reopened  | Milestone:  1.0   
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by oxyum):

 Replying to [comment:22 kmtracey]:
 > I am confused by your traceback included above.  The one that starts
 "Original traceback" and starts with "django/template/debug.py", line
 71,"...yet this bug you and everyone else reports only occurs with DEBUG
 set to False.  There is also no mention of django/template/debug.py in the
 original posted traceback, nor any indication that there are multiple
 exceptions raised...so all in all I find that traceback info confusing.

 That's small bug in byteflow default configuration. When we set DEBUG to
 False, DEBUG_TEMPLATES doesn't set to False. But I'm trying set
 DEBUG_TEMPLATES to False - it's doesn't matter.

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

Re: [Django] #9358: .dates(...) only spitting out a single date, bug in queryset order

[Django]

#9358: .dates(...) only spitting out a single date, bug in queryset order
---+
  Reporter:  dokterbob | Owner:  
mtredinnick  
Status:  assigned  | Milestone:  post-1.0   
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  dates 
order .dates sqlite
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by mtredinnick):

 The point is that I don't want to have code that does things way for
 SQLite and some other way for other databases. The ordering and column
 selections pieces of the query construction are relatively separated and
 having to put part of the ordering construction into the `db/backends/*`
 part of the code is a bit fugly.

 Fortunately, we can avoid it. As you note, we can use a named alias for
 the output column gets around this, so I'll add that into the query. That
 will also avoid a problem with "order by 1" problems that we've seen on
 older SQLites on Windows (particularly the SQLite shipped with the Python
 2.5 binary).

 Short version: no need to worry about an SQLite-specific workaround.
 Assuming the aliased query actually works on SQLite (does it?), I'm going
 to take that approach.

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

Re: [Django] #9358: .dates(...) only spitting out a single date, bug in queryset order

[Django]

#9358: .dates(...) only spitting out a single date, bug in queryset order
---+
  Reporter:  dokterbob | Owner:  
mtredinnick  
Status:  assigned  | Milestone:  post-1.0   
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  dates 
order .dates sqlite
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by dokterbob):

 I'll see if I can find the time to look up the 'official' way we're
 supposed to do this stuff in SQLite.

 For now I think other users might actually be helped by my works-for-me
 patch, allthough I should have realized it's not proper SQL. :)

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

[Django] #9369: Add query string info to put and delete in test Client

[Django]

#9369: Add query string info to put and delete in test Client
---+
 Reporter:  david  |   Owner:  david 
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 #5888 has been added to trunk but the put() and delete() methods do not
 have QUERY_STRING information in the query environment and it's useful.

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