[Django] #17680: logging from command line

[Django]

#17680: logging from command line
-+
 Reporter:  Brian May   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Uncategorized|Version:  1.3
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 The documentation says "Logging is configured immediately after settings
 have been loaded. Since the loading of settings is one of the first things
 that Django does, you can be certain that loggers are always ready for use
 in your project code."

 I assume this to be correct for web requests. It also seems to be correct
 for the "manage.py shell" interactive shell. It does not seem to work for
 command line applications however. For example, if I try to run the
 following code:

 {{{
 #!/usr/bin/env python
 from django.core.management import setup_environ
 from kgadmin.conf import settings
 setup_environ(settings)

 import logging
 logger = logging.getLogger(__name__)
 logger.debug(u"something weent debug")
 logger.info(u"something weent info")
 logger.error(u"something weent error")
 }}}

 then logging is not initialized and I get the following message:

 {{{
 No handlers could be found for logger "__main__"
 }}}

 To fix this, I have to insert code like the following to force the
 settings to become initialized:

 {{{
 import django.conf
 django.conf.settings.LOGGING
 }}}

 I would have hoped that setup_environ(...) would do all of this, but
 apparently not.

 This is with python-django 1.3-2ubuntu1.1 running on Ubuntu 11.10

 Brian May

-- 
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] #17679: Error messages from field.validators never used if the ValidationError has a code matching an error message on the Field

[Django]

#17679: Error messages from field.validators never used if the ValidationError 
has
a code matching an error message on the Field
+
 Reporter:  insin   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  SVN
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+
 Given the following field, I would have expected that validate_email's
 error message would haven been displayed:

 {{{
 >>> from django.conf import settings
 >>> settings.configure()
 >>> from django import forms
 >>> from django.core import validators
 >>> f = forms.CharField(validators=[validators.validate_email])
 >>> f.clean('@@')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/insin/Virtualenvs/django-
 trunk/src/django/django/forms/fields.py", line 155, in clean
 self.run_validators(value)
   File "/home/insin/Virtualenvs/django-
 trunk/src/django/django/forms/fields.py", line 144, in run_validators
 raise ValidationError(errors)
 django.core.exceptions.ValidationError: [u'Enter a valid value.']
 >>> import django
 >>> django.get_version()
 '1.4a1'
 }}}

 The root issue is that many of the django.core.validators use the
 "invalid" error code, which is always going to be defined on the field as
 it's a default. I have a branch on !GitHub which has one approach to
 updating this behaviour - using the validators' own error messages unless
 the message code has been customised on the field instance. The tests
 demonstrate a use case extending RegexValidator, which was raised as an
 issue in my JavaScript port of django.forms:

 https://github.com/insin/django/compare/validators-error-messages

 Another approach would be to change the codes used by the OOTB validators
 away from 'invalid', as is already the case with BaseValidator and classes
 which extend it.

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

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

Re: [Django] #17675: using date filter with regroup tag not working with 1.4 TZ

[Django]

#17675: using date filter with regroup tag not working with 1.4 TZ
-+---
 Reporter:  ptone|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.4-alpha-1
 Severity:  Release blocker  |   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 akaariai):

 Looking quickly through the patch it doesn't seem that hackish to me.
 However, I would like if there was a comment of _why_ the context
 resolving dance is done.

-- 
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] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
+
 Reporter:  brutasse|Owner:  brutasse
 Type:  New feature |   Status:  new
Component:  Forms   |  Version:
 Severity:  Normal  |   Resolution:
 Keywords:  form-rendering  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by quinode):

 * cc: dguardiola@… (added)


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

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

Re: [Django] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 I created a ticket for the proxy_for_model bug (#17678).

 My performance concern is about doing the same queries again and again, so
 I think we are on the same page about that. This could become ridiculously
 slow if this would happen for each deferred class instance.

 I don't have time to work on this today, all time went to 17678 (I didn't
 realize that there was already an implementation available in the latest
 patch to this ticket). Busy week and all that, but I hope I can work on
 this ticket sometime during this week. But, there is one problem which I
 would like to solve before working on this.

 I think I will go for an implementation where the proxy_equivalence_class
 is a property, and the real set is contained in
 model._meta.concrete_model. This should be pretty clean implementation.

 One problem I would like to solve still: Should the auto-created deferred
 model classes be added to the proxy-equivalence set? I think yes, as this
 is easier to implement, and it is possible to get only the real classes by
 doing some filtering on the equivalence class. Going into the other
 direction isn't possible, of course.

-- 
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] #17675: using date filter with regroup tag not working with 1.4 TZ

[Django]

#17675: using date filter with regroup tag not working with 1.4 TZ
-+---
 Reporter:  ptone|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.4-alpha-1
 Severity:  Release blocker  |   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 aaugustin):

 Disclaimer: the solution I used in this patch is quite hackish, but the
 previous one was even worse, and the semantics of the `regroup` tag
 themselves are hackish: they require the equivalent of Python's `getattr`,
 but with the behavior of the DTL's context lookups.

-- 
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] #17675: using date filter with regroup tag not working with 1.4 TZ

[Django]

#17675: using date filter with regroup tag not working with 1.4 TZ
-+---
 Reporter:  ptone|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.4-alpha-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---
Changes (by aaugustin):

 * has_patch:  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] #17675: using date filter with regroup tag not working with 1.4 TZ

[Django]

#17675: using date filter with regroup tag not working with 1.4 TZ
-+---
 Reporter:  ptone|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.4-alpha-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---

Comment (by aaugustin):

 Indeed, it looks very wrong to me to call `resolve` with something that
 isn't a `Context` as the first positional argument (`context`). I'm
 currently refactoring the implementation of the `regroup` tag to avoid
 this.

-- 
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] #17678: Model._meta proxy_for_model set up incorrectly

[Django]

#17678: Model._meta proxy_for_model set up incorrectly
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 There are some places in the code which assume that proxy_for_model
 creates a proxy chain. That is, if you have models:
 {{{
 A
 Proxy(A)
 ProxyProxy(Proxy)
 }}}
 the expected result is that ProxyProxy._meta.proxy_for_model == Proxy, but
 this isn't true. One place which makes this proxy-chain mistake is the
 very place that sets up the proxy_for_model so this seems like a clear
 bug.

 In the attached patch I added ._meta.concrete_class, which is always the
 concrete class of the model. This simplifies code in some places. In
 addition, the proxy_for_model correctly creates a proxy chain now.

 I think the proxy_for_model error was responsible for one bug in admin,
 but I haven't verified that there was a bug (so, no tests). In addition
 there is one place in sql/query.py which is working now as it was before,
 but I am not sure if the before behavior was in fact correct. Neither of
 these should be this ticket's problems.

 The bug is present in at least 1.3, maybe even before.

-- 
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] #17675: using date filter with regroup tag not working with 1.4 TZ

[Django]

#17675: using date filter with regroup tag not working with 1.4 TZ
-+---
 Reporter:  ptone|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.4-alpha-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---

Comment (by akaariai):

 Isn't that using a kwarg in a very non-necessary fashion? That line is
 doing:
 {{{
 def somef(v):
 return self.expression.resolve(v, True)
 groupby(obj_list, somef)
 }}}
 Now, wouldn't be a surprise if the above is wrong. As said, the line is a
 bit cryptic...

-- 
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] #17600: Error in encapsulates filters (Q)

[Django]

#17600: Error in encapsulates filters (Q)
-+-
 Reporter:  pmartin  |Owner:  nobody
 Type:  Bug  |   Status:  new
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|UI/UX:  0
-+-

Comment (by akaariai):

 I think this one should rest until 1.4 is out. Fixing this before that
 seems unlikely. Or, if this is fixed, the fix must be something like what
 is done by pmartin.

 I think the real fix here would include some refactoring of the WhereNode
 class (mainly, there is something weird going on with the .negate() and
 start_subtree() business). Then refactor sql/query.py add_q (it creates
 pretty stupid boolean trees on certain inputs), and finally check what
 broke and how to _then_ fix the issue in this ticket.

 There are some related tickets already: #17025 is about where node
 refactoring. It maybe goes a bit too far, but I think it shows the
 potential of code cleanup and speed improvement available. Then there is
 #17000 which is about add_q refactoring.

-- 
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] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
---+
 Reporter:  jarrow |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by michelts):

 * cc: michelts@… (added)


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

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

Re: [Django] #17675: using date filter with regroup tag not working with 1.4 TZ

[Django]

#17675: using date filter with regroup tag not working with 1.4 TZ
-+---
 Reporter:  ptone|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.4-alpha-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---

Comment (by aaugustin):

 I can see how this bug happens: `FilterExpression.resolve` is called with
 items of the iterators you're grouping as the first argument, but it
 expects a context as the first argument.

 I'm also struggling to figure out this very cryptic line :/

-- 
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] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * needs_better_patch:  0 => 1


Comment:

 The get_db_prep_value seems like the right place, because that is called
 in all the right places. The only other option I can see is to create a
 new method for this.

 The get_db_prep_value is already doing some validation, it calls
 get_prep_value which calls int(value), and that can raise a `ValueError`.

 There is a small mistake in the error message. It says zero is not
 accepted for primary key. This isn't true for `MySQL`.
 {{{
 mysql> create table testtbl(id integer primary key);
 Query OK, 0 rows affected (0.05 sec)

 mysql> insert into testtbl values(0);
 Query OK, 1 row affected (0.01 sec)

 mysql> select * from testtbl;
 ++
 | id |
 ++
 |  0 |
 ++
 1 row in set (0.00 sec)
 }}}

 I know this is a minor nitpick. But it is also easy to correct. It should
 say that zero is not allowed for `AutoFields`.

 There should be a test for bulk_create, too. Maybe, as this ticket is
 about get_or_create add one for that too, although that might be a bit
 redundant.

-- 
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] r17520 - in django/trunk/docs: ref/templates releases topics/i18n

[noreply]

Author: jezdez
Date: 2012-02-13 12:57:44 -0800 (Mon, 13 Feb 2012)
New Revision: 17520

Modified:
   django/trunk/docs/ref/templates/builtins.txt
   django/trunk/docs/releases/1.4-beta-1.txt
   django/trunk/docs/releases/1.4.txt
   django/trunk/docs/topics/i18n/formatting.txt
Log:
Added a note to the release notes about the new format strings added in r17473.

Modified: django/trunk/docs/ref/templates/builtins.txt
===
--- django/trunk/docs/ref/templates/builtins.txt2012-02-13 10:51:17 UTC 
(rev 17519)
+++ django/trunk/docs/ref/templates/builtins.txt2012-02-13 20:57:44 UTC 
(rev 17520)
@@ -1361,6 +1361,10 @@
 
 The ``c`` and ``u`` format specification characters were added in Django 1.2.
 
+.. versionadded:: 1.4
+
+The ``e`` and ``o`` format specification characters were added in Django 1.4.
+
 For example::
 
 {{ value|date:"D d M Y" }}

Modified: django/trunk/docs/releases/1.4-beta-1.txt
===
--- django/trunk/docs/releases/1.4-beta-1.txt   2012-02-13 10:51:17 UTC (rev 
17519)
+++ django/trunk/docs/releases/1.4-beta-1.txt   2012-02-13 20:57:44 UTC (rev 
17520)
@@ -502,6 +502,28 @@
 :djadmin:`startproject`. If you want to use this feature in an existing
 project, there is a :ref:`migration guide `.
 
+Two new date format strings
+~~~
+
+Two new :tfilter:`date` formats for use in template filters, template tags
+and :ref:`format-localization`:
+
+- ``e`` -- the name of the timezone of the given datetime object
+- ``o`` -- the ISO 8601 year number
+
+Please make sure to update your :ref:`custom format files
+` if they contain either ``e`` or ``o`` in a format
+string. For example a Spanish localization format previously only escaped the
+``d`` format character::
+
+  DATE_FORMAT = r'j \de F \de Y'
+
+But now it needs to also escape ``e`` and ``o``::
+
+  DATE_FORMAT = r'j \d\e F \d\e Y'
+
+For more information, see the :tfilter:`date` documentation.
+
 Minor features
 ~~
 

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2012-02-13 10:51:17 UTC (rev 17519)
+++ django/trunk/docs/releases/1.4.txt  2012-02-13 20:57:44 UTC (rev 17520)
@@ -490,6 +490,28 @@
 client's response contains a given HTML fragment. See the :ref:`assertion
 documentation` for more.
 
+Two new date format strings
+~~~
+
+Two new :tfilter:`date` formats for use in template filters, template tags
+and :ref:`format-localization`:
+
+- ``e`` -- the name of the timezone of the given datetime object
+- ``o`` -- the ISO 8601 year number
+
+Please make sure to update your :ref:`custom format files
+` if they contain either ``e`` or ``o`` in a format
+string. For example a Spanish localization format previously only escaped the
+``d`` format character::
+
+  DATE_FORMAT = r'j \de F \de Y'
+
+But now it needs to also escape ``e`` and ``o``::
+
+  DATE_FORMAT = r'j \d\e F \d\e Y'
+
+For more information, see the :tfilter:`date` documentation.
+
 Minor features
 ~~
 

Modified: django/trunk/docs/topics/i18n/formatting.txt
===
--- django/trunk/docs/topics/i18n/formatting.txt2012-02-13 10:51:17 UTC 
(rev 17519)
+++ django/trunk/docs/topics/i18n/formatting.txt2012-02-13 20:57:44 UTC 
(rev 17520)
@@ -149,6 +149,8 @@
 control localization over a large section of a template, use the
 :ttag:`localize` template tag.
 
+.. _custom-format-files:
+
 Creating custom format files
 
 

-- 
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] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by krzysiumed):

 * owner:  krzysiumed => nobody
 * needs_better_patch:  1 => 0
 * status:  assigned => new


Comment:

 Sorry for delay, but the ticket is not as easy as I thought.

 I attached a patch similar to akaariai's patch. It validates value for
 primary key in new method `BaseDatabaseOperations.check_autopk_value` in
 module `db.backends`. The method is overriden in `DatabaseOperations` in
 module `db.backends.mysql`, so it does not use `allows_primary_key_0`
 flag. The method is called by `AutoField.get_db_prep_value` from module
 `db.models.fields`. The patch includes simple test.

 I'm not sure if `get_db_prep_save` is right place for validation. The doc
 of the method says:
 {{{
 Returns field's value prepared for interacting with the database
 backend.

 Used by the default implementations of ``get_db_prep_save``and
 `get_db_prep_lookup```
 }}}
 so maybe we should add note that `get_db_prep_save` do validation and may
 raise error?

 Note that both patches (mine and akaariai's) works for `AutoField` as well
 as for `ForeignKey` and `ManyToManyField`, because related fields calls
 `AutoField.get_db_prep_value` during executing their `get_db_prep_value`
 method (see
 
https://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L962).

-- 
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] #17144: Excessive GROUP BY clauses during aggregations.

[Django]

#17144: Excessive GROUP BY clauses during aggregations.
--+
 Reporter:  christian_oudard  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  ORM aggregation   |  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 anonymous):

 @sbussetti is absolutely right. I can't do half the things I need to do
 with the ORM once I need annotation. The issue of group by needs to be
 revisited, and perhaps redesigned. This is a major caveat in my day to day
 work.

-- 
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] #16304: Add HTML5 'placeholder' attribute support to form fields.

[Django]

#16304: Add HTML5 'placeholder' attribute support to form fields.
-+-
 Reporter:  rich@…   |Owner:  j4nu5
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  forms, placeholder,  | Triage Stage:  Accepted
  html5  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  1|
-+-
Changes (by j4nu5):

 * status:  new => assigned
 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


Comment:

 Based on the discussions on dev mailing list, I have removed placeholder
 attribute from ModelForms.

 The submitted patch adds a placeholder attribute to Forms. ModelForms will
 have to be manually overridden to add a placeholder attribute. Has tests
 and documentation.

-- 
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] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
-+-
 Reporter:  ikelly   |Owner:
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle postgresql|  Needs documentation:  0
  mysql schemas  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-
Changes (by mitar):

 * cc: mmitar@… (added)


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

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

Re: [Django] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
-+-
 Reporter:  pixelcort|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  1
-+-
Changes (by arj):

 * cc: anders@… (removed)


-- 
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] #12767: Problem running syncdb with a multi-db router that restricts auth to a single database

[Django]

#12767: Problem running syncdb with a multi-db router that restricts auth to a
single database
-+-
 Reporter:  russellm |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mitar):

 * cc: mmitar@… (added)
 * ui_ux:   => 0
 * 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] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
-+-
 Reporter:  pixelcort|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  1
-+-

Comment (by shanx):

 Dear anonymous, Django is open source remember. People don't owe you, even
 if it has been ten years since something was reported in Trac. Do you want
 Nested inline support? Step up to help out, pay a developer to build it,
 be involved in some way to do something constructive

-- 
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] #17600: Error in encapsulates filters (Q)

[Django]

#17600: Error in encapsulates filters (Q)
-+-
 Reporter:  pmartin  |Owner:  nobody
 Type:  Bug  |   Status:  new
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|UI/UX:  0
-+-
Changes (by shai):

 * has_patch:  1 => 0


Comment:

 If your patch is not intended as a fix to the problem, I think it is
 better to remove the "has patch" mark -- and so I did. Feel free to
 correct me, of course.

 I think the best step forward, short of a core developer getting involved,
 is to add a patch that just has tests to demonstrate the 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.

[Changeset] r17519 - in django/trunk: django/contrib/staticfiles django/contrib/staticfiles/management/commands tests/regressiontests/staticfiles_tests tests/regressiontests/staticfiles_tests/apps/te

[noreply]

Author: jezdez
Date: 2012-02-13 02:51:17 -0800 (Mon, 13 Feb 2012)
New Revision: 17519

Removed:
   
django/trunk/tests/regressiontests/staticfiles_tests/apps/test/static/test/.hidden
   
django/trunk/tests/regressiontests/staticfiles_tests/apps/test/static/test/backup~
Modified:
   django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
   django/trunk/django/contrib/staticfiles/storage.py
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
Log:
Minor bugfixing of the staticfiles app following upstream development in 
django-staticfiles.

- Create the files to ignore during the tests dynamically (.hidden and backup~)
- Refactored the post_processing method of the CachedFilesMixin storage mixin 
to be less time consuming.
- Refactored handling of fragments in the post_process method.

Modified: 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
===
--- 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2012-02-12 17:16:37 UTC (rev 17518)
+++ 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2012-02-13 10:51:17 UTC (rev 17519)
@@ -7,13 +7,14 @@
 from django.core.files.storage import FileSystemStorage
 from django.core.management.base import CommandError, NoArgsCommand
 from django.utils.encoding import smart_str, smart_unicode
+from django.utils.datastructures import SortedDict
 
 from django.contrib.staticfiles import finders, storage
 
 
 class Command(NoArgsCommand):
 """
-Command that allows to copy or symlink media files from different
+Command that allows to copy or symlink static files from different
 locations to the settings.STATIC_ROOT.
 """
 option_list = NoArgsCommand.option_list + (
@@ -50,6 +51,7 @@
 self.copied_files = []
 self.symlinked_files = []
 self.unmodified_files = []
+self.post_processed_files = []
 self.storage = storage.staticfiles_storage
 try:
 self.storage.path('')
@@ -61,18 +63,27 @@
 if hasattr(os, 'stat_float_times'):
 os.stat_float_times(False)
 
-def handle_noargs(self, **options):
+def set_options(self, **options):
+"""
+Set instance variables based on an options dict
+"""
+self.interactive = options['interactive']
+self.verbosity = int(options.get('verbosity', 1))
+self.symlink = options['link']
 self.clear = options['clear']
 self.dry_run = options['dry_run']
 ignore_patterns = options['ignore_patterns']
 if options['use_default_ignore_patterns']:
 ignore_patterns += ['CVS', '.*', '*~']
 self.ignore_patterns = list(set(ignore_patterns))
-self.interactive = options['interactive']
-self.symlink = options['link']
-self.verbosity = int(options.get('verbosity', 1))
 self.post_process = options['post_process']
 
+def collect(self):
+"""
+Perform the bulk of the work of collectstatic.
+
+Split off from handle_noargs() to facilitate testing.
+"""
 if self.symlink:
 if sys.platform == 'win32':
 raise CommandError("Symlinking is not supported by this "
@@ -80,6 +91,46 @@
 if not self.local:
 raise CommandError("Can't symlink to a remote destination.")
 
+if self.clear:
+self.clear_dir('')
+
+if self.symlink:
+handler = self.link_file
+else:
+handler = self.copy_file
+
+found_files = SortedDict()
+for finder in finders.get_finders():
+for path, storage in finder.list(self.ignore_patterns):
+# Prefix the relative path if the source storage contains it
+if getattr(storage, 'prefix', None):
+prefixed_path = os.path.join(storage.prefix, path)
+else:
+prefixed_path = path
+found_files[prefixed_path] = storage.open(path)
+handler(path, prefixed_path, storage)
+
+# Here we check if the storage backend has a post_process
+# method and pass it the list of modified files.
+if self.post_process and hasattr(self.storage, 'post_process'):
+processor = self.storage.post_process(found_files,
+  dry_run=self.dry_run)
+for original_path, processed_path, processed in processor:
+if processed:
+self.log(u"Post-processed '%s' as '%s" %
+ (original_path, processed_path), level=1)
+self.post_processed_files.append(original_path)
+else:
+self.log(u"Skipped post-processing '%s'" % original_path)
+
+return {
+'modified': self.copied_files + s

Re: [Django] #13427: verbose_name and verbose_name_plural is untranslated on autogenerated m2m models

[Django]

#13427: verbose_name and verbose_name_plural is untranslated on autogenerated 
m2m
models
-+-
 Reporter:  russellm |Owner:  ramiro
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  verbose_name |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by quinode):

 This does also happens for m2m with intermediate through models, when
 they're used as inlines in the admin [[BR]]

 The fields labels are also completely untranslated in tabular inlines, and
 partially (?) in stacked inlines, where I can see that verbose_name
 gettext translations for text input and textarea widgets are displayed,
 but not for select widgets...


 This bug does not happens at all with Generic Inlines, their app and
 fields verbose_name translated labels are correctly displayed in the
 admin.

-- 
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] #17473: Add like and ilike lookups

[Django]

#17473: Add like and ilike lookups
-+-
 Reporter:  pmartin  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by pmartin):

 Replying to [comment:2 russellm]:

 I have written a [http://www.yaco.es/blog/en/contribuciones/2012/02/a
 -simple-and-impossible-query-in-django/ post] about this:

  * I have written a [https://github.com/goinnn/django-
 like/blob/master/src/django_like/management/commands/benchmark_like.py
 benchmark], with this you can see the improvement.
  * In this post, I talk that it is not a duplication of code or
 duplication of funcionality. You can read. I hope to convince you

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