date:20110813

Re: [Django] #15838: assertFieldOutput should be integrated to the general test framework

2011-08-13 Thread Django

#15838: assertFieldOutput should be integrated to the general test framework
-+-
   Reporter:  julien |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


Comment:

 Awesome! Probably worth mentioning in the release notes too.

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

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

[Django] #16628: Provide a class to hold application-based settings

2011-08-13 Thread Django

#16628: Provide a class to hold application-based settings
-+--
 Reporter:  AzMoo|  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Core (Other)
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  1|  Easy pickings:  0
UI/UX:  0|
-+--
 When developing a portable application it would be useful to have a simple
 way to access the project settings first and fall back to an application-
 based settings module for defaults.

 Application developers can create a settings.py module in the application
 and instantiate settings using the ApplicationSettingsHolder.

 Example:

 {{{
 #!div style="font-size: 80%"
 !__init!__.py:
   {{{#!python
   from django.conf import ApplicationSettingsHolder

   settings = ApplicationSettingsHolder('myapp.settings')
   }}}
 access settings with:
   {{{#!python
   from myapp import settings
   }}}
 }}}

-- 
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] #2443: Add IntervalField to database models

2011-08-13 Thread Django

#2443: Add IntervalField to database models
-+-
   Reporter: |  Owner:  Adys
  ben.tucker@…   | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  IntervalField
 Resolution: |  interval duration DurationField
   Triage Stage:  Accepted   |  feature
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  1
  UI/UX:  1  |  Easy pickings:  0
-+-
Changes (by anonymous):

 * ui_ux:  0 => 1


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

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

Re: [Django] #2443: Add IntervalField to database models

2011-08-13 Thread Django

#2443: Add IntervalField to database models
-+-
   Reporter: |  Owner:  Adys
  ben.tucker@…   | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  IntervalField
 Resolution: |  interval duration DurationField
   Triage Stage:  Accepted   |  feature
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by Karen Rustad):

 * ui_ux:   => 0


Comment:

 This is a vote to get a DurationField (or whatever you want to call it)
 into Django 1.4. I'm currently running into this problem in that I need to
 represent an iteration length in some task management software I'm
 writing, where the length is set by the user and could be anything from a
 week to a month to a couple months (even more hilarity since months aren't
 consistent lengths). Of course, timedeltas are super-conveniently built
 into Python and can handle all of this in a snap...but in Django I have no
 way to store them. It's driving me nuts.

 Like, come on. If Django is Python, timedelta needs a model field.
 Without, it's incomplete.

-- 
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] #11665: django.test.TestCase should flush constraints

2011-08-13 Thread Django

#11665: django.test.TestCase should flush constraints
+---
   Reporter:  Glenn |  Owner:
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by jsdalton):

 Patch wasn't applying cleanly so I fixed it up a bit.

 With this patch, I'm currently one test error (#16592) away from all tests
 passing on 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] #16626: login_required attribute in class-based Generic Views

2011-08-13 Thread Django

#16626: login_required attribute in class-based Generic Views
-+-
   Reporter:  szczav |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  Generic views
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  login_required
 Resolution: |  decorator view generic views
  worksforme |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 I'm not in favor of tying the generic views to the auth framework. If we
 add a special case for `login_required`, the next question is obviously
 going to be about `permission_required('foo.bar')`. Clearly, it isn't
 desireable to duplicate the auth API in the generic views.

 What about defining your view like this:
 {{{
 class MyView(...):
 # this is a generic view
 ...

 my_view = login_required(MyView.as_view())
 }}}
 and using `my_view` in your URLconf?

 If you have many generic views that should be decorated with login
 required, an alternative is to implement a mixin, like this:
 {{{
 class LoginRequiredMixin(object):
 def as_view(cls):
 return login_required(super(LoginRequiredMixin, cls).as_view())

 class MyView(LoginRequiredMixin, ...):
 # this is a generic view
 ...
 }}}
 and use `MyView.as_view()` is your URLconf.

-- 
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] #4102: Allow UPDATE of only specific fields in model.save()

2011-08-13 Thread Django

#4102: Allow UPDATE of only specific fields in model.save()
-+-
   Reporter:  Collin |  Owner:  cgrady
  Grady    | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  update fields sql
 Resolution: |  row table modified
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by akaariai):

 Correcting myself: Actually, I do think this works with deferred
 attributes, the deferred loading of attributes accesses directly the
 `__dict__` of the instance, and if the attribute has not been accessed,
 save() will not access it. This is actually a big plus to this feature: if
 one uses .only() to load just the attributes needed in data manipulation
 and then saves the object back, things work as expected. Currently all the
 deferred attributes will be fetched before save, one at a time if I am not
 mistaken...

 On the other hand, there is a minor backwards incompatibility. The
 following is valid at the moment (although not necessarily very wise thing
 to do):

 {{{
 # Lets fetch an object and update another object with it's data.
 m = M.objects.get(pk=1)
 m.pk = 2 # assume pk = 2 is in the DB.
 m.save() # Old code would have updated all attributes, new code doesn't.
 }}}

 This could be fixed by setting all attrs as changed when the pk has
 changed.

-- 
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] #15838: assertFieldOutput should be integrated to the general test framework

2011-08-13 Thread Django

#15838: assertFieldOutput should be integrated to the general test framework
---+---
   Reporter:  julien   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Testing framework
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by ramiro):

 * has_patch:  0 => 1
 * ui_ux:   => 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.

Re: [Django] #2259: PK Change creates new object instead of update

2011-08-13 Thread Django

#2259: PK Change creates new object instead of update
-+-
   Reporter:  ed@…   |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  contrib.admin
Version: |   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  0
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)
 * has_patch:  0 => 1
 * ui_ux:   => 0
 * easy:   => 0


Comment:

 I know this is unlikely to get accepted because of backwards compatibility
 reasons, but here goes anyways.

 The attached patch implements a version of save_base that automatically
 does the following things when the PK has been changed since last loaded
 from the DB:
   - If there is already a row with the new pk and force_update is not set,
 it errors out.
   - If there is already a row with the new pk and force_update is set it
 updates the row with the new pk and leaves the old pk alone.
   - If there is no row with new or old pk, it inserts a new row.
   - If pk has not been changed, everything works as always.
   - The only way (without resorting to undocumented features) to get a pk
 update is to use a model that comes from DB. save() counts as come from
 DB.

 The above tries to be intelligent and do the right thing. The current code
 also tries to be intelligent and do the right thing, but IMHO it fails
 when the PK has been changed. What it does is not what one would expect.
 On the other hand the specification of what save() does is very clear. I
 think the problem here is that we have the single method save() which
 should always do the right thing. With changing PKs it is not entirely
 clear what the right thing is.

 Other possible ways to solve this ticket is to make a new method or to add
 additional optional parameters to save. In this case I think .save()
 without force_update or force_insert should raise an Error if the primary
 key has changed.

 The biggest backwards incompatibility is this (present also in Django test
 suite):
 {{{
 Lets save some objects:
 obj = T()
 t.pk = 123
 t.name = 'foob'
 t.save()
 t.pk = 456
 t.name = 'faab'
 t.save()
 # Or better yet, do that in loop...
 }}}

 Old code would have saved two objects, the new code updates the first
 saved. So as is this patch has no change to get in. On the other hand,
 if/when composite primary keys are going to be included in Django, the
 current save() is going to cause a lot of wondering...

-- 
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] #16393: CookieWizard incompatible with simlejson 2.0.9

2011-08-13 Thread Django

#16393: CookieWizard incompatible with simlejson 2.0.9
+---
   Reporter:  kmtracey  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.formtools
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by steph):

 The patch fixes the failing tests but doesn't add new tests for the exact
 problem.

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

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

Re: [Django] #16592: In MySQL, table names in unmanaged intermediate models are being lower cased

2011-08-13 Thread Django

#16592: In MySQL, table names in unmanaged intermediate models are being lower
cased
+---
   Reporter:  jsdalton  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  mysql
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by jsdalton):

 I went ahead and added an admonition to use lowercase table names, as well
 as a few sentences noting the problematic behavior in MySQL when using
 mixed case table names. Patch attached.

-- 
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] #16622: django.test.TestCase slow using PostgreSQL 8.4.4

2011-08-13 Thread Django

#16622: django.test.TestCase slow using PostgreSQL 8.4.4
--+---
   Reporter:  valhallasw  |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---

Comment (by ramiro):

 Sorry, posted last comment when I was too tired so it lacked details,
 should have made clear my testing conditions: A simple app and a !TestCase
 with only one test method:
 {{{
 from django.db import models

 class Person(models.Model):
 age = models.IntegerField()
 }}}
 {{{
 from django.test import TestCase

 from models import Person


 class SimpleTest(TestCase):
 def test_a(self):
 self.assertEqual(0, Person.objects.filter(age=42).count())

 # added afterwards:
 #def test_b(self):
 #self.assertEqual(0, Person.objects.filter(pk=314).count())

 }}}

 Now (just in case, even when `manage.py test` already runs tests of all
 django.contrib apps listed in INSTALLED_APPS), I've added another test
 method and another similar simple app with its own tests. But number of
 TRUNCATE operation stays at one here (most surely because of this
 
[https://code.djangoproject.com/browser/django/trunk/django/db/backends/creation.py#L241
 `flush` operation] added in these commits.)

 Count me as also confused on why valhallasw sees it once per test.

-- 
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] #6644: FormPreview doesn't pass tests

2011-08-13 Thread Django

#6644: FormPreview doesn't pass tests
-+-
   Reporter: |Owner:  simeon
  alfred.einstein@…  |   Status:  closed
   Type:  Bug|Component:  contrib.formtools
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:
 Resolution:  fixed  |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16616]:
 {{{
 #!CommitTicketReference repository="" revision="16616"
 Fixed #6644 -- Fixed django.contrib.formtools tests to be better isolated
 when running outside of the Django test suite. Also moved around the new
 wizard's templates a bit to better fit the common app layout.
 }}}

-- 
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] #16360: Add a standard entrypoint for WSGI to project template

2011-08-13 Thread Django

#16360: Add a standard entrypoint for WSGI to project template
---+--
   Reporter:  jezdez   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Core (Other)
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--

Comment (by aaugustin):

 This review is based on code inspection of the branch at
 https://github.com/jezdez/django/compare/feature/wsgi in its current
 state.


 '''django/conf/global_settings.py'''

 Isn't the default `'django.core.handlers.wsgi.application'` rather than
 `'django.core.handlers.wsgi.WSGIHandler'`?


 '''django/conf/project_template/settings.py'''

 No other setting in this file is commented out. In this regard,
 `WSGI_APPLICATION` looks inconsistent. New Django projects using this
 template for `settings.py` will also have `wsgi.py`, so it would be
 logical and consistent to uncomment this line.

 I wondered if this setting is actually useful. I concluded it is, because
 it makes the location of the WSGI application explicit, and because people
 may run different websites one the same codebase with different WSGI
 entrypoints. The argument is less compelling than for `ROOT_URLCONF` but I
 guess it could happen.

 I'm not sure if "for using" is correct, I'd write "to use" instead.


 '''django/conf/project_template/wsgi.py'''

 I think the docstring should be moved to the documentation — as far as I
 can tell, the docs aren't written yet. (Do you want help writing them?)

 (minor) The "Make sure..." sentence isn't necessary if `WSGI_APPLICATION`
 is set by default (see above).

 The comment about using '{{ project_name }}.settings' is misleading,
 because `setup_environ` will honor `os.environ['DJANGO_SETTINGS_MODULE']`.

 Also, the code will fail if there is no `settings` module on `PYTHONPATH`.
 Isn't it possible to make it work, provided `DJANGO_SETTINGS_MODULE` is
 set? Based on
 https://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/ it looks
 like it's possible.


 '''django/contrib/staticfiles/management/commands/runserver.py'''

 (minor) I think:
 {{{
 enabled = (settings.DEBUG and use_static_handler or
 (use_static_handler and insecure_serving))
 }}}
 would be more readable as:
 {{{
 enabled = use_static_handler and (settings.DEBUG or insecure_serving)
 }}}


 '''django/core/handlers/wsgi.py'''

 Line 322 looks wrong: it returns `self._instance` instead of
 `self._instance(environ, start_response)`.

 I suppose you first check `if self._instance is not None` to avoid the
 performance hit of taking the lock; this optimization should be explained
 in a quick comment.

 I think the whole function would be more easier to understand like this:

 {{{
 # Non-atomic check, avoids taking a lock at each call of this method
 if self._instance is None:
 with self._instance_lock:
 # Atomic check, prevents concurrent initialization of
 self._instance
 if self._instance is None:
 # ... initialize self._instance  ...
 return self._instance(environ, start_response)
 }}}

-- 
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] #10343: Need a way to access widgets individually contained within a MultiWidget

2011-08-13 Thread Django

#10343: Need a way to access widgets individually contained within a MultiWidget
-+-
   Reporter: |  Owner:  nobody
  chewinggumking | Status:  new
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone: |   Keywords:  widgets
Version:  1.0|  SplitDateTimeF
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

 * ui_ux:   => 0
 * component:  contrib.formtools => Forms
 * easy:   => 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.

Re: [Django] #4102: Allow UPDATE of only specific fields in model.save()

2011-08-13 Thread Django

#4102: Allow UPDATE of only specific fields in model.save()
-+-
   Reporter:  Collin |  Owner:  cgrady
  Grady    | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  update fields sql
 Resolution: |  row table modified
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)
 * needs_better_patch:  0 => 1


Comment:

 Some quick notes:
   - I don't think this works when using deferred field loading
   - The _modified_attrs should go to the model._state, not directly to the
 model
   - The _state.adding should maybe play a part in this. What about: if we
 are adding, then every field has changed by default? Maybe this is not so
 hot idea, but could be worth exploring.
   - There is a trick one can use to speed up model `__init__`:
 {{{
 # Pseudocode

 class Model():
 def __setattr__(args):
 ...
 _my_setattr = __setattr__

 def __init__(self, ...):
 # Check if inheriting class has defined a __setattr__ method
 if self._my_setattr == self.__setattr__:
 # If not, we can skip our own __setattr__ and use
 # directly the super __setattr__
 _set = super(Model, self).__setattr__
 else:
 # We need to call the __setattr__ defined in inheriting class
 # (backwards compatibility).
 _set = self.__setattr__
 ...
 for field, val in izip(fields, args):
 _set(self, field.attname, val)
 ...

 }}}

 This way if there is no overriding `__setattr__` there is almost no speed
 loss in Model's `__init__`. On the other hand this is a dirty trick that
 could easily bite...

 Also a check could be done to guard against overriding `__setattr__` doing
 direct `__dict__` manipulation and not calling our `__setattr__`. On
 Django startup create a instance of every Model class and see if a
 modification registers to _modified_attrs. If not, raise an Exception.
 Python documentation says that `__setattr__` should call the base
 `__setattr__` for new style classes, but it is a safe bet that there are
 users who do not do that.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] r16615 - in django/trunk: . docs/ref docs/ref/contrib docs/ref/contrib/admin docs/ref/contrib/formtools docs/ref/contrib/gis docs/ref/forms docs/releases docs/topics/forms

2011-08-13 Thread noreply

Author: jezdez
Date: 2011-08-13 04:58:19 -0700 (Sat, 13 Aug 2011)
New Revision: 16615

Modified:
   django/trunk/AUTHORS
   django/trunk/docs/ref/contrib/admin/index.txt
   django/trunk/docs/ref/contrib/csrf.txt
   django/trunk/docs/ref/contrib/flatpages.txt
   django/trunk/docs/ref/contrib/formtools/form-wizard.txt
   django/trunk/docs/ref/contrib/gis/deployment.txt
   django/trunk/docs/ref/contrib/gis/gdal.txt
   django/trunk/docs/ref/contrib/gis/geoquerysets.txt
   django/trunk/docs/ref/contrib/gis/install.txt
   django/trunk/docs/ref/contrib/localflavor.txt
   django/trunk/docs/ref/forms/fields.txt
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/releases/1.2-alpha-1.txt
   django/trunk/docs/releases/1.2.txt
   django/trunk/docs/topics/forms/modelforms.txt
Log:
Fixed #16621 -- Fixed lots of typos in the docs. Thanks, Bernhard Essl.

Modified: django/trunk/AUTHORS
===
--- django/trunk/AUTHORS2011-08-13 11:53:42 UTC (rev 16614)
+++ django/trunk/AUTHORS2011-08-13 11:58:19 UTC (rev 16615)
@@ -172,6 +172,7 @@
 er...@win.tue.nl
 Tomáš Ehrlich 
 Dirk Eschler 
+Bernhard Essl 
 Dan Fairs 
 Marc Fargas 
 Szilveszter Farkas 

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2011-08-13 11:53:42 UTC 
(rev 16614)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2011-08-13 11:58:19 UTC 
(rev 16615)
@@ -985,7 +985,7 @@
 .. versionadded:: 1.4
 
 The ``get_ordering`` method takes a``request`` as parameter and
-is expected to return a ``list`` or ``tuple`` for ordering similiar
+is expected to return a ``list`` or ``tuple`` for ordering similar
 to the :attr:`ordering` attribute. For example::
 
 class PersonAdmin(ModelAdmin):

Modified: django/trunk/docs/ref/contrib/csrf.txt
===
--- django/trunk/docs/ref/contrib/csrf.txt  2011-08-13 11:53:42 UTC (rev 
16614)
+++ django/trunk/docs/ref/contrib/csrf.txt  2011-08-13 11:58:19 UTC (rev 
16615)
@@ -417,7 +417,7 @@
 Default: ``None``
 
 The domain to be used when setting the CSRF cookie.  This can be useful for
-easily allowing cross-subdomain requests to be exluded from the normal cross
+easily allowing cross-subdomain requests to be excluded from the normal cross
 site request forgery protection.  It should be set to a string such as
 ``".lawrence.com"`` to allow a POST request from a form on one subdomain to be
 accepted by accepted by a view served from another subdomain.

Modified: django/trunk/docs/ref/contrib/flatpages.txt
===
--- django/trunk/docs/ref/contrib/flatpages.txt 2011-08-13 11:53:42 UTC (rev 
16614)
+++ django/trunk/docs/ref/contrib/flatpages.txt 2011-08-13 11:58:19 UTC (rev 
16615)
@@ -85,7 +85,7 @@
subsequently raise a 404.
 
 .. versionchanged:: 1.4
-   Redirects by the middlware are permanent (301 status code) instead of
+   Redirects by the middleware are permanent (301 status code) instead of
temporary (302) to match behavior of the
:class:`~django.middleware.common.CommonMiddleware`.
 

Modified: django/trunk/docs/ref/contrib/formtools/form-wizard.txt
===
--- django/trunk/docs/ref/contrib/formtools/form-wizard.txt 2011-08-13 
11:53:42 UTC (rev 16614)
+++ django/trunk/docs/ref/contrib/formtools/form-wizard.txt 2011-08-13 
11:58:19 UTC (rev 16615)
@@ -100,7 +100,7 @@
 in the :doc:`sessions documentation ` on
 how to enable sessions.
 
-We will use the :class:`SessionWizardView` in all examples but is is completly
+We will use the :class:`SessionWizardView` in all examples but is is completely
 fine to use the :class:`CookieWizardView` instead. As with your
 :class:`~django.forms.Form` classes, this :class:`WizardView` class can live
 anywhere in your codebase, but convention is to put it in :file:`views.py`.
@@ -263,8 +263,8 @@
 .. method:: WizardView.get_form_initial(step)
 
 Returns a dictionary which will be passed to the form for ``step`` as
-``initial``. If no initial data was provied while initializing the
-form wizard, a empty dictionary should be returned.
+``initial``. If no initial data was provided while initializing the
+form wizard, an empty dictionary should be returned.
 
 The default implementation::
 
@@ -283,8 +283,8 @@
 
 .. method:: WizardView.get_form_instance(step)
 
-Returns a object which will be passed to the form for ``step`` as
-``instance``. If no instance object was provied while initializing
+Returns an object which

Re: [Django] #16621: typos in documentation

2011-08-13 Thread Django

#16621: typos in documentation
-+-
   Reporter: |  Owner:  nobody
  BernhardEssl   | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16615]:
 {{{
 #!CommitTicketReference repository="" revision="16615"
 Fixed #16621 -- Fixed lots of typos in the docs. Thanks, Bernhard Essl.
 }}}

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

2011-08-13 Thread noreply

Author: jezdez
Date: 2011-08-13 04:53:42 -0700 (Sat, 13 Aug 2011)
New Revision: 16614

Modified:
   django/trunk/django/db/models/fields/__init__.py
   django/trunk/tests/regressiontests/model_fields/models.py
   django/trunk/tests/regressiontests/model_fields/tests.py
Log:
Fixed #14695 -- Stopped model fields from incorrectly overwriting the field 
name during model initialization if it was already passed as a keyword 
argument. Thanks, erikrose and willhardy.

Modified: django/trunk/django/db/models/fields/__init__.py
===
--- django/trunk/django/db/models/fields/__init__.py2011-08-13 11:53:33 UTC 
(rev 16613)
+++ django/trunk/django/db/models/fields/__init__.py2011-08-13 11:53:42 UTC 
(rev 16614)
@@ -220,15 +220,16 @@
 except KeyError:
 return None
 
+@property
 def unique(self):
 return self._unique or self.primary_key
-unique = property(unique)
 
 def set_attributes_from_name(self, name):
-self.name = name
+if not self.name:
+self.name = name
 self.attname, self.column = self.get_attname_column()
-if self.verbose_name is None and name:
-self.verbose_name = name.replace('_', ' ')
+if self.verbose_name is None and self.name:
+self.verbose_name = self.name.replace('_', ' ')
 
 def contribute_to_class(self, cls, name):
 self.set_attributes_from_name(name)

Modified: django/trunk/tests/regressiontests/model_fields/models.py
===
--- django/trunk/tests/regressiontests/model_fields/models.py   2011-08-13 
11:53:33 UTC (rev 16613)
+++ django/trunk/tests/regressiontests/model_fields/models.py   2011-08-13 
11:53:42 UTC (rev 16614)
@@ -66,6 +66,9 @@
 bfield = models.BooleanField()
 string = models.CharField(max_length=10, default='abc')
 
+class RenamedField(models.Model):
+modelname = models.IntegerField(name="fieldname", choices=((1,'One'),))
+
 ###
 # FileField
 

Modified: django/trunk/tests/regressiontests/model_fields/tests.py
===
--- django/trunk/tests/regressiontests/model_fields/tests.py2011-08-13 
11:53:33 UTC (rev 16613)
+++ django/trunk/tests/regressiontests/model_fields/tests.py2011-08-13 
11:53:42 UTC (rev 16614)
@@ -8,7 +8,7 @@
 from django.db.models.fields.files import FieldFile
 from django.utils import unittest
 
-from models import Foo, Bar, Whiz, BigD, BigS, Image, BigInt, Post, 
NullBooleanModel, BooleanModel, Document
+from models import Foo, Bar, Whiz, BigD, BigS, Image, BigInt, Post, 
NullBooleanModel, BooleanModel, Document, RenamedField
 
 # If PIL available, do these tests.
 if Image:
@@ -53,6 +53,15 @@
 f = models.fields.CharField()
 self.assertEqual(repr(f), '')
 
+def test_field_name(self):
+"""
+Regression test for #14695: explicitly defined field name overwritten
+by model's attribute name.
+"""
+instance = RenamedField()
+self.assertTrue(hasattr(instance, 'get_fieldname_display'))
+self.assertFalse(hasattr(instance, 'get_modelname_display'))
+
 class DecimalFieldTests(test.TestCase):
 def test_to_python(self):
 f = models.DecimalField(max_digits=4, decimal_places=2)

-- 
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] #14695: Field's `name` kwarg gets paved over

2011-08-13 Thread Django

#14695: Field's `name` kwarg gets paved over
-+-
   Reporter:  erikrose   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:  dceu2011
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16614]:
 {{{
 #!CommitTicketReference repository="" revision="16614"
 Fixed #14695 -- Stopped model fields from incorrectly overwriting the
 field name during model initialization if it was already passed as a
 keyword argument. Thanks, erikrose and willhardy.
 }}}

-- 
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] #16613: manage.py test fails on database creation (MySQL)

2011-08-13 Thread Django

#16613: manage.py test fails on database creation (MySQL)
-+-
   Reporter:  Stan   |  Owner:  nobody
     | Status:  closed
   Type:  Bug|  Component:  Uncategorized
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16613]:
 {{{
 #!CommitTicketReference repository="" revision="16613"
 Fixed #16613 -- Fixed test for introspected foreign keys in the MySQL
 backend if ANSI_QUOTES SQL mode is enabled. Thanks, Stan.
 }}}

-- 
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] r16613 - django/trunk/django/db/backends/mysql

2011-08-13 Thread noreply

Author: jezdez
Date: 2011-08-13 04:53:33 -0700 (Sat, 13 Aug 2011)
New Revision: 16613

Modified:
   django/trunk/django/db/backends/mysql/base.py
Log:
Fixed #16613 -- Fixed test for introspected foreign keys in the MySQL backend 
if ANSI_QUOTES SQL mode is enabled. Thanks, Stan.

Modified: django/trunk/django/db/backends/mysql/base.py
===
--- django/trunk/django/db/backends/mysql/base.py   2011-08-13 11:25:57 UTC 
(rev 16612)
+++ django/trunk/django/db/backends/mysql/base.py   2011-08-13 11:53:33 UTC 
(rev 16613)
@@ -143,7 +143,7 @@
 # will tell you the default table type of the created
 # table. Since all Django's test tables will have the same
 # table type, that's enough to evaluate the feature.
-cursor.execute('SHOW TABLE STATUS WHERE Name="INTROSPECT_TEST"')
+cursor.execute("SHOW TABLE STATUS WHERE Name='INTROSPECT_TEST'")
 result = cursor.fetchone()
 cursor.execute('DROP TABLE INTROSPECT_TEST')
 return result[1] != 'MyISAM'

-- 
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] #16606: Typo in csrf docs

2011-08-13 Thread Django

#16606: Typo in csrf docs
-+-
   Reporter:  selwin |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by timo):

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


Comment:

 In [16612]:
 {{{
 #!CommitTicketReference repository="" revision="16612"
 Fixed #16606 - Typo in docs/ref/contrib/csrf.txt; thanks selwin.
 }}}

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

2011-08-13 Thread noreply

Author: timo
Date: 2011-08-13 04:25:57 -0700 (Sat, 13 Aug 2011)
New Revision: 16612

Modified:
   django/trunk/docs/ref/contrib/csrf.txt
Log:
Fixed #16606 - Typo in docs/ref/contrib/csrf.txt; thanks selwin.

Modified: django/trunk/docs/ref/contrib/csrf.txt
===
--- django/trunk/docs/ref/contrib/csrf.txt  2011-08-13 11:23:13 UTC (rev 
16611)
+++ django/trunk/docs/ref/contrib/csrf.txt  2011-08-13 11:25:57 UTC (rev 
16612)
@@ -31,7 +31,7 @@
 1. Add the middleware
``'django.middleware.csrf.CsrfViewMiddleware'`` to your list of
middleware classes, :setting:`MIDDLEWARE_CLASSES`.  (It should come
-   and before any view middleware that assume that CSRF attacks have
+   before any view middleware that assume that CSRF attacks have
been dealt with.)
 
Alternatively, you can use the decorator

-- 
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] #16627: Warning when building the docs

2011-08-13 Thread Django

#16627: Warning when building the docs
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16611]:
 {{{
 #!CommitTicketReference repository="" revision="16611"
 Fixed #16627 -- Fixed docs build warning.
 }}}

-- 
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] r16611 - django/trunk/docs/topics/http

2011-08-13 Thread noreply

Author: jezdez
Date: 2011-08-13 04:23:13 -0700 (Sat, 13 Aug 2011)
New Revision: 16611

Modified:
   django/trunk/docs/topics/http/views.txt
Log:
Fixed #16627 -- Fixed docs build warning.

Modified: django/trunk/docs/topics/http/views.txt
===
--- django/trunk/docs/topics/http/views.txt 2011-08-13 00:42:08 UTC (rev 
16610)
+++ django/trunk/docs/topics/http/views.txt 2011-08-13 11:23:13 UTC (rev 
16611)
@@ -201,7 +201,7 @@
 .. _http_forbidden_view:
 
 The 403 (HTTP Forbidden) view
-
+-
 
 .. versionadded:: 1.4
 

-- 
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] #16591: Bad reference to YEAR_CHOICES

2011-08-13 Thread Django

#16591: Bad reference to YEAR_CHOICES
-+-
   Reporter: |  Owner:  elbarto
  santi.romero@… | Status:  new
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  example, reference,
 Resolution: |  name
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by julien):

 Note when committing: instances of "favourite" could be replaced with
 "favorite" :-)

-- 
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] #16627: Warning when building the docs

2011-08-13 Thread Django

#16627: Warning when building the docs
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * stage:  Unreviewed => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16627: Warning when building the docs

2011-08-13 Thread Django

#16627: Warning when building the docs
---+-
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Milestone: |Component:  Documentation
  Version:  1.3| Severity:  Normal
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-
 {{{
 docs/topics/http/views.txt:204: (WARNING/2) Title underline too short.

 The 403 (HTTP Forbidden) view
 
 }}}

-- 
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] #16591: Bad reference to YEAR_CHOICES

2011-08-13 Thread Django

#16591: Bad reference to YEAR_CHOICES
-+-
   Reporter: |  Owner:  elbarto
  santi.romero@… | Status:  new
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  example, reference,
 Resolution: |  name
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15095: django-admin.py createconfig /path/to/settings.py

2011-08-13 Thread Django

#15095: django-admin.py createconfig /path/to/settings.py
-+-
   Reporter: |  Owner:  nobody
  frankwiles | Status:  new
   Type:  New|  Component:  Core (Management
  feature|  commands)
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by anonymous):

 * ui_ux:   => 0
 * easy:  1 => 0


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

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

Re: [Django] #16622: django.test.TestCase slow using PostgreSQL 8.4.4

2011-08-13 Thread Django

#16622: django.test.TestCase slow using PostgreSQL 8.4.4
--+---
   Reporter:  valhallasw  |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---

Comment (by valhallasw):

 I am seeing a `TRUNCATE` for every single test case. I will try to do some
 more debugging this weekend to see why exactly the `TRUNCATE` is called.
 In any case, thanks for your comments.

-- 
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] #16393: CookieWizard incompatible with simlejson 2.0.9

2011-08-13 Thread Django

#16393: CookieWizard incompatible with simlejson 2.0.9
+---
   Reporter:  kmtracey  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.formtools
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by jezdez):

 * component:  Forms => contrib.formtools


-- 
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] #16393: CookieWizard incompatible with simlejson 2.0.9

2011-08-13 Thread Django

#16393: CookieWizard incompatible with simlejson 2.0.9
+
   Reporter:  kmtracey  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Forms
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+

Comment (by jezdez):

 Replying to [comment:3 kmtracey]:
 > This is pdb info from a session where simplejson 2.0.9 was installed. I
 added breakpoints to the django/contrib/formtools/wizard/storage/cookie.py
 file, methods load_data and update_response to see what was getting stored
 in the cookie and what was subsequently loaded:
 >
 > {{{
 > --> ./runtests.py --settings=testdb.sqlite -v0
 formtools.CookieWizardTests.test_cleaned_data
 > > /home/kmtracey/django/hg-
 django/django/contrib/formtools/wizard/storage/cookie.py(32)update_response()
 > -> response.set_signed_cookie(self.prefix,
 self.encoder.encode(self.data))
 > (Pdb) self.data
 > {'step_files': {}, 'step': u'form1', 'extra_data': {}, 'step_data': {}}
 > (Pdb) c
 > > /home/kmtracey/django/hg-
 django/django/contrib/formtools/wizard/storage/cookie.py(27)load_data()
 > -> return json.loads(data, cls=json.JSONDecoder)
 > (Pdb) n
 > --Return--
 > > /home/kmtracey/django/hg-
 
django/django/contrib/formtools/wizard/storage/cookie.py(27)load_data()->{u'extra_data':
 {}, u'step': u'form1', u'step_data': {}, u'step_files': {}}
 > -> return json.loads(data, cls=json.JSONDecoder)
 >
 > # No problem above, first calls to store/load the cookie data have no
 data that causes a problem
 >
 > # Next iteration is where there's a problem. The step_data for form1 is
 a QueryDict
 >
 > (Pdb) c
 > > /home/kmtracey/django/hg-
 django/django/contrib/formtools/wizard/storage/cookie.py(32)update_response()
 > -> response.set_signed_cookie(self.prefix,
 self.encoder.encode(self.data))
 > (Pdb) self.data
 > {u'step_files': {u'form1': {}}, u'step': u'form2', u'extra_data': {},
 u'step_data': {u'form1': }}
 > (Pdb) self.data['step_data']['form1']
 > 
 > (Pdb) c
 > > /home/kmtracey/django/hg-
 django/django/contrib/formtools/wizard/storage/cookie.py(27)load_data()
 > -> return json.loads(data, cls=json.JSONDecoder)
 > (Pdb) n
 > --Return--
 > > /home/kmtracey/django/hg-
 
django/django/contrib/formtools/wizard/storage/cookie.py(27)load_data()->{u'extra_data':
 {}, u'step': u'form2', u'step_data': {u'form1': {u'cookie...ent_step':
 [u'form1'], u'form1-name': [u'Pony'], u'form1-thirsty': [u'2'],
 u'form1-user': [u'1']}}, u'step_files': {u'form1': {}}}
 > -> return json.loads(data, cls=json.JSONDecoder)
 > (Pdb) n
 >
 > # When step_data for form1 is re-constituted, the values for all the
 keys are wrapped in lists
 > # This ultimately triggers errors like: TypeError: int() argument must
 be a string or a number, not 'list'
 > # when the wizard code uses the re-constituted step data as data for the
 form.
 >
 > > /home/kmtracey/django/hg-
 django/django/contrib/formtools/wizard/storage/cookie.py(14)__init__()
 > -> if self.data is None:
 > (Pdb) self.data['step_data']['form1']
 > {u'form1-user': [u'1'], u'cookie_contact_wizard-current_step':
 [u'form1'], u'form1-name': [u'Pony'], u'form1-thirsty': [u'2']}
 > (Pdb)
 > }}}
 >
 > This is with simplejson 2.1.6 installed:
 >
 > {{{
 > --> ./runtests.py --settings=testdb.sqlite -v0
 formtools.CookieWizardTests.test_cleaned_data
 > > /home/kmtracey/django/hg-
 django/django/contrib/formtools/wizard/storage/cookie.py(32)update_response()
 > -> response.set_signed_cookie(self.prefix,
 self.encoder.encode(self.data))
 > (Pdb) c
 > > /home/kmtracey/django/hg-
 django/django/contrib/formtools/wizard/storage/cookie.py(27)load_data()
 > -> return json.loads(data, cls=json.JSONDecoder)
 > (Pdb) c
 > > /home/kmtracey/django/hg-
 django/django/contrib/formtools/wizard/storage/cookie.py(32)update_response()
 > -> response.set_signed_cookie(self.prefix,
 self.encoder.encode(self.data))
 > (Pdb) self.data
 > {u'step_files': {u'form1': {}}, u'step': u'form2', u'extra_data': {},
 u'step_data': {u'form1': }}
 > (Pdb) self.data['step_data']['form1']
 > 
 > (Pdb) c
 > > /home/kmtracey/django/hg-
 django/django/contrib/formtools/wizard/storage/cookie.py(27)load_data()
 > -> return json.loads(data, cls=json.JSONDecoder)
 > (Pdb) n
 > --Return--
 > > /home/kmtracey/django/hg-
 
django/django/contrib/formtools/wizard/storage/cookie.py(27)load_data()->{u'extra_data':
 {}, u'step': u'form2', u'step_data': {u'form1': {u'cookie...ent_step':
 u'form1', u'form1-name': u'Pony', u'form1-thirsty': u'2', u'form1-user':
 u'1'}}, u'step_files': {u'form1': {}}}
 > -> return json.loads(data,

Re: [Django] #15838: assertFieldOutput should be integrated to the general test framework

[Django] #16628: Provide a class to hold application-based settings

Re: [Django] #2443: Add IntervalField to database models

Re: [Django] #2443: Add IntervalField to database models

Re: [Django] #11665: django.test.TestCase should flush constraints

Re: [Django] #16626: login_required attribute in class-based Generic Views

Re: [Django] #4102: Allow UPDATE of only specific fields in model.save()

Re: [Django] #15838: assertFieldOutput should be integrated to the general test framework

Re: [Django] #2259: PK Change creates new object instead of update

Re: [Django] #16393: CookieWizard incompatible with simlejson 2.0.9

Re: [Django] #16592: In MySQL, table names in unmanaged intermediate models are being lower cased

Re: [Django] #16622: django.test.TestCase slow using PostgreSQL 8.4.4

Re: [Django] #6644: FormPreview doesn't pass tests

Re: [Django] #16360: Add a standard entrypoint for WSGI to project template

Re: [Django] #10343: Need a way to access widgets individually contained within a MultiWidget

Re: [Django] #4102: Allow UPDATE of only specific fields in model.save()

[Changeset] r16615 - in django/trunk: . docs/ref docs/ref/contrib docs/ref/contrib/admin docs/ref/contrib/formtools docs/ref/contrib/gis docs/ref/forms docs/releases docs/topics/forms

Re: [Django] #16621: typos in documentation

[Changeset] r16614 - in django/trunk: django/db/models/fields tests/regressiontests/model_fields

Re: [Django] #14695: Field's `name` kwarg gets paved over

Re: [Django] #16613: manage.py test fails on database creation (MySQL)

[Changeset] r16613 - django/trunk/django/db/backends/mysql

Re: [Django] #16606: Typo in csrf docs

[Changeset] r16612 - django/trunk/docs/ref/contrib

Re: [Django] #16627: Warning when building the docs

[Changeset] r16611 - django/trunk/docs/topics/http

Re: [Django] #16591: Bad reference to YEAR_CHOICES

Re: [Django] #16627: Warning when building the docs

[Django] #16627: Warning when building the docs

Re: [Django] #16591: Bad reference to YEAR_CHOICES

Re: [Django] #15095: django-admin.py createconfig /path/to/settings.py

Re: [Django] #16622: django.test.TestCase slow using PostgreSQL 8.4.4

Re: [Django] #16393: CookieWizard incompatible with simlejson 2.0.9

Re: [Django] #16393: CookieWizard incompatible with simlejson 2.0.9

34 matches

Site Navigation

Mail list logo

Footer information