Re: [Django] #15119: MySQL backend generates unnecessary commands

[Django]

#15119: MySQL backend generates unnecessary commands
-+-
   Reporter: |  Owner:  nobody
  lukesneeringer | Status:  new
   Type: |  Component:  Database layer
  Cleanup/optimization   |  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

 * easy:   => 0


Comment:

 Please look at Baron's article here:
 http://www.mysqlperformanceblog.com/2010/05/05/checking-for-a-live-
 database-connection-considered-harmful/

 I am not sure that is what you need to completely convince you, but I hope
 it is a good start.

-- 
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] #16042: comments framework uses uncached content types

[Django]

#16042: comments framework uses uncached content types
+--
 Reporter:  cdestigter  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  contrib.comments
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  1   |  Easy pickings:  1
+--
 We found our list views were doing too many database queries for content
 types, even with caching turned on.

 Turns out the comments framework is to blame, for using the uncached
 method ContentType.objects.get(...)

 This one-liner fixes it:

 {{{
 --- a/django/contrib/comments/templatetags/comments.py
 +++ b/django/contrib/comments/templatetags/comments.py
 @@ -49,7 +49,7 @@ class BaseCommentNode(template.Node):
  def lookup_content_type(token, tagname):
  try:
  app, model = token.split('.')
 -return ContentType.objects.get(app_label=app, model=model)
 +return ContentType.objects.get_by_natural_key(app, model)
  except ValueError:
  raise template.TemplateSyntaxError("Third argument in %r must
 be in the format 'app.model'" % tagname)
  except ContentType.DoesNotExist:
 }}}

-- 
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] #16007: libgdal.py needs to include 1.8.0

[Django]

#16007: libgdal.py needs to include 1.8.0
+
   Reporter:  Leo   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:  1.4   |  Component:  GIS
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
+

Comment (by Leo):

 Ah, sorry aaugustin, I thought you meant 'should be fixed' as in it's
 already been done, not 'should be fixed' as in it's something that needs
 to happen in the future :-)

-- 
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] #16007: libgdal.py needs to include 1.8.0

[Django]

#16007: libgdal.py needs to include 1.8.0
+
   Reporter:  Leo   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:  1.4   |  Component:  GIS
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
+
Changes (by Leo):

 * easy:  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.

[Django] #16041: djangoproject.com uses non-existent From address, and no way to resend confirmation email

[Django]

#16041: djangoproject.com uses non-existent From address, and no way to resend
confirmation email
-+
 Reporter:  dracos2  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Djangoproject.com Web site
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+
 Confirmation emails sent by djangoproject.com (e.g. to register) are sent
 out From: nore...@djangoproject.com - this address does not exist, and so
 any server that performs sender verification -
 http://en.wikipedia.org/wiki/Callback_verification - will not accept the
 mail for delivery. Coupled with the fact it appears to be impossible to
 have a confirmation email resent, this means the username I originally
 signed up with (dracos) is now inaccessible (I went through a password
 reset, and trying to log in at
 http://www.djangoproject.com/accounts/login/ says "Please correct the
 errors below:" with no errors listed - presumably it is wanting to say
 "This account has not been confirmed." which is not a field error.) I also
 only realised this was an issue because I had access to the mail log files
 of a server en route - others might not know why their email does not
 arrive if their ISP has implemented sender verification.

 Could noreply@ change to be an accepted email address (that either
 /dev/nulls incoming email or auto-replies saying mail to that address is
 not read) and/or could there be a way to resend a confirmation email (this
 might be useful in other circumstances 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.

Re: [Django] #16015: DecimalField allows invalid default values.

[Django]

#16015: DecimalField allows invalid default values.
-+-
   Reporter:  ShawnMilo  |  Owner:  ShawnMilo
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Design |   Keywords:
  decision needed|  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by ShawnMilo):

 Russell,

 Since there's currently no error as-is in Python 2.6 or 2.7 (unless we
 introduce the patch above), where are you suggesting that we implement the
 float_to_decimal functionality?

 Part of my confusion with this ticket is that get_default always returns a
 unicode object anyway -- for all field types. That could either be seen as
 a design flaw or as a "failsafe" because database backends all know how to
 coerce a string to the required type.

 If get_default is as it should be, then it appears that this ticket should
 be closed with 'wontfix' unless I'm missing something.

-- 
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] #16035: GZipMiddleware doesn't change an ETag

[Django]

#16035: GZipMiddleware doesn't change an ETag
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  HTTP handling
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+---

Comment (by dracos2):

 (I submitted the bug not logged in, sorry.) I've attached the same patch
 run from the right directory with svn diff this time, and also added some
 tests of the GZipMiddleware - one that tests short things aren't gzipped,
 and one to test the ETag does indeed differ for gzipped and non-gzipped
 versions. Hope that's helpful.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16010: Support Origin header checking in the CSRF middleware

[Django]

#16010: Support Origin header checking in the CSRF middleware
---+--
   Reporter:  davidben |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.csrf
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
---+--

Comment (by lukeplant):

 I'm hesitating on this, because:

 1) I think we need to worry about CSRF_COOKIE_DOMAIN - this can be set to
 allow cross-subdomain POSTs, but with this addition that would break.

 2) Which brings us to the strict referer checking to HTTPS, which doesn't
 allow for CSRF_COOKIE_DOMAIN either, but probably should - and probably
 hasn't come up so far because fewer people are using HTTPS. But I'm
 hesitating on that too, because of possible unforeseen security
 implications in the context of HTTPS.

 So, I think to start with we should make the Origin checking allow wild-
 card subdomains if CSRF_COOKIE_DOMAIN does, and docs for that setting
 should be updated accordingly. Sorry for not mentioning that earlier, it
 didn't occur to. For now, we'll leave the referer checking as it is, and
 as it is documented i.e. a simple strict referer check for HTTPS.

-- 
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] #16038: Localization of django form Field falls back to False instead of settings.USE_L10N

[Django]

#16038: Localization of django form Field falls back to False instead of
settings.USE_L10N
+
   Reporter:  jonathanslenders  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:  1.4   |  Component:  Forms
Version:  SVN   |   Severity:  Normal
 Resolution:  needsinfo |   Keywords:  l10n
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+

Comment (by jonathanslenders):

 If French was active when the form was declared (during "import forms").
 All datetime fields for following requests will render in French. (I would
 understand, if it was English, as non-localized), but not French,
 especially while the active language during a request could be German.

-- 
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] #16038: Localization of django form Field falls back to False instead of settings.USE_L10N

[Django]

#16038: Localization of django form Field falls back to False instead of
settings.USE_L10N
+
   Reporter:  jonathanslenders  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:  1.4   |  Component:  Forms
Version:  SVN   |   Severity:  Normal
 Resolution:  needsinfo |   Keywords:  l10n
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+

Comment (by jonathanslenders):

 A test case, I hope this will clarify the issue.
 -

 1. Paste following snippet in django_test_case.py
 http://dpaste.com/hold/543037/

 2. Use a django project with USE_L10N=True

 3. open shell_plus, and import django_test_case

 You will see that both forms produce a different outcome. In this case
 it's obvious where the localization comes from. What what is wrong, is
 that the form seems to be localized somehow, but the localization does not
 match the language which is active during the initialization of the form.

 From the user's perspective, I think we have two use cases:
 1. No localization: everything rendered like it's in English, or the
 default.
 2. With localization: a form renders in the language which is active at
 render-time, or during the initialization. The language that was active
 during the declaration of the form should be of no importance.
 (Form.__metaclass__ should be transparent here.)



 I'm not really satisfied with keeping 'localize=False' as the default.
 When using modelforms, do we have to specify for every single datetime
 field that we want to have localization?

 At least in DateTimeInput.__init__, don't call formats.get_format when
 self.is_localized will not be set by the form.

 Please reopen again.

 Thanks,
 Jonathan

-- 
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] #15921: naturaltime filter should only work with time, current filter should be renamed to naturaldatetime

[Django]

#15921: naturaltime filter should only work with time, current filter should be
renamed to naturaldatetime
---+--
   Reporter:  hvdklauw |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.humanize
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
---+--
Changes (by jezdez):

 * has_patch:  0 => 1


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

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

Re: [Django] #15921: naturaltime filter should only work with time, current filter should be renamed to naturaldatetime

[Django]

#15921: naturaltime filter should only work with time, current filter should be
renamed to naturaldatetime
---+--
   Reporter:  hvdklauw |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.humanize
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
---+--
Changes (by jezdez):

 * stage:  Design decision needed => Accepted


Comment:

 Yeah, that filter is really not that good (the ungettext calls aren't
 passed the arguments).

 I also agree that it should be solely a time based filter and not fall
 back to defaultfilters.date but instead to the timesince and timeuntil.

-- 
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] #16040: test.Client does not handle domain changes on redirection follow

[Django]

#16040: test.Client does not handle domain changes on redirection follow
---+---
   Reporter:  jdunck   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Uncategorized
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---
Description changed by jdunck:

Old description:

> The default SERVER_NAME used by the test client is testserver.
>
> I have a multi-tenant site serving www.foo.com and www.bar.com.  I also
> have a view which redirects from /spam/ to /eggs/.
>
> Middleware handles the domain redirection, while a view handles the
> /spam/ -> /eggs/ redirection.
>
> If the test client requests http://www.foo.com/spam/, it is redirected to
> http://www.bar.com/spam/, but _handle_redirects, while parsing url into
> scheme and path, does not also update SERVER_NAME in extras.  This causes
> the 2nd request handling to be handled as though it were for
> http://www.foo.com/spam/ (again), causing a redirection loop.
>
> I think that just as wsgi.url_scheme is updated for scheme,
> extra['SERVER_NAME'] should be updated for netloc.
>
> It's debatable to me whether this is a bug or a feature -- I realize
> multi-tenancy is relatively unusual under Django.

New description:

 The default SERVER_NAME used by the test client is testserver.

 I have a multi-tenant site serving www.foo.com and www.bar.com.  I also
 have a view which redirects from /spam/ to /eggs/.

 Middleware handles the domain redirection, while a view handles the /spam/
 -> /eggs/ redirection.

 If the test client requests http://www.foo.com/spam/, it is redirected to
 http://www.bar.com/spam/, but _handle_redirects, while parsing url into
 scheme and path, does not also update SERVER_NAME in extras.  This causes
 the 2nd request handling to be handled as though it were for
 http://www.foo.com/spam/ (again), causing a redirection loop.

 I think that just as wsgi.url_scheme is updated for scheme,
 extra!['SERVER_NAME'] should be updated for netloc.

 It's debatable to me whether this is a bug or a feature -- I realize
 multi-tenancy is relatively unusual under Django.

--

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

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

Re: [Django] #16040: test.Client does not handle domain changes on redirection follow

[Django]

#16040: test.Client does not handle domain changes on redirection follow
---+---
   Reporter:  jdunck   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Uncategorized
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---
Description changed by jdunck:

Old description:

> The default SERVER_NAME used by the test client is testserver.
>
> I have a multi-tenant site serving www.foo.com and www.bar.com.  I also
> have a view which redirects from /spam/ to /eggs/.
>
> Middleware handles the www -> m redirection, while a view handles the
> /spam/ -> /eggs/ redirection.
>
> If the test client requests http://www.foo.com/spam/, it is redirected to
> http://www.bar.com/spam/, but _handle_redirects, while parsing url into
> scheme and path, does not also update SERVER_NAME in extras.  This causes
> the 2nd request handling to be handled as though it were for
> http://www.foo.com/spam/ (again), causing a redirection loop.
>
> I think that just as wsgi.url_scheme is updated for scheme,
> extra['SERVER_NAME'] should be updated for netloc.
>
> It's debatable to me whether this is a bug or a feature -- I realize
> multi-tenancy is relatively unusual under Django.

New description:

 The default SERVER_NAME used by the test client is testserver.

 I have a multi-tenant site serving www.foo.com and www.bar.com.  I also
 have a view which redirects from /spam/ to /eggs/.

 Middleware handles the domain redirection, while a view handles the /spam/
 -> /eggs/ redirection.

 If the test client requests http://www.foo.com/spam/, it is redirected to
 http://www.bar.com/spam/, but _handle_redirects, while parsing url into
 scheme and path, does not also update SERVER_NAME in extras.  This causes
 the 2nd request handling to be handled as though it were for
 http://www.foo.com/spam/ (again), causing a redirection loop.

 I think that just as wsgi.url_scheme is updated for scheme,
 extra['SERVER_NAME'] should be updated for netloc.

 It's debatable to me whether this is a bug or a feature -- I realize
 multi-tenancy is relatively unusual under Django.

--

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

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

Re: [Django] #16040: test.Client does not handle domain changes on redirection follow

[Django]

#16040: test.Client does not handle domain changes on redirection follow
---+---
   Reporter:  jdunck   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Uncategorized
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---
Description changed by jdunck:

Old description:

> The default SERVER_NAME used by the test client is testserver.
>
> I have a multi-tenant site serving www.foo.com and m.foo.com.  I also
> have a view which redirects from /spam/ to /eggs/.
>
> Middlware handles the www -> m redirection, while a view handles the
> /spam/ -> /eggs/ redirection.
>
> If the test client requests http://www.foo.com/spam/, it is redirected to
> http://www.bar.com/spam/, but _handle_redirects, while parsing url into
> scheme and path, does not also update SERVER_NAME in extras.  This causes
> the 2nd request handling to be handled as though it were for
> http://www.foo.com/spam/ (again), causing a redirection loop.
>
> I think that just as wsgi.url_scheme is updated for scheme,
> extra['SERVER_NAME'] should be updated for netloc.
>
> It's debatable to me whether this is a bug or a feature -- I realize
> multi-tenancy is relatively unusual under Django.

New description:

 The default SERVER_NAME used by the test client is testserver.

 I have a multi-tenant site serving www.foo.com and www.bar.com.  I also
 have a view which redirects from /spam/ to /eggs/.

 Middleware handles the www -> m redirection, while a view handles the
 /spam/ -> /eggs/ redirection.

 If the test client requests http://www.foo.com/spam/, it is redirected to
 http://www.bar.com/spam/, but _handle_redirects, while parsing url into
 scheme and path, does not also update SERVER_NAME in extras.  This causes
 the 2nd request handling to be handled as though it were for
 http://www.foo.com/spam/ (again), causing a redirection loop.

 I think that just as wsgi.url_scheme is updated for scheme,
 extra['SERVER_NAME'] should be updated for netloc.

 It's debatable to me whether this is a bug or a feature -- I realize
 multi-tenancy is relatively unusual under Django.

--

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

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

[Django] #16040: test.Client does not handle domain changes on redirection follow

[Django]

#16040: test.Client does not handle domain changes on redirection follow
-+-
 Reporter:  jdunck   |Owner:  nobody
 Type:  New feature  |   Status:  new
Milestone:   |Component:  Uncategorized
  Version:  1.3  | Severity:  Normal
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|
-+-
 The default SERVER_NAME used by the test client is testserver.

 I have a multi-tenant site serving www.foo.com and m.foo.com.  I also have
 a view which redirects from /spam/ to /eggs/.

 Middlware handles the www -> m redirection, while a view handles the
 /spam/ -> /eggs/ redirection.

 If the test client requests http://www.foo.com/spam/, it is redirected to
 http://www.bar.com/spam/, but _handle_redirects, while parsing url into
 scheme and path, does not also update SERVER_NAME in extras.  This causes
 the 2nd request handling to be handled as though it were for
 http://www.foo.com/spam/ (again), causing a redirection loop.

 I think that just as wsgi.url_scheme is updated for scheme,
 extra['SERVER_NAME'] should be updated for netloc.

 It's debatable to me whether this is a bug or a feature -- I realize
 multi-tenancy is relatively unusual under Django.

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

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

Re: [Django] #15561: Factorize settings manipulation in tests

[Django]

#15561: Factorize settings manipulation in tests
---+---
   Reporter:  claudep  |  Owner:  lrekucki
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Testing framework
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  1
Patch needs improvement:  1|  Easy pickings:  0
---+---
Changes (by jezdez):

 * needs_tests:  0 => 1


Comment:

 Agreed, but the patch needs to use the same technique the
 `TestCase.settings` CM uses (using `UserSettingsHandler`) since that'll
 make sure that the previous settings instance is reset correctly.

-- 
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] #11475: test.Client.session.save() raises error for anonymous users

[Django]

#11475: test.Client.session.save() raises error for anonymous users
--+---
   Reporter:  egmanoj@…   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.1-beta-1  |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+---

Comment (by prestontimmons):

 Crosslinking to #10899 which would fix this issue. Also #15740, which is
 strictly the bug fix portion of #10899.

-- 
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] #15968: readonly_fields ignore form field label

[Django]

#15968: readonly_fields ignore form field label
-+-
   Reporter:  gabomdq@…  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * type:  Bug => Cleanup/optimization


Comment:

 Just to synthesise, there is no bug as this is the normal behaviour, and
 the feature you were after already exists. The documentation about read-
 only fields is a bit succinct and it could be improved in a few ways, at
 least by emphasising that form fields are excluded from the `ModelForm` if
 declared as readon-only, and by providing a tip on modifying the label of
 a read-only "field" if that "field" is a callable.

-- 
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] #15968: readonly_fields ignore form field label

[Django]

#15968: readonly_fields ignore form field label
-+---
   Reporter:  gabomdq@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
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
-+---

Comment (by julien):

 Yes you're right about `verbose_name`, I read your code sample a bit too
 fast. The feature you're after already exists with `short_description`:

 {{{#!python
 class MyModel(models.Model):
 name = models.CharField(max_length=100, blank=True)

 def test_field_callable(self):
 print 'test content'
 test_field_callable.short_description = 'blah'
 }}}

-- 
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] #16039: syncdb with --database option fails

[Django]

#16039: syncdb with --database option fails
---+--
 Reporter:  yedpodtrzitko  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Database layer (models, ORM)
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
---+--
 Let's presume we've more than one databases in settings:


 {{{
 DATABASES = {
 'default': {
 'NAME': '/home/yed/tmp/icentrum.sqlite',
 'ENGINE': 'django.db.backends.sqlite3',
 },
 'ysql': {
 'NAME': 'icentrum',
 'ENGINE': 'django.db.backends.mysql',
 'USER': 'yed',
 'PASSWORD': 'heslo',
 'HOST': 'localhost',
 'OPTIONS': {"charset":"utf8", "init_command":"SET
 storage_engine=InnoDB"},
 }
 }
 }}}



 ...and now try to sync non-default database database:


 {{{
 ./manage.py syncdb --database=ysql
 }}}



 Expected result:

 Non-default database is synced


 Obtained result:


 {{{
 Creating tables ...
 Running post-sync handlers for application auth
 Traceback (most recent call last):
   File "./manage.py", line 28, in 
 execute_from_command_line()
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/core/management/__init__.py", line 429, in
 execute_from_command_line
 utility.execute()
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/core/management/__init__.py", line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/core/management/base.py", line 191, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/core/management/base.py", line 220, in execute
 output = self.handle(*args, **options)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/core/management/base.py", line 351, in handle
 return self.handle_noargs(**options)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/core/management/commands/syncdb.py", line 109, in
 handle_noargs
 emit_post_sync_signal(created_models, verbosity, interactive, db)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/core/management/sql.py", line 190, in
 emit_post_sync_signal
 interactive=interactive, db=db)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/dispatch/dispatcher.py", line 172, in send
 response = receiver(signal=self, sender=sender, **named)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/contrib/auth/management/__init__.py", line 30, in
 create_permissions
 ctype = ContentType.objects.get_for_model(klass)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/contrib/contenttypes/models.py", line 38, in get_for_model
 defaults = {'name': smart_unicode(opts.verbose_name_raw)},
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/db/models/manager.py", line 135, in get_or_create
 return self.get_query_set().get_or_create(**kwargs)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/db/models/query.py", line 378, in get_or_create
 return self.get(**lookup), False
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/db/models/query.py", line 344, in get
 num = len(clone)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/db/models/query.py", line 82, in __len__
 self._result_cache = list(self.iterator())
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/db/models/query.py", line 273, in iterator
 for row in compiler.results_iter():
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/db/models/sql/compiler.py", line 680, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/db/models/sql/compiler.py", line 735, in execute_sql
 cursor.execute(sql, params)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/db/backends/util.py", line 34, in execute
 return self.cursor.execute(sql, params)
   File "/home/yed/skript/centrum/mypage-all/lib/python2.5/site-
 packages/django/db/backends/sqlite3/base.py", line 234, in execute
 return Database.Cursor.execute(self, query, params)
 django.db.utils.DatabaseError: no such table: django_content_type

 }}}

-- 
Ticket URL: 
Django 
The Web framework for 

Re: [Django] #15968: readonly_fields ignore form field label

[Django]

#15968: readonly_fields ignore form field label
-+---
   Reporter:  gabomdq@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
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
-+---

Comment (by anonymous):

 Thanks for the tip, I've already been down that road and gone through the
 code throughly before reporting here, but you'll have to agree that what
 you comment does not apply to this case. There's no verbose_name to be set
 because the field is not really part of the Model, it's just a method.
 That's why I don't think it's a documentation issue, if it is not
 considered a bug (which I believe to be the case), it's a Feature Request.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15968: readonly_fields ignore form field label

[Django]

#15968: readonly_fields ignore form field label
-+---
   Reporter:  gabomdq@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
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
-+---

Comment (by julien):

 `contrib.admin.helpers.AdminReadonlyField` is where you'll find the
 details of how the read-only fields are built. It is fairly inflexible and
 there's no API for controlling much about it. Yet  :-)

 In the meantime, a work-around is to provide a `verbose_name` to your
 model field.

-- 
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] #15968: readonly_fields ignore form field label

[Django]

#15968: readonly_fields ignore form field label
-+---
   Reporter:  gabomdq@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
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
-+---

Comment (by anonymous):

 If that is so, what is the recommended way to set a custom label in this
 case?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16038: Localization of django form Field falls back to False instead of settings.USE_L10N

[Django]

#16038: Localization of django form Field falls back to False instead of
settings.USE_L10N
+
   Reporter:  jonathanslenders  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:  1.4   |  Component:  Forms
Version:  SVN   |   Severity:  Normal
 Resolution:  needsinfo |   Keywords:  l10n
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+
Changes (by kmtracey):

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


Comment:

 The problem description here is very confusing to me. A programmatic test
 case illustrating the problem would help.

 The localize Field argument, and its default, was not added on a whim; it
 was reluctantly added to fix #13032. Are you sure your proposed change
 would not re-introduce the problem that it was introduced to fix?

-- 
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] #16027: Include app_label in ContentType.__unicode__

[Django]

#16027: Include app_label in ContentType.__unicode__
-+-
   Reporter:  jakub  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:
  Milestone: |  contrib.contenttypes
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  1
-+-

Comment (by jakub):

 How about this: "`name (app_label.model)`"

 It should be both user-friendly (`ContentType.name` is the model's
 `verbose_name`) and easy to identify the origin of the model.

 A `ContentType` instance for `UserProfile` from `accounts` would have the
 following unicode representation:

 "user profile (accounts.userprofile)"

 If there is another model with the same name, say
 `facebook.models.UserProfile`:

 * user profile (accounts.userprofile)
 * user profile (facebook.userprofile)

 As for tests, I'm not sure what exactly to test in this case, any hints?
 Also, I've realized that this might be a backwards-incompatible change to
 some extent, because it will break any doctests relying on
 `ContentType.__unicode__` returning only the verbose name of models.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16038: Localization of django form Field falls back to False instead of settings.USE_L10N

[Django]

#16038: Localization of django form Field falls back to False instead of
settings.USE_L10N
--+
 Reporter:  jonathanslenders  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:  1.4   |  Component:  Forms
  Version:  SVN   |   Severity:  Normal
 Keywords:  l10n  |   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
--+
 django.forms.Field has a localize argument which defaults to False instead
 of settings.USE_L10N.
 This causes unexpected/random behaviour.

 Field is initialized right after the form has been defined. So, Input
 widgets like DateTimeInput, are also inialized at this time, where the
 date formatting is set according to the current language when USE_L10N is
 still enabled.

 The field will stay in the language that was active during the creation of
 the form. So, when an application has several forms, but they were somehow
 created in different languages, they all have different formatting.


 When USE_L10N is enabled in settings.py, it's better to default to this
 value.


 It's no good that Input calls a method 'get_format' which behaviour
 depends on the value of USE_L10N, while Field has an __init__ attribute
 'localize'.
 In my opinion, the 'localize' attribute of a Field should be deprecated,
 but if someone would really require it (which I doubt, as it is broken
 now...), DateTimeInput or any Input widget should never call
 formats.get_format when USE_L10N=True, but localize=False, as this
 combination causes the field to be localized in a random language. (And
 causes it to stay and render in this language, no mater the active
 language later on.)

 People using ModelForm, usually don't explicitely initialize Field for
 datetime fields in their model, so they fall back to the broken default.

 Patch attached which sets Field.localize to USE_L10N and fixes ModelForm.
 If someone still uses the localize parameter, and sets it explicitely to
 False (True would not be an issue), he gets the broken behaviour again.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #11475: test.Client.session.save() raises error for anonymous users

[Django]

#11475: test.Client.session.save() raises error for anonymous users
--+---
   Reporter:  egmanoj@…   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.1-beta-1  |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+---
Changes (by bmihelac):

 * cc: bmihelac@… (added)
 * 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] #16037: Multiple databases support for unit testing

[Django]

#16037: Multiple databases support for unit testing
-+-
   Reporter:  prudnikov  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution:  duplicate  |   Severity:  Normal
   Triage Stage: |   Keywords:  test, database,
  Unreviewed |  fixtures
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by julien):

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


Comment:

 This feature was already requested in #14610.

-- 
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] #16037: Multiple databases support for unit testing

[Django]

#16037: Multiple databases support for unit testing
-+-
   Reporter:  prudnikov  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  test, database,
  Unreviewed |  fixtures
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 If I understand correctly, the actual bug is the fact that the `loaddata`
 operation performed during the test sequence does not honor the database
 routers.

-- 
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] #16035: GZipMiddleware doesn't change an ETag

[Django]

#16035: GZipMiddleware doesn't change an ETag
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  HTTP handling
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+---
Changes (by aaugustin):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16033: get_field_display: Django needs a filter to allow get_field_display for a dynamic field

[Django]

#16033: get_field_display: Django needs a filter to allow get_field_display for 
a
dynamic field
---+-
   Reporter:  thepapermen  |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Template system
Version:  1.3  |   Severity:  Normal
 Resolution:  duplicate|   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+-
Changes (by aaugustin):

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


Comment:

 Duplicate of #16034 - double submission.

-- 
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] #16037: Multiple databases support for unit testing

[Django]

#16037: Multiple databases support for unit testing
-+-
 Reporter:  prudnikov|  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Database layer
  Version:  1.3  |  (models, ORM)
 Keywords:  test, database,  |   Severity:  Normal
  fixtures   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+-
 I use multiple database functionality. Fixtures that contain data for non-
 default database are not being loaded when I run `./manage.py tests app`.
 It starts loading when I delete all routers from `DATABASE_ROUTERS` (all
 data goes to the 'default' database).

 There is no option `--database` for "test" management command.

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