Re: [Django] #4339: Override an existing file, using Model.save_FIELD_file method,

[Django]

#4339: Override an existing file, using Model.save_FIELD_file method,
---+
  Reporter:  elaat...@gmail.com| Owner:  Gulopine   

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  FileField 
db fs-rf-docs
 Stage:  Design decision needed| Has_patch:  1  

Needs_docs:  1 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Comment (by nwelch):

 Overriding both _save and get_available_name seems to do the trick for me.
 It *seems* that it should be unnecessary to override both, but overwriting
 _save wasn't enough, and only overriding get_available_name resulted in an
 infinite loop since _save demands that the file not exist (i.e. it won't
 do an actual overwrite -- but rather a delete, then a write).

 {{{
 from django.core.files.storage import FileSystemStorage
 class OverwriteStorage(FileSystemStorage):
 def _save(self, name, content):
 if self.exists(name):
 self.delete(name)
 return super(OverwriteStorage, self)._save(name, content)
 def get_available_name(self, name):
 return name
 }}}

 I disclaim any copyright to the above code.  (I'm guessing it would be
 considered too trivial to be copyrighted anyway, but just in case)

 Also, while this is maybe a bit more likely to cause race conditions,
 nothing particularly harmful happens as a result.  The thread will just
 have to try again until it succeeds.

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

Re: [Django] #10572: defer() doesn't work cleanly with model inheritance

[Django]

#10572: defer() doesn't work cleanly with model inheritance
---+
  Reporter:  mtredinnick   | Owner:  mtredinnick
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: br...@ithink-design.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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10572: defer() doesn't work cleanly with model inheritance

[Django]

#10572: defer() doesn't work cleanly with model inheritance
---+
  Reporter:  mtredinnick   | Owner:  mtredinnick
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by byron):

 using only() doesn't work cleanly either. Given CustomUser which
 subclasses auth.User

 > CustomUser.objects.only("home_address").query.as_sql()

 ... retrieves "home_address" and all parent fields as well.

 > 'SELECT "auth_user"."id", "auth_user"."username",
 "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email",
 > "auth_user"."password", "auth_user"."is_staff", "auth_user"."is_active",
 "auth_user"."is_superuser", "auth_user"."last_login",
 > "auth_user"."date_joined", "users_customuser"."user_ptr_id",
 "users_customuser"."home_address" FROM "users_customuser" INNER
 > JOIN "auth_user" ON ("users_customuser"."user_ptr_id" =
 "auth_user"."id")'

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

Re: [Django] #5768: Allow QuerySet.values() to return values spanning joins (for multi-valued relations)

[Django]

#5768: Allow QuerySet.values() to return values spanning joins (for multi-valued
relations)
-+--
  Reporter:  anonymous   | Owner:  
Status:  new | Milestone:  
 Component:  Database layer (models, ORM)|   Version:  0.96
Resolution:  |  Keywords:  
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by miracle2k):

 * cc: miracle2k (added)

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

[Django] #11077: Django's built-in tests fail when using url reverse tags in default registration templates

[Django]

#11077: Django's built-in tests fail when using url reverse tags in default
registration templates
---+
 Reporter:  srosro |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 To reproduce:
 Create a new project.  Create some registration templates (ie:
 templates/password_reset_form.html).  Use the {% url %} template tag. For
 example, {% url index %}.  Make sure you have a valid 'index' named url!

 You should then get a failure when running the test suite:

 {{{
 #python manage.py test
 Creating test database...
 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_site
 Installing index for auth.Permission model
 Installing index for auth.Message model
 EE.EEE.F


 ...


 ==
 ERROR: test_confirm_complete
 (django.contrib.auth.tests.views.PasswordResetTest)
 --
 Traceback (most recent call last):
   File "/Applications/Django/django-
 trunk/django/contrib/auth/tests/views.py", line 71, in
 test_confirm_complete
 url, path = self._test_confirm_start()
   File "/Applications/Django/django-
 trunk/django/contrib/auth/tests/views.py", line 31, in _test_confirm_start
 response = self.client.post('/password_reset/', {'email':
 'staffmem...@example.com'})
   File "/Applications/Django/django-trunk/django/test/client.py", line
 299, in post
 return self.request(**r)
   File "/Applications/Django/django-trunk/django/core/handlers/base.py",
 line 86, in get_response
 response = callback(request, *callback_args, **callback_kwargs)
   File "/Applications/Django/django-trunk/django/contrib/auth/views.py",
 line 92, in password_reset
 form.save(**opts)
   File "/Applications/Django/django-trunk/django/contrib/auth/forms.py",
 line 135, in save
 t.render(Context(c)), None, [user.email])
   File "/Applications/Django/django-trunk/django/test/utils.py", line 15,
 in instrumented_test_render
 return self.nodelist.render(context)
   File "/Applications/Django/django-trunk/django/template/__init__.py",
 line 768, in render
 bits.append(self.render_node(node, context))
   File "/Applications/Django/django-trunk/django/template/debug.py", line
 81, in render_node
 raise wrapped
 TemplateSyntaxError: Caught an exception while rendering: Reverse for
 'testing1234.index' with arguments '()' and keyword arguments '{}' not
 found.

 Original Traceback (most recent call last):
   File "/Applications/Django/django-trunk/django/template/debug.py", line
 71, in render_node
 result = node.render(context)
   File "/Applications/Django/django-trunk/django/template/defaulttags.py",
 line 387, in render
 args=args, kwargs=kwargs)
   File "/Applications/Django/django-trunk/django/core/urlresolvers.py",
 line 262, in reverse
 *args, **kwargs)))
   File "/Applications/Django/django-trunk/django/core/urlresolvers.py",
 line 251, in reverse
 "arguments '%s' not found." % (lookup_view, args, kwargs))
 NoReverseMatch: Reverse for 'testing1234.index' with arguments '()' and
 keyword arguments '{}' not found.
 }}}

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

Re: [Django] #6183: [patch] Support help_text with ManyToMany field widgets

[Django]

#6183: [patch] Support help_text with ManyToMany field widgets
--+-
  Reporter:  Steven Armstrong   | Owner:  
nobody
Status:  new  | Milestone:  
  
 Component:  django.contrib.admin |   Version:  
newforms-admin
Resolution:   |  Keywords:  
  
 Stage:  Accepted | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  1|  
--+-
Changes (by kit1980):

  * keywords:  nfa-someday =>

Comment:

 Newforms-admin merged to trunk long time ago.
 Maybe someday is 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7050: make-messages should be able to ignore apps that have their own locale directory

[Django]

#7050: make-messages should be able to ignore apps that have their own locale
directory
---+
  Reporter:  Italo Maia| Owner:  garcia_marc
Status:  assigned  | Milestone: 
 Component:  Internationalization  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  1 |  
---+
Comment (by garcia_marc):

 Note that I created a thread on django-i18n to discuss about this ticket

 http://groups.google.com/group/Django-
 I18N/browse_thread/thread/e24ccc3bfc0c8ac3

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

Re: [Django] #7050: make-messages should be able to ignore apps that have their own locale directory

[Django]

#7050: make-messages should be able to ignore apps that have their own locale
directory
---+
  Reporter:  Italo Maia| Owner:  garcia_marc
Status:  assigned  | Milestone: 
 Component:  Internationalization  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  1 |  
---+
Changes (by garcia_marc):

  * needs_docs:  0 => 1

Comment:

 Probably it's worth mentioning the new behavior on
 http://docs.djangoproject.com/en/dev/topics/i18n/#message-files

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

Re: [Django] #11075: DateField on ManyToMany intermediary won't accept input

[Django]

#11075: DateField on ManyToMany intermediary won't accept input
---+
  Reporter:  singingwolfboy| Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:  invalid   |  Keywords:  
manytomanyfield m2m datefield
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Comment:

 Your problem is your `date_left = models.DateField(blank=True,
 default='')` `PerformanceGroupMembership` field. Try with
 `models.DateField(blank=True, null=True[, default=None])` instead, `''`
 isn't  a valid `datetime.date` value.

 The `tests/modeltests/m2m_through` successfully running tests has an
 almost identical model setup (modulo the `date_left` field that is).

 Also, next time please use the django user support channels (send a
 message to the django-users mailing list or visit the #django IRC channel)
 before opening a ticket here.

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

Re: [Django] #7050: make-messages should be able to ignore apps that have their own locale directory

[Django]

#7050: make-messages should be able to ignore apps that have their own locale
directory
---+
  Reporter:  Italo Maia| Owner:  garcia_marc
Status:  assigned  | Milestone: 
 Component:  Internationalization  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  1 |  
---+
Changes (by garcia_marc):

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

Comment:

 Just uploaded patches on ticket 7916, that is a duplicate of this one.

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

Re: [Django] #10853: Django unit test fails when using the dummy cache backend.

[Django]

#10853: Django unit test fails when using the dummy cache backend.
+---
  Reporter:  stavros| Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by andrewbadr):

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

Comment:

 Ran into this too. A solution might involve
 http://code.djangoproject.com/ticket/4788.

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

Re: [Django] #7050: make-messages should be able to ignore apps that have their own locale directory

[Django]

#7050: make-messages should be able to ignore apps that have their own locale
directory
---+
  Reporter:  Italo Maia| Owner:  garcia_marc
Status:  assigned  | Milestone: 
 Component:  Internationalization  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by garcia_marc):

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

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

Re: [Django] #11076: @transaction.commit_on_success does not seem to work as documented

[Django]

#11076: @transaction.commit_on_success does not seem to work as documented
---+
  Reporter:  Pierre| Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:  duplicate |  Keywords:  
@commit_on_success, set_dirty
 Stage:  Unreviewed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

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

Re: [Django] #11076: @transaction.commit_on_success does not seem to work as documented

[Django]

#11076: @transaction.commit_on_success does not seem to work as documented
---+
  Reporter:  Pierre| Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  
@commit_on_success, set_dirty
 Stage:  Unreviewed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 Dupe of #9964

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

[Django] #11076: @transaction.commit_on_success does not seem to work as documented

[Django]

#11076: @transaction.commit_on_success does not seem to work as documented
---+
 Reporter:  Pierre |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Database layer (models, ORM)   | Version:  1.0   
 Keywords:  @commit_on_success, set_dirty  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Observed on 1.0.2, but seems to be the same on 1.1.

 Note that this is similar to ticket #9964, but not identical (the
 issue presented here is much narrower).

 I'm working on a simple view using the @transaction.commit_on_success
 decorator.

 The view does UPDATE requests to a legacy database (through a custom
 Python module).

 Sample code (simplified)
 {{{
 @transaction.commit_on_success
 def myview(request):
   # ...
   if request.method == "POST":
 # no Django model calls;
 # some calls causing an UPDATE
   # ...
   return render_to_response(...)
 }}}

 The work is always rolled-back by Django at the end of the view.

 From django.db.transaction it appears that the commit() is done
 only if a call to set_dirty() has been made previously:

 {{{
 if is_dirty():
 commit()
 }}}

 Which in my case does not happen (unless I call it explicitly, of
 course).
 The documentation states:

 {{{
 If the function returns successfully, then Django will commit all work
 done
 within the function at that point. If the function raises an exception,
 though, Django will
 roll back the transaction.
 }}}

 As compared with the description of autocommit, which states things
 explicitly, this seems to imply that the commit() is done in all
 cases, dirty or not, so I found the actual behaviour surprising.

 I don't know where is the best place to fix this, code or doc, but
 in case you think it's the code... see 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10061: incorrect logout link in admin

[Django]

#10061: incorrect logout link in admin
---+
  Reporter:  lashni| Owner:  mtredinnick
Status:  new   | Milestone:  1.1
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  1  
Needs_better_patch:  1 |  
---+
Comment (by sorl):

 sorry I didn't reed up properly, discard my suggestion, just use it if you
 want something working 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #1820: Autogenerated ManyToMany fields can generate too long identifiers for mysql to handle

[Django]

#1820: Autogenerated ManyToMany fields can generate too long identifiers for 
mysql
to handle
---+
  Reporter:  re...@diji.biz| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  mysql 
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 I had a problem with a long constraint name, and got around it by munging
 Django's output with a Perl one-liner:

 ./manage.py sqlreset core | perl -pe 's{DROP TABLE}{DROP TABLE IF EXISTS};
 s{(?<=CONSTRAINT )(\S{47})\S*?(\S{16})(?= )}{$1_$2}' | mysql

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

Re: [Django] #11075: DateField on ManyToMany intermediary won't accept input

[Django]

#11075: DateField on ManyToMany intermediary won't accept input
---+
  Reporter:  singingwolfboy| Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  
manytomanyfield m2m datefield
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by singingwolfboy):

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

Comment:

 Proper syntax highlighting for models.py is at
 http://dpaste.com/hold/43158/

 Also, forgot to mention: running Django 1.0.2, installed via easy_install.

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

[Django] #11075: DateField on ManyToMany intermediary won't accept input

[Django]

#11075: DateField on ManyToMany intermediary won't accept input
---+
 Reporter:  singingwolfboy |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Database layer (models, ORM)   | Version:  1.0   
 Keywords:  manytomanyfield m2m datefield  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I cannot save() my m2m intermediary model, because it is throwing an error
 on a date validation. However, the date is correct -- it does not accept
 either a Python date object, or a properly formatted datestring. The
 object can be created and referenced successfully, but cannot be saved.

 Full traceback demonstrating error is attached, and also here:
 http://dpaste.com/hold/43152/
 As a reference, the relevant models are attached, and also here:
 http://dpaste.com/hold/43153/

 Help? Is any more information 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11071: Udate is_ajax docs to include ExtJS as complying

[Django]

#11071: Udate is_ajax docs to include ExtJS as complying
+---
  Reporter:  FunkyBob   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by ubernostrum):

 I wonder if, at this point, it would be better just to say that a bunch of
 popular modern JS toolkits support this, and leave off trying to
 constantly maintain a list of them.

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

Re: [Django] #10788: Actual name of uploaded file available later than it was in 1.0

[Django]

#10788: Actual name of uploaded file available later than it was in 1.0
-+--
  Reporter:  kmtracey| Owner:  jacob
Status:  new | Milestone:  1.1  
 Component:  File uploads/storage|   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Design decision needed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by mitsuhiko):

 Replying to [comment:7 anonymous]:
 > Replying to [comment:6 mitsuhiko]:
 > > The core no longer depends on that and I stronly suggest designing
 custom upload handlers in a way that they don't depend on the final
 filename of the file on the filesystem. This however is slighty backwards
 incomaptible as it seems so it requires a decision by a main developer.
 >
 > It's totally incompatible with every code I could see that needs to
 rename (uploaded) files. To rename the file, you have know its name first,
 but in the current status, this is not possible anymore (especially in
 pre_save() signals).
 Why would you need to rename a file?  Can't see how this is useful.  Just
 set the filename before the file is saved by the model then you don't have
 to rename the file, it would be stored with the correct name.

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

[Changeset] r10744 - django/branches/releases/1.0.X/django/db/backends/oracle

[noreply]

Author: mboersma
Date: 2009-05-11 15:56:38 -0500 (Mon, 11 May 2009)
New Revision: 10744

Modified:
   django/branches/releases/1.0.X/django/db/backends/oracle/introspection.py
Log:
[1.0.X] Fixed #11050 -- Oracle now passes all but one introspection unit test.


Modified: 
django/branches/releases/1.0.X/django/db/backends/oracle/introspection.py
===
--- django/branches/releases/1.0.X/django/db/backends/oracle/introspection.py   
2009-05-11 20:55:40 UTC (rev 10743)
+++ django/branches/releases/1.0.X/django/db/backends/oracle/introspection.py   
2009-05-11 20:56:38 UTC (rev 10744)
@@ -24,17 +24,20 @@
 def get_table_list(self, cursor):
 "Returns a list of table names in the current database."
 cursor.execute("SELECT TABLE_NAME FROM USER_TABLES")
-return [row[0].upper() for row in cursor.fetchall()]
+return [row[0].lower() for row in cursor.fetchall()]
 
 def get_table_description(self, cursor, table_name):
 "Returns a description of the table, with the DB-API 
cursor.description interface."
 cursor.execute("SELECT * FROM %s WHERE ROWNUM < 2" % 
self.connection.ops.quote_name(table_name))
-return cursor.description
+description = []
+for desc in cursor.description:
+description.append((desc[0].lower(),) + desc[1:])
+return description
 
 def table_name_converter(self, name):
 "Table name comparison is case insensitive under Oracle"
-return name.upper()
-
+return name.lower()
+
 def _name_to_index(self, cursor, table_name):
 """
 Returns a dictionary of {field_name: field_index} for the given table.
@@ -76,33 +79,27 @@
 # This query retrieves each index on the given table, including the
 # first associated field name
 # "We were in the nick of time; you were in great peril!"
-sql = """
-WITH primarycols AS (
- SELECT user_cons_columns.table_name, user_cons_columns.column_name, 1 AS 
PRIMARYCOL
- FROM   user_cons_columns, user_constraints
- WHERE  user_cons_columns.constraint_name = 
user_constraints.constraint_name AND
-user_constraints.constraint_type = 'P' AND
-user_cons_columns.table_name = %s),
- uniquecols AS (
- SELECT user_ind_columns.table_name, user_ind_columns.column_name, 1 AS 
UNIQUECOL
- FROM   user_indexes, user_ind_columns
- WHERE  uniqueness = 'UNIQUE' AND
-user_indexes.index_name = user_ind_columns.index_name AND
-user_ind_columns.table_name = %s)
-SELECT allcols.column_name, primarycols.primarycol, uniquecols.UNIQUECOL
-FROM   (SELECT column_name FROM primarycols UNION SELECT column_name FROM
-uniquecols) allcols,
-  primarycols, uniquecols
-WHERE  allcols.column_name = primarycols.column_name (+) AND
-  allcols.column_name = uniquecols.column_name (+)
-"""
-cursor.execute(sql, [table_name, table_name])
+sql = """\
+SELECT LOWER(all_tab_cols.column_name) AS column_name,
+   CASE user_constraints.constraint_type
+   WHEN 'P' THEN 1 ELSE 0
+   END AS is_primary_key,
+   CASE user_indexes.uniqueness
+   WHEN 'UNIQUE' THEN 1 ELSE 0
+   END AS is_unique
+FROM   all_tab_cols, user_cons_columns, user_constraints, user_ind_columns, 
user_indexes
+WHERE  all_tab_cols.column_name = user_cons_columns.column_name (+)
+  AND  all_tab_cols.table_name = user_cons_columns.table_name (+)
+  AND  user_cons_columns.constraint_name = user_constraints.constraint_name (+)
+  AND  user_constraints.constraint_type (+) = 'P'
+  AND  user_ind_columns.column_name (+) = all_tab_cols.column_name
+  AND  user_ind_columns.table_name (+) = all_tab_cols.table_name
+  AND  user_indexes.uniqueness (+) = 'UNIQUE'
+  AND  user_indexes.index_name (+) = user_ind_columns.index_name
+  AND  all_tab_cols.table_name = UPPER(%s)
+"""
+cursor.execute(sql, [table_name])
 indexes = {}
 for row in cursor.fetchall():
-# row[1] (idx.indkey) is stored in the DB as an array. It comes 
out as
-# a string of space-separated integers. This designates the field
-# indexes (1-based) of the fields that have indexes on the table.
-# Here, we skip any indexes across multiple fields.
 indexes[row[0]] = {'primary_key': row[1], 'unique': row[2]}
 return indexes
-


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

[Changeset] r10743 - django/trunk/django/db/backends/oracle

[noreply]

Author: mboersma
Date: 2009-05-11 15:55:40 -0500 (Mon, 11 May 2009)
New Revision: 10743

Modified:
   django/trunk/django/db/backends/oracle/introspection.py
Log:
Fixed #11050 -- Oracle now passes all but one introspection unit test.


Modified: django/trunk/django/db/backends/oracle/introspection.py
===
--- django/trunk/django/db/backends/oracle/introspection.py 2009-05-11 
17:29:08 UTC (rev 10742)
+++ django/trunk/django/db/backends/oracle/introspection.py 2009-05-11 
20:55:40 UTC (rev 10743)
@@ -24,17 +24,20 @@
 def get_table_list(self, cursor):
 "Returns a list of table names in the current database."
 cursor.execute("SELECT TABLE_NAME FROM USER_TABLES")
-return [row[0].upper() for row in cursor.fetchall()]
+return [row[0].lower() for row in cursor.fetchall()]
 
 def get_table_description(self, cursor, table_name):
 "Returns a description of the table, with the DB-API 
cursor.description interface."
 cursor.execute("SELECT * FROM %s WHERE ROWNUM < 2" % 
self.connection.ops.quote_name(table_name))
-return cursor.description
+description = []
+for desc in cursor.description:
+description.append((desc[0].lower(),) + desc[1:])
+return description
 
 def table_name_converter(self, name):
 "Table name comparison is case insensitive under Oracle"
-return name.upper()
-
+return name.lower()
+
 def _name_to_index(self, cursor, table_name):
 """
 Returns a dictionary of {field_name: field_index} for the given table.
@@ -76,33 +79,27 @@
 # This query retrieves each index on the given table, including the
 # first associated field name
 # "We were in the nick of time; you were in great peril!"
-sql = """
-WITH primarycols AS (
- SELECT user_cons_columns.table_name, user_cons_columns.column_name, 1 AS 
PRIMARYCOL
- FROM   user_cons_columns, user_constraints
- WHERE  user_cons_columns.constraint_name = 
user_constraints.constraint_name AND
-user_constraints.constraint_type = 'P' AND
-user_cons_columns.table_name = %s),
- uniquecols AS (
- SELECT user_ind_columns.table_name, user_ind_columns.column_name, 1 AS 
UNIQUECOL
- FROM   user_indexes, user_ind_columns
- WHERE  uniqueness = 'UNIQUE' AND
-user_indexes.index_name = user_ind_columns.index_name AND
-user_ind_columns.table_name = %s)
-SELECT allcols.column_name, primarycols.primarycol, uniquecols.UNIQUECOL
-FROM   (SELECT column_name FROM primarycols UNION SELECT column_name FROM
-uniquecols) allcols,
-  primarycols, uniquecols
-WHERE  allcols.column_name = primarycols.column_name (+) AND
-  allcols.column_name = uniquecols.column_name (+)
-"""
-cursor.execute(sql, [table_name, table_name])
+sql = """\
+SELECT LOWER(all_tab_cols.column_name) AS column_name,
+   CASE user_constraints.constraint_type
+   WHEN 'P' THEN 1 ELSE 0
+   END AS is_primary_key,
+   CASE user_indexes.uniqueness
+   WHEN 'UNIQUE' THEN 1 ELSE 0
+   END AS is_unique
+FROM   all_tab_cols, user_cons_columns, user_constraints, user_ind_columns, 
user_indexes
+WHERE  all_tab_cols.column_name = user_cons_columns.column_name (+)
+  AND  all_tab_cols.table_name = user_cons_columns.table_name (+)
+  AND  user_cons_columns.constraint_name = user_constraints.constraint_name (+)
+  AND  user_constraints.constraint_type (+) = 'P'
+  AND  user_ind_columns.column_name (+) = all_tab_cols.column_name
+  AND  user_ind_columns.table_name (+) = all_tab_cols.table_name
+  AND  user_indexes.uniqueness (+) = 'UNIQUE'
+  AND  user_indexes.index_name (+) = user_ind_columns.index_name
+  AND  all_tab_cols.table_name = UPPER(%s)
+"""
+cursor.execute(sql, [table_name])
 indexes = {}
 for row in cursor.fetchall():
-# row[1] (idx.indkey) is stored in the DB as an array. It comes 
out as
-# a string of space-separated integers. This designates the field
-# indexes (1-based) of the fields that have indexes on the table.
-# Here, we skip any indexes across multiple fields.
 indexes[row[0]] = {'primary_key': row[1], 'unique': row[2]}
 return indexes
-


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

Re: [Django] #5537: Remove Reverse Lookups on ForeignKeys/ManyToMany

[Django]

#5537: Remove Reverse Lookups on ForeignKeys/ManyToMany
---+
  Reporter:  dcramer   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jpwatts):

 * cc: jpwatts (added)

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

Re: [Django] #11017: Oracle LIKEC query doesn't use index

[Django]

#11017: Oracle LIKEC query doesn't use index
---+
  Reporter:  jtiai | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  oracle
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by jtiai):

 Replying to [comment:8 ikelly]:
 > Thanks for the test case.  This confirms that the problem happens at
 least with VARCHAR2 columns.  However, when I change the column type to
 NVARCHAR2, I get full table scans for both queries.  I may have something
 misconfigured -- it seems bizarre that this sort of query would ignore the
 index just because the column is NVARCHAR2.
 >

 I recall that there was some "catch" again here. Orace is so delicate what
 comes to indices.

 > To test the reverse-key index suggestion, I also changed the original
 script by adding a reverse-key index and changing the search strings to
 '%Alley'.  The result: Oracle wouldn't let me create both a normal and
 reverse-key index on the same column.  So I deleted the normal index and
 tried again, and I got full table scans for both queries.

 There was some "catch" to make reverses working - it's not main concern
 right now anyway.

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

Re: [Django] #7857: manage.py shell, dbshell funtionality

[Django]

#7857: manage.py shell, dbshell funtionality
-+--
  Reporter:  Sanha   | Owner:  nobody   

Status:  new | Milestone:   

 Component:  django-admin.py |   Version:  SVN  

Resolution:  |  Keywords:  manage.py, 
testserver, shell, dbshell
 Stage:  Design decision needed  | Has_patch:  0

Needs_docs:  0   |   Needs_tests:  0

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

 For now you can use `testshell` command that I just assembled:

 http://www.djangosnippets.org/snippets/1500/

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

Re: [Django] #10788: Actual name of uploaded file available later than it was in 1.0

[Django]

#10788: Actual name of uploaded file available later than it was in 1.0
-+--
  Reporter:  kmtracey| Owner:  jacob
Status:  new | Milestone:  1.1  
 Component:  File uploads/storage|   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Design decision needed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 Replying to [comment:6 mitsuhiko]:
 > The core no longer depends on that and I stronly suggest designing
 custom upload handlers in a way that they don't depend on the final
 filename of the file on the filesystem. This however is slighty backwards
 incomaptible as it seems so it requires a decision by a main developer.

 It's totally incompatible with every code I could see that needs to rename
 (uploaded) files. To rename the file, you have know its name first, but in
 the current status, this is not possible anymore (especially in pre_save()
 signals).

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

[Django] #11074: syncdb should execute custom field SQL separately from initial model SQL

[Django]

#11074: syncdb should execute custom field SQL separately from initial model SQL
--+-
 Reporter:  psmith|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django-admin.py   | Version:  1.0   
 Keywords:  syncdb geodjango post_create_sql  |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Currently, if I have exception-throwing SQL in a /.sql file,
 this breaks GeoDjango's creation of geometry fields and indexes on
 ./manage.py syncdb. You wind up with a database table that has the regular
 Django fields but is missing geometry fields at the end of the syncdb
 command. This is because GeoDjango's field-specific post-table-creation
 SQL which actually creates the geometry fields (from the post_create_sql()
 hook) is lumped in with the initial model SQL. I am proposing that custom
 field post-table-creation SQL like GeoDjango emits and user-specified
 initial model SQL in *.sql files be run in separate transactions.

 Arguably if my custom initial model SQL is broken then I shouldn't expect
 syncdb to work cleanly. But it may be surprising that my probably
 unrelated initial model SQL leaves my GeoDjango model tables (or any model
 with a custom field that implements post_create_sql()) in an incomplete or
 undefined state because it happens to be executing in the same transaction
 as the custom field SQL. syncdb does charge ahead and create as much as
 possible despite exceptions, so I think one could argue that leaving the
 database in as consistent a state as possible despite errors is a decent
 goal.

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

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

[Django]

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

 How do I get email notifications when a wiki page is changed (excluding
 minor changes)?  If there's no way to do that, then wiki pages aren't
 usable for discussion.

 Referer checking helps login CSRF, but I don't think it helps same-domain
 session fixing.  I'm not sure any generally acceptable method fixes that
 yet, though.

 My approach protects against same-domain attacks via HTTP; referer
 checking less reliable for this.

 The method I described has a property which makes it a bit simpler: its
 behavior can nest outside of the main CSRF handling.  In fact, it could
 probably be implemented as a separate middleware (though there's no reason
 to actually do so).  I may implement it as a proof-of-concept to see how
 tricky it is.

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

Re: [Django] #11073: SESSION_COOKIE_PATH should be introduced in this page

[Django]

#11073: SESSION_COOKIE_PATH should be introduced in this page
+---
  Reporter:  liling | Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.0 
Resolution: |  Keywords:  session settings
 Stage:  Unreviewed | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by gsong):

  * 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11073: SESSION_COOKIE_PATH should be introduced in this page

[Django]

#11073: SESSION_COOKIE_PATH should be introduced in this page
--+-
 Reporter:  liling|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Documentation | Version:  1.0   
 Keywords:  session settings  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 settings.SESSION_COOKIE_PATH is not mentioned in this document:

   http://docs.djangoproject.com/en/dev/topics/http/sessions/

 I found the setting from bug tracking system. It should be added.

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

Re: [Django] #11072: Add Info Window Html to GMarker

[Django]

#11072: Add Info Window Html to GMarker
-+--
  Reporter:  Ubercore| Owner:  nobody   
Status:  new | Milestone:   
 Component:  GIS |   Version:  SVN  
Resolution:  |  Keywords:  googlemaps marker gis
 Stage:  Unreviewed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by Ubercore):

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

Comment:

 Sorry, my example has a typo. It should have been
 {{{
 marker = GMarker(object.location, title=object.address)
 marker.info_window_html = "Info Window!";
 }}}

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

Re: [Django] #10889: ModelAdmin calls .log_deletion after deletion, causing invalid object_id

[Django]

#10889: ModelAdmin calls .log_deletion after deletion, causing invalid object_id
---+
  Reporter:  jdunck| Owner:  nobody
Status:  closed| Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  1.1-beta-1
Resolution:  fixed |  Keywords:
 Stage:  Ready for checkin | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 Replying to [comment:6 jacob]:
 > Fixed in [10686].
 And r10720 for 1.0.X

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

Re: [Django] #11051: Oracle backend fails null_fk regression tests

[Django]

#11051: Oracle backend fails null_fk regression tests
---+
  Reporter:  mboersma  | Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:  fixed |  Keywords:  Oracle 
oracle
 Stage:  Unreviewed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by mboersma):

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

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

[Changeset] r10742 - django/trunk/django/db/backends/oracle

[noreply]

Author: mboersma
Date: 2009-05-11 12:29:08 -0500 (Mon, 11 May 2009)
New Revision: 10742

Modified:
   django/trunk/django/db/backends/oracle/query.py
Log:
Fixed #11051 -- Oracle passes null_fk unit tests in trunk again.  Thanks, 
JirkaV.


Modified: django/trunk/django/db/backends/oracle/query.py
===
--- django/trunk/django/db/backends/oracle/query.py 2009-05-11 16:13:29 UTC 
(rev 10741)
+++ django/trunk/django/db/backends/oracle/query.py 2009-05-11 17:29:08 UTC 
(rev 10742)
@@ -51,14 +51,14 @@
   for v in row[rn_offset:index_start]]
 for value, field in map(None, row[index_start:], fields):
 values.append(self.convert_values(value, field))
-return values
+return tuple(values)
 
 def convert_values(self, value, field):
 if isinstance(value, Database.LOB):
 value = value.read()
 if field and field.get_internal_type() == 'TextField':
 value = force_unicode(value)
-
+
 # Oracle stores empty strings as null. We need to undo this in
 # order to adhere to the Django convention of using the empty
 # string instead of null, but only if the field accepts the
@@ -148,4 +148,3 @@
 klass = query_class(QueryClass, cx_Oracle)
 return klass.__new__(klass)
 unpickle_query_class.__safe_for_unpickling__ = True
-


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

[Django] #11072: Add Info Window Html to GMarker

[Django]

#11072: Add Info Window Html to GMarker
---+
 Reporter:  Ubercore   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  GIS| Version:  SVN   
 Keywords:  googlemaps marker gis  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 I did a quick search for this and didn't find any previous work.

 It allows you to set HTML for a GInfoWindow on an instance of a GMarker.
 No support for options on the info window yet, this is just the simplest
 case.

 I did see that it's possible to accomplish this using the GEvent class in
 overlays.py, but I think there's value in being able to set it directly on
 the marker.

 google-map.js uses bindInfoWindowHtml() to add the info window when the
 marker is added.

 A more complete solution might involve implementing GInfoWindow and
 GInfoWindowOptions, but I didn't want to implement them since they have no
 public constructor in the Google Maps API. Maybe represent the info window
 as a tuple of (html, { options})?

 Anyway, this tackles the simplest case.

 Example usage:

 {{{
 marker = GMarker(object.location, title=object.address)
 marker.infowindowhtml = "Info Window!";
 }}}

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

Re: [Django] #11017: Oracle LIKEC query doesn't use index

[Django]

#11017: Oracle LIKEC query doesn't use index
---+
  Reporter:  jtiai | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  oracle
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by ikelly):

 Thanks for the test case.  This confirms that the problem happens at least
 with VARCHAR2 columns.  However, when I change the column type to
 NVARCHAR2, I get full table scans for both queries.  I may have something
 misconfigured -- it seems bizarre that this sort of query would ignore the
 index just because the column is NVARCHAR2.

 To test the reverse-key index suggestion, I also changed the original
 script by adding a reverse-key index and changing the search strings to
 '%Alley'.  The result: Oracle wouldn't let me create both a normal and
 reverse-key index on the same column.  So I deleted the normal index and
 tried again, and I got full table scans for both queries.

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

Re: [Django] #10061: incorrect logout link in admin

[Django]

#10061: incorrect logout link in admin
---+
  Reporter:  lashni| Owner:  mtredinnick
Status:  new   | Milestone:  1.1
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  1  
Needs_better_patch:  1 |  
---+
Changes (by sorl):

 * cc: mi...@sorl.net (added)

Comment:

 What about adding something like:

 {{{
 def _get_root_path(self):
 if not hasattr(self, '_root_path'):
 self._root_path = reverse('%sadmin_index' % self.name)
 return self._root_path
 root_path = property(_get_root_path)
 }}}

 to the !AdminSite class?

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

Re: [Django] #8817: Accessing ImageField's dimensions doesn't close file

[Django]

#8817: Accessing ImageField's dimensions doesn't close file
---+
  Reporter:  tripediac | Owner:  mitsuhiko
Status:  closed| Milestone:  1.1  
 Component:  File uploads/storage  |   Version:  SVN  
Resolution:  fixed |  Keywords:   
 Stage:  Ready for checkin | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 Replying to [comment:14 bthomas]:
 > This no longer seems to be an issue after r10737. #11032 is still
 broken, but for a different reason, and unrelated to this bug.

 Yes, I confirmed r10737 fixed 'mug' being kept open.  I've also checked in
 the fix for #11032 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r10741 - django/trunk/tests/regressiontests/file_storage

[noreply]

Author: kmtracey
Date: 2009-05-11 11:13:29 -0500 (Mon, 11 May 2009)
New Revision: 10741

Modified:
   django/trunk/tests/regressiontests/file_storage/models.py
Log:
Fixed #11032: close() a file explictly open()'d in a test, so that deleting the 
file tree it is in doesn't fail on Windows.  Thanks bthomas for the patch.


Modified: django/trunk/tests/regressiontests/file_storage/models.py
===
--- django/trunk/tests/regressiontests/file_storage/models.py   2009-05-11 
11:56:46 UTC (rev 10740)
+++ django/trunk/tests/regressiontests/file_storage/models.py   2009-05-11 
16:13:29 UTC (rev 10741)
@@ -86,6 +86,7 @@
 >>> p3.mugshot.file.open()
 >>> p = Person.objects.create(name="Bob The Builder", 
 >>> mugshot=File(p3.mugshot.file))
 >>> p.save()
+>>> p3.mugshot.file.close() 
 
 # Delete all test files
 >>> shutil.rmtree(temp_storage_dir)


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

Re: [Django] #11032: Failed regressiontest on Windows for ImageField

[Django]

#11032: Failed regressiontest on Windows for ImageField
---+
  Reporter:  joeri | Owner:  nobody 
  
Status:  reopened  | Milestone:  1.1
  
 Component:  File uploads/storage  |   Version:  SVN
  
Resolution:|  Keywords:  regressiontest 
imagefield windows
 Stage:  Ready for checkin | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

  * stage:  Unreviewed => Ready for checkin
  * milestone:  => 1.1

Comment:

 I'd guess r10737 is what fixed 'mug' being left open, as it wasn't
 previously (yesterday) fixed by the fix for #8817.  What remains looks
 like a straightforward test bug of opening a file without closing 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 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10996: CSRF documentation doesn't note login CSRF vulnerability

[Django]

#10996: CSRF documentation doesn't note login CSRF vulnerability
+---
  Reporter:  smehmood   | Owner:  lukeplant
Status:  new| Milestone:   
 Component:  Documentation  |   Version:  1.0  
Resolution: |  Keywords:  CSRF 
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by lukeplant):

 See CsrfProtection - out-of-the-box login views are not actually
 vulnerable to login CSRF with the CSRF middleware.  But probably the
 documentation does need fixing in the 1.0.X branch (and 1.1.X branch when
 it arrives).

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

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

[Django]

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

 OK, I've had another think about this, and since it is getting rather
 complicated, I've created a wiki page: CsrfProtection

 Let's move any discussion to a 'Talk' section at the bottom of that page.
 I haven't thought about the proposal you made about the optional use of
 session, but it seems a bit complex, and I think what I've come up with on
 that page covers all our bases a bit better.

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

Re: [Django] #10870: Aggregates with joins ignore extra filters provided by setup_joins

[Django]

#10870: Aggregates with joins ignore extra filters provided by setup_joins
--+-
  Reporter:  fas  | Owner:  fas 

Status:  new  | Milestone:  1.2 

 Component:  ORM aggregation  |   Version:  SVN 

Resolution:   |  Keywords:  orm, aggregation, join, 
contenttypes, filter
 Stage:  Accepted | Has_patch:  0   

Needs_docs:  0|   Needs_tests:  0   

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

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

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

Re: [Django] #8817: Accessing ImageField's dimensions doesn't close file

[Django]

#8817: Accessing ImageField's dimensions doesn't close file
---+
  Reporter:  tripediac | Owner:  mitsuhiko
Status:  closed| Milestone:  1.1  
 Component:  File uploads/storage  |   Version:  SVN  
Resolution:  fixed |  Keywords:   
 Stage:  Ready for checkin | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by bthomas):

 This no longer seems to be an issue after r10737. #11032 is still broken,
 but for a different reason, and unrelated to this bug.

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

Re: [Django] #11032: Failed regressiontest on Windows for ImageField

[Django]

#11032: Failed regressiontest on Windows for ImageField
---+
  Reporter:  joeri | Owner:  nobody 
  
Status:  reopened  | Milestone: 
  
 Component:  File uploads/storage  |   Version:  SVN
  
Resolution:|  Keywords:  regressiontest 
imagefield windows
 Stage:  Unreviewed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by bthomas):

  * has_patch:  0 => 1

Comment:

 Attached a trivial patch for the latest trunk that allows the file_storage
 tests to pass on Windows.

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

Re: [Django] #11032: Failed regressiontest on Windows for ImageField

[Django]

#11032: Failed regressiontest on Windows for ImageField
---+
  Reporter:  joeri | Owner:  nobody 
  
Status:  reopened  | Milestone: 
  
 Component:  File uploads/storage  |   Version:  SVN
  
Resolution:|  Keywords:  regressiontest 
imagefield windows
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by bthomas):

 I probably should mention that I'm running the latest trunk, so I have the
 patch for #8817.

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

Re: [Django] #11032: Failed regressiontest on Windows for ImageField

[Django]

#11032: Failed regressiontest on Windows for ImageField
---+
  Reporter:  joeri | Owner:  nobody 
  
Status:  reopened  | Milestone: 
  
 Component:  File uploads/storage  |   Version:  SVN
  
Resolution:|  Keywords:  regressiontest 
imagefield windows
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by bthomas):

 The file_storage tests fail for me on Windows as well, but for a different
 reason. "shot" is being held open, not "mug". If I remove the last test:

 {{{
 # Make sure that wrapping the file in a file still works
 >>> p3.mugshot.file.open()
 >>> p = Person.objects.create(name="Bob The Builder",
 mugshot=File(p3.mugshot.file))
 >>> p.save()
 }}}

 everything is fine. If instead I just add {{{p3.mugshot.file.close()}}}
 after the {{{p.save()}}}, the test will also pass.

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

Re: [Django] #6191: Admin delete view doesn't show all items in some circumstances

[Django]

#6191: Admin delete view doesn't show all items in some circumstances
---+
  Reporter:  nicklane  | Owner:  nobody 
Status:  new   | Milestone: 
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords:  nfa-someday
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  1 |  
---+
Changes (by carljm):

 * cc: carljm (added)

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

Re: [Django] #10788: Actual name of uploaded file available later than it was in 1.0

[Django]

#10788: Actual name of uploaded file available later than it was in 1.0
-+--
  Reporter:  kmtracey| Owner:  jacob
Status:  new | Milestone:  1.1  
 Component:  File uploads/storage|   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Design decision needed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by mitsuhiko):

 * cc: mitsuhiko (added)
  * owner:  mitsuhiko => jacob
  * stage:  Accepted => Design decision needed

Comment:

 The core no longer depends on that and I stronly suggest designing custom
 upload handlers in a way that they don't depend on the final filename of
 the file on the filesystem. This however is slighty backwards incomaptible
 as it seems so it requires a decision by a main developer.

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

Re: [Django] #11071: Udate is_ajax docs to include ExtJS as complying

[Django]

#11071: Udate is_ajax docs to include ExtJS as complying
+---
  Reporter:  FunkyBob   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

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

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

[Changeset] r10740 - django/trunk/django/db/backends/postgresql_psycopg2

[noreply]

Author: russellm
Date: 2009-05-11 06:56:46 -0500 (Mon, 11 May 2009)
New Revision: 10740

Modified:
   django/trunk/django/db/backends/postgresql_psycopg2/base.py
Log:
More fixes to PostgreSQL version comparisons from r10730.

Modified: django/trunk/django/db/backends/postgresql_psycopg2/base.py
===
--- django/trunk/django/db/backends/postgresql_psycopg2/base.py 2009-05-11 
10:13:43 UTC (rev 10739)
+++ django/trunk/django/db/backends/postgresql_psycopg2/base.py 2009-05-11 
11:56:46 UTC (rev 10740)
@@ -105,11 +105,11 @@
 cursor.execute("SET TIME ZONE %s", [settings_dict['TIME_ZONE']])
 if not hasattr(self, '_version'):
 self.__class__._version = get_version(cursor)
-if self._version[0:2] < [8, 0]:
+if self._version[0:2] < (8, 0):
 # No savepoint support for earlier version of PostgreSQL.
 self.features.uses_savepoints = False
 if self.features.uses_autocommit:
-if self._version[0:2] < [8, 2]:
+if self._version[0:2] < (8, 2):
 # FIXME: Needs extra code to do reliable model insert
 # handling, so we forbid it for now.
 from django.core.exceptions import ImproperlyConfigured


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

Re: [Django] #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:  Unreviewed | Has_patch:  1 
Needs_docs:  1  |   Needs_tests:  1 
Needs_better_patch:  1  |  
+---
Changes (by toxik):

  * status:  closed => reopened
  * needs_better_patch:  0 => 1
  * resolution:  fixed =>
  * needs_tests:  0 => 1
  * needs_docs:  0 => 1

Comment:

 Seems like you got the wrong ticket number, Russell.

 As an aside, here's how I access the session in a very session backend
 agnostic way:
 {{{
 #!python
 from django.test import TestCase
 from django.test.client import ClientHandler

 class SessionHandler(ClientHandler):
 def get_response(self, request):
 response = super(SessionHandler, self).get_response(request)
 response.session = request.session.copy()
 return response

 class SessionTestCase(TestCase):
 def _pre_setup(self):
 super(SessionTestCase, self)._pre_setup()
 self.client.handler = SessionHandler()

 class FooTestCase(SessionTestCase):
 def test_session_exists(self):
 resp = self.client.get("/")
 self.assert_(hasattr(resp, "session"))
 self.assert_("my_session_key" in resp.session)
 self.assertEqual(resp.session["my_session_key"], "Hello world!")
 }}}

 As you can see, it'd be very easy for the original `ClientHandler` class
 to just copy over the session to the response object.

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

Re: [Django] #11055: ImageField uploads fail at r10717

[Django]

#11055: ImageField uploads fail at r10717
---+
  Reporter:  timo  | Owner:  mitsuhiko
Status:  closed| Milestone:  1.1  
 Component:  File uploads/storage  |   Version:  SVN  
Resolution:  fixed |  Keywords:   
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  1
Needs_better_patch:  0 |  
---+
Changes (by jacob):

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

Comment:

 Fixed in [10739].

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

[Changeset] r10739 - django/trunk/django/core/files

[noreply]

Author: jacob
Date: 2009-05-11 05:13:43 -0500 (Mon, 11 May 2009)
New Revision: 10739

Modified:
   django/trunk/django/core/files/uploadhandler.py
Log:
Fixed #11055: fixed a regression in [10717] that caused uploaded files to have 
incorrectly set file pointers. They're now, as before, reset to the beginning 
upon successful upload.

Modified: django/trunk/django/core/files/uploadhandler.py
===
--- django/trunk/django/core/files/uploadhandler.py 2009-05-11 10:10:03 UTC 
(rev 10738)
+++ django/trunk/django/core/files/uploadhandler.py 2009-05-11 10:13:43 UTC 
(rev 10739)
@@ -180,6 +180,7 @@
 if not self.activated:
 return
 
+self.file.seek(0)
 return InMemoryUploadedFile(
 file = self.file,
 field_name = self.field_name,


Property changes on: django/trunk/django/core/files/uploadhandler.py
___
Name: svn:executable
   + *


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

[Changeset] r10738 - in django/trunk: django/db/models django/db/models/sql tests/modeltests/proxy_models

[noreply]

Author: jacob
Date: 2009-05-11 05:10:03 -0500 (Mon, 11 May 2009)
New Revision: 10738

Modified:
   django/trunk/django/db/models/base.py
   django/trunk/django/db/models/manager.py
   django/trunk/django/db/models/options.py
   django/trunk/django/db/models/sql/query.py
   django/trunk/tests/modeltests/proxy_models/models.py
Log:
Fixed #10953, #10955: proxies of proxies now work correctly, though I still 
don't quite understand why you'd want to do such a thing. Thanks, Armin 
Ronacher.

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2009-05-11 09:57:19 UTC (rev 
10737)
+++ django/trunk/django/db/models/base.py   2009-05-11 10:10:03 UTC (rev 
10738)
@@ -116,6 +116,8 @@
 new_class._meta.local_many_to_many):
 raise FieldError("Proxy model '%s' contains model fields."
 % name)
+while base._meta.proxy:
+base = base._meta.proxy_for_model
 new_class._meta.setup_proxy(base)
 
 # Do the appropriate setup for any model parents.
@@ -123,6 +125,7 @@
 if isinstance(f, OneToOneField)])
 
 for base in parents:
+original_base = base
 if not hasattr(base, '_meta'):
 # Things without _meta aren't functional models, so they're
 # uninteresting parents.
@@ -167,7 +170,7 @@
 # Proxy models inherit the non-abstract managers from their base,
 # unless they have redefined any of them.
 if is_proxy:
-new_class.copy_managers(base._meta.concrete_managers)
+new_class.copy_managers(original_base._meta.concrete_managers)
 
 # Inherit virtual fields (like GenericForeignKey) from the parent
 # class

Modified: django/trunk/django/db/models/manager.py
===
--- django/trunk/django/db/models/manager.py2009-05-11 09:57:19 UTC (rev 
10737)
+++ django/trunk/django/db/models/manager.py2009-05-11 10:10:03 UTC (rev 
10738)
@@ -57,7 +57,7 @@
 setattr(model, name, ManagerDescriptor(self))
 if not getattr(model, '_default_manager', None) or 
self.creation_counter < model._default_manager.creation_counter:
 model._default_manager = self
-if model._meta.abstract or self._inherited:
+if model._meta.abstract or (self._inherited and not 
self.model._meta.proxy):
 model._meta.abstract_managers.append((self.creation_counter, name,
 self))
 else:

Modified: django/trunk/django/db/models/options.py
===
--- django/trunk/django/db/models/options.py2009-05-11 09:57:19 UTC (rev 
10737)
+++ django/trunk/django/db/models/options.py2009-05-11 10:10:03 UTC (rev 
10738)
@@ -461,8 +461,13 @@
 if ancestor in self.parents:
 return self.parents[ancestor]
 for parent in self.parents:
-if parent._meta.get_ancestor_link(ancestor):
-return self.parents[parent]
+# Tries to get a link field from the immediate parent
+parent_link = parent._meta.get_ancestor_link(ancestor)
+if parent_link:
+# In case of a proxied model, the first link
+# of the chain to the ancestor is that parent
+# links
+return self.parents[parent] or parent_link
 
 def get_ordered_objects(self):
 "Returns a list of Options objects that are ordered with respect to 
this object."

Modified: django/trunk/django/db/models/sql/query.py
===
--- django/trunk/django/db/models/sql/query.py  2009-05-11 09:57:19 UTC (rev 
10737)
+++ django/trunk/django/db/models/sql/query.py  2009-05-11 10:10:03 UTC (rev 
10738)
@@ -778,7 +778,9 @@
 qn2 = self.connection.ops.quote_name
 aliases = set()
 only_load = self.deferred_to_columns()
-proxied_model = opts.proxy and opts.proxy_for_model or 0
+# Skip all proxy to the root proxied model
+proxied_model = get_proxied_model(opts)
+
 if start_alias:
 seen = {None: start_alias}
 for field, model in opts.get_fields_with_model():
@@ -1301,7 +1303,10 @@
 opts = self.model._meta
 root_alias = self.tables[0]
 seen = {None: root_alias}
-proxied_model = opts.proxy and opts.proxy_for_model or 0
+
+# Skip all proxy to the root proxied model
+proxied_model = get_proxied_model(opts)
+
 for field, model in opts.get_fields_with_model():
 if model not in seen:
 if model is proxied_model:
@@ -1376,6 +1381,13 @@
 alias = root_alias
 alias_chain = []
  

[Changeset] r10737 - in django/trunk: django/core/files django/db/models/fields tests/modeltests/model_forms tests/regressiontests/file_storage

[noreply]

Author: jacob
Date: 2009-05-11 04:57:19 -0500 (Mon, 11 May 2009)
New Revision: 10737

Modified:
   django/trunk/django/core/files/base.py
   django/trunk/django/core/files/images.py
   django/trunk/django/core/files/uploadedfile.py
   django/trunk/django/db/models/fields/files.py
   django/trunk/tests/modeltests/model_forms/models.py
   django/trunk/tests/regressiontests/file_storage/models.py
Log:
Fixed #10404: ImageField height_field and width_field options no longer depend 
on putting the image field after the height/width fields as they did after 
r9766.

This bug actually exposed a related handful of inconsistancies in the 
underlying file handling and wraping, so a few related changes are in here as 
well:

* Dimensions are also now calculated the moment the image is assigned to 
the field instead of upon save.
* The base `File` object now when possible delegates its closed attribute 
down to the os-level file it wrapps.
* In-memory files' `close()` now is a no-op. Without this certain APIs that 
should be able to handle in-memory files were failing.
* Accessing `FieldFile.closed` used to open the file. That's silly, and it 
doesn't any more.
* Some over-eager error handling was squishing some errors that would 
normally be raised. One unit test was incorrectly depending on this behavior, 
so the test was removed.

Thanks to Armin Ronacher for much of this work.

Modified: django/trunk/django/core/files/base.py
===
--- django/trunk/django/core/files/base.py  2009-05-11 01:48:06 UTC (rev 
10736)
+++ django/trunk/django/core/files/base.py  2009-05-11 09:57:19 UTC (rev 
10737)
@@ -16,7 +16,6 @@
 name = getattr(file, 'name', None)
 self.name = name
 self.mode = getattr(file, 'mode', None)
-self.closed = False
 
 def __str__(self):
 return smart_str(self.name or '')
@@ -48,6 +47,10 @@
 
 size = property(_get_size, _set_size)
 
+def _get_closed(self):
+return not self.file or self.file.closed
+closed = property(_get_closed)
+
 def chunks(self, chunk_size=None):
 """
 Read the file and yield chucks of ``chunk_size`` bytes (defaults to
@@ -101,15 +104,13 @@
 def open(self, mode=None):
 if not self.closed:
 self.seek(0)
-elif os.path.exists(self.file.name):
-self.file = open(self.file.name, mode or self.file.mode)
-self.closed = False
+elif self.name and os.path.exists(self.name):
+self.file = open(self.name, mode or self.mode)
 else:
 raise ValueError("The file cannot be reopened.")
 
 def close(self):
 self.file.close()
-self.closed = True
 
 class ContentFile(File):
 """
@@ -127,6 +128,7 @@
 return True
 
 def open(self, mode=None):
-if self.closed:
-self.closed = False
 self.seek(0)
+
+def close(self):
+pass

Modified: django/trunk/django/core/files/images.py
===
--- django/trunk/django/core/files/images.py2009-05-11 01:48:06 UTC (rev 
10736)
+++ django/trunk/django/core/files/images.py2009-05-11 09:57:19 UTC (rev 
10737)
@@ -21,7 +21,11 @@
 
 def _get_image_dimensions(self):
 if not hasattr(self, '_dimensions_cache'):
+close = self.closed
+self.open()
 self._dimensions_cache = get_image_dimensions(self)
+if close:
+self.close()
 return self._dimensions_cache
 
 def get_image_dimensions(file_or_path):

Modified: django/trunk/django/core/files/uploadedfile.py
===
--- django/trunk/django/core/files/uploadedfile.py  2009-05-11 01:48:06 UTC 
(rev 10736)
+++ django/trunk/django/core/files/uploadedfile.py  2009-05-11 09:57:19 UTC 
(rev 10737)
@@ -74,16 +74,13 @@
 
 def close(self):
 try:
-try:
-return self.file.close()
-except OSError, e:
-if e.errno != 2:
-# Means the file was moved or deleted before the tempfile
-# could unlink it.  Still sets self.file.close_called and
-# calls self.file.file.close() before the exception
-raise
-finally:
-self.closed = True
+return self.file.close()
+except OSError, e:
+if e.errno != 2:
+# Means the file was moved or deleted before the tempfile
+# could unlink it.  Still sets self.file.close_called and
+# calls self.file.file.close() before the exception
+raise
 
 class InMemoryUploadedFile(UploadedFile):
 """
@@ -93,10 +90,12 @@
 super(InMemoryUploadedFile, self).__init__(file, name, content_type, 
size, charset)
 

Re: [Django] #11055: ImageField uploads fail at r10717

[Django]

#11055: ImageField uploads fail at r10717
---+
  Reporter:  timo  | Owner:  mitsuhiko
Status:  new   | Milestone:  1.1  
 Component:  File uploads/storage  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Unreviewed| Has_patch:  1
Needs_docs:  0 |   Needs_tests:  1
Needs_better_patch:  0 |  
---+
Changes (by aalbrecht):

 * cc: albrecht.a...@gmail.com (added)

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

Re: [Django] #11053: access to OneToOneField when null=True should return None instead of raising DoesNotExist

[Django]

#11053: access to OneToOneField when null=True should return None instead of
raising DoesNotExist
+---
  Reporter:  Harm Geerts   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Database layer (models, ORM)   |   Version:  SVN   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Harm Geerts ):

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

Comment:

 I thought I had looked over existing tickets but it seems I missed one.
 dupe of #10227

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

Re: [Django] #10032: ORM switches incorrectly to OUTER JOIN in certain cases with isnull=True

[Django]

#10032: ORM switches incorrectly to OUTER JOIN in certain cases with isnull=True
---+
  Reporter:  gabor | Owner:  nobody
Status:  closed| Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:  wontfix   |  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by gabor):

 * cc: ga...@nekomancer.net (added)

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

Re: [Django] #10955: `select_related()` doesn't work with proxy models.

[Django]

#10955: `select_related()` doesn't work with proxy models.
---+
  Reporter:  mrmachine | Owner:  jacob  
   
Status:  assigned  | Milestone:  1.1
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  proxy 
model select_related
 Stage:  Unreviewed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by mitsuhiko):

 * cc: mitsuhiko (added)

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

Re: [Django] #10404: ImageField: height_field and width_field option sometimes doesn't work

[Django]

#10404: ImageField: height_field and width_field option sometimes doesn't work
---+
  Reporter:  Lehich| Owner:  jacob  
  
Status:  assigned  | Milestone:  1.1
  
 Component:  File uploads/storage  |   Version:  SVN
  
Resolution:|  Keywords:  ImageField, 
height_field, width_field
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by mitsuhiko):

 * cc: mitsuhiko (added)

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

Re: [Django] #10953: Proxy model of a proxy model is of incorrect type.

[Django]

#10953: Proxy model of a proxy model is of incorrect type.
---+
  Reporter:  mrmachine | Owner:  jacob  
   
Status:  assigned  | Milestone:  1.1
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  proxy type 
foreign key
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by jacob):

  * owner:  mitsuhiko => jacob
  * status:  new => assigned

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

Re: [Django] #10955: `select_related()` doesn't work with proxy models.

[Django]

#10955: `select_related()` doesn't work with proxy models.
---+
  Reporter:  mrmachine | Owner:  jacob  
   
Status:  assigned  | Milestone:  1.1
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  proxy 
model select_related
 Stage:  Unreviewed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by jacob):

  * owner:  mitsuhiko => jacob
  * status:  new => assigned

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

Re: [Django] #10404: ImageField: height_field and width_field option sometimes doesn't work

[Django]

#10404: ImageField: height_field and width_field option sometimes doesn't work
---+
  Reporter:  Lehich| Owner:  jacob  
  
Status:  assigned  | Milestone:  1.1
  
 Component:  File uploads/storage  |   Version:  SVN
  
Resolution:|  Keywords:  ImageField, 
height_field, width_field
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by jacob):

  * owner:  mitsuhiko => jacob
  * status:  new => assigned

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