Re: [Django] #18250: Comparing two unsaved model objects

[Django]

#18250: Comparing two unsaved model objects
-+-
 Reporter:  yrdnsa@… |Owner:  Yarden
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  compare model|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * stage:  Design decision needed => 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] #18243: Management shell should make it easy to force LOGGING_CONFIG=None

[Django]

#18243: Management shell should make it easy to force LOGGING_CONFIG=None
--+
 Reporter:  ncoghlan@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  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
--+
Changes (by claudep):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Core (Management commands) => Core (Other)
 * stage:  Unreviewed => Accepted


Comment:

 OK, so let's see what it will look like in a patch :-)

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

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

Re: [Django] #17209: Dogfood class-based views in contrib.auth

[Django]

#17209: Dogfood class-based views in contrib.auth
-+-
 Reporter:  melinath |Owner:  andrews
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.auth |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  class-based views|  Needs documentation:  0
  admin auth |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by andrews):

 * owner:  nobody => andrews
 * cc: andrewsmedina@… (added)


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

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

[Django] #18254: Add support for `as ` to the staticfiles {% static %} template tag.

[Django]

#18254: Add support for `as ` to the staticfiles {% static %} template
tag.
-+
 Reporter:  melinath |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  contrib.staticfiles  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+
 I'm in a situation where I want to prepend the current site's domain to a
 static file's URL. In olden times, I would've done something like:

 {{{
 {% if STATIC_URL|slice:":4" != "http" %}http://{{ site.domain }}{% endif
 %}{{ STATIC_URL }}path/to/file.txt
 }}}

 But now the standard way to do things is to use the {{{ {% static %} }}}
 template tag from staticfiles, which currently has no way of assigning to
 the context - which means that to accomplish the above, you would need to
 write a custom template tag. Granted, that would be pretty trivial, but it
 shouldn't be necessary. Having the option of {{{ {% static  as
  %} }}} would parallel nicely with the {{{ {% url %} }}} tag and
 similar.

-- 
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] #18173: Modeladmin documentation for get_changelist suggests its an attribute

[Django]

#18173: Modeladmin documentation for get_changelist suggests its an attribute
-+-
 Reporter:  Keryn Knight |Owner:  nobody
   |   Status:  new
 Type:   |  Version:  master
  Cleanup/optimization   |   Resolution:
Component:  Documentation| Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by moritzs):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 It's a good idea to move it to the methods section.

 In addition the documentation should be more specific: The get_changelist
 method gets passed a request object and should return a class inherited
 from django.contrib.admin.views.main.ChangeList.

-- 
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] #18225: Staticfiles template tag does not fail silently

[Django]

#18225: Staticfiles template tag does not fail silently
-+
 Reporter:  bouke|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by moritzs):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  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] #18250: Comparing two unsaved model objects

[Django]

#18250: Comparing two unsaved model objects
-+-
 Reporter:  yrdnsa@… |Owner:  Yarden
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  compare model|  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Alex):

 It doesn't have to, you can have it fall back to an identity comparison if
 the pks are None.

-- 
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] #18250: Comparing two unsaved model objects

[Django]

#18250: Comparing two unsaved model objects
-+-
 Reporter:  yrdnsa@… |Owner:  Yarden
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  compare model|  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by moritzs):

 * cc: moritzs (added)
 * version:  1.3 => master
 * stage:  Unreviewed => Design decision needed


Comment:

 Changing the !__eq!__ method to check if the pk value is None would cause
 that all non-saved model objects would return False when being compared:
 {{{
 #!python
 >>> o = MyModel(text='foo')
 >>> o == o
 False
 }}}

-- 
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] #18243: Management shell should make it easy to force LOGGING_CONFIG=None

[Django]

#18243: Management shell should make it easy to force LOGGING_CONFIG=None
-+-
 Reporter:  ncoghlan@…   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ncoghlan@…):

 No, I don't think it needs to be opt-in as such, I'd just like to see the
 *location* of the implicit configuration changed so it doesn't happen as a
 side effect of importing django.conf.

 For example, on the web side, ensuring that logging is configured could be
 handled by django.core.handlers.wsgi.WSGIHandler()

 On the management CLI side, it could be handled by
 django.core.management.execute_from_command_line() (and done in such a way
 that the "--help" code path *avoids* initialising logging)

 Those are the active entry points I use, but there may be others.

 There are a couple of advantages to doing things this way:

 1. It means that a broken logging configuration isn't quite as fatal an
 error. At the moment, logging config problems mean that *importing Django*
 fails. By moving the initialisation, the failure instead moves to code
 paths that are actually likely to *want* the logging enabled, while paths
 that don't care about logging (like the --help output) won't be affected.

 2. It's easier to control. Instead of having to set global state to affect
 whether or not the logging gets configured, you can start adding control
 parameters to the active interfaces (such as an "init_logging" callable
 parameter for WSGIHandler and execute_from_command_line that can be set to
 None to disable logging, left at the default to use the logging config
 from settings.py, or customised to use something else entirely)

-- 
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] #18253: error in tutorial

[Django]

#18253: error in tutorial
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by moritzs):

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


Comment:

 In [https://docs.djangoproject.com/en/1.3/intro/tutorial02/ tutorial02]
 there is no unicode method.

 In [https://docs.djangoproject.com/en/1.3/intro/tutorial01/ tutorial01]
 there are two unicode methods for each Poll and Choice but they seem to be
 correct.

-- 
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] #18233: file_move_safe overwrites destination file

[Django]

#18233: file_move_safe overwrites destination file
-+-
 Reporter:  anonymous|Owner:  aviraldg
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  1.3
  uploads/storage|   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by moritzs):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


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

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

[Django] #18253: error in tutorial

[Django]

#18253: error in tutorial
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 https://docs.djangoproject.com/en/1.3/intro/tutorial02/

 def __unicode__(self):
 return self.question

 should probably read

 def __unicode__(self):
 return self.choice

 see here
 http://stackoverflow.com/questions/2811075/model-django-poll

-- 
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] #9950: PUT requests do not have request body handled

[Django]

#9950: PUT requests do not have request body handled
---+--
 Reporter:  ssolon |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  HTTP handling  |  Version:  1.0
 Severity:  Normal |   Resolution:  invalid
 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 slacy):

 As RESTful APIs become more and more important (alongside the rise of
 client-side framewarks like Backbone.js, knockout.js, Ember.js, etc.) this
 issue is quite a hinderance to the adoption of Django.

 I think the right solution here is to have some kind of pluggable system
 (akin to a Middleware, in fact, it even may be one) that detects content
 types and parses and stuffs the WSGIRequest with the relevant info.
 Telling clients to parse it themselves is a copout.  The input side of
 HTTP is just as well defined as the output, and the logic can be as simple
 as "check the input content type and call the right parser".

-- 
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] #9950: PUT requests do not have request body handled

[Django]

#9950: PUT requests do not have request body handled
---+--
 Reporter:  ssolon |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  HTTP handling  |  Version:  1.0
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by slacy):

 * cc: slacy@… (added)
 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * 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] #1028: High-level feed framework should make more feed elements available

[Django]

#1028: High-level feed framework should make more feed elements available
-+-
 Reporter:  ubernostrum  |Owner:
 Type:  New feature  |  tylerdavis
Component:  contrib.syndication  |   Status:  assigned
 Severity:  Normal   |  Version:  1.2-alpha
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-

Comment (by tylerdavis):

 Hello all.  This is my first attempt at working on a ticket, so thank you
 very much for your patience.  I was hoping anyone that may have been
 involved with this ticket in the past could fill me in on what the
 specific goals are here.  Obviously, I understand that the framework
 doesn't support all the currently supported rss 2.0 elements.  It looks
 like the current patches have addressed that for the most part?  What can
 I do to help complete this?

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

[Django]

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

Comment (by akaariai):

 I just spotted that m2m fields are allowed in the "update_fields" arg. I
 guess they have to be forbidden, as this could lead to confusion: "I
 defined 'm2m' in the update_fields, but it did not get updated. Whats
 going on?". Maybe removing the PK field should be done, too. You can't
 actually update the primary key currently, and allowing it in the
 update_fields is misleading.

 Maybe the right fix is to use something like [field.name for field in
 self._meta.fields if not field.primary_key] instead of
 get_all_field_names(). Not tested...

 I can take care of the above points when committing the patch. Of course,
 if you want to do the work I am more than happy to let you do 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] #18252: Multi-table inheritance + ForeignKey to parent => corrupted save

[Django]

#18252: Multi-table inheritance + ForeignKey to parent => corrupted save
-+-
 Reporter:  magon@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by magon@…):

 * status:  new => closed
 * needs_docs:  0 => 1
 * resolution:   => duplicate


Comment:

 Thank for pointing me to the right tickets. I was unable to find something
 similar.
 Having
 {{{
 a_id = models.AutoField(db_column='id', primary_key=True)
 }}}
 in either class "A" or class "B" (or both) solves the problem.

 As suggested in the other tickets, I vote for not validating this models
 (without the autoFields). It seems that fixing it inside core is
 troublesome.

 Making a note in multi-table inheritance documentation would be great as
 it really causes data loss.

 Marking duplicate for #12002.

-- 
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/django] 435081: Fixed tests for date-based generic views.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 435081fd22cec08d98ccbf1efcd223ccaa634ecd
  
https://github.com/django/django/commit/435081fd22cec08d98ccbf1efcd223ccaa634ecd
  Author: Aymeric Augustin 
  Date:   2012-05-01 (Tue, 01 May 2012)

  Changed paths:
M tests/regressiontests/generic_views/dates.py

  Log Message:
  ---
  Fixed tests for date-based generic views.


diff --git a/tests/regressiontests/generic_views/dates.py 
b/tests/regressiontests/generic_views/dates.py
index f3984c6..eb1f7d0 100644
--- a/tests/regressiontests/generic_views/dates.py
+++ b/tests/regressiontests/generic_views/dates.py
@@ -456,15 +456,17 @@ def test_datetime_day_view(self):
 
 @override_settings(USE_TZ=True, TIME_ZONE='Africa/Nairobi')
 def test_aware_datetime_day_view(self):
-BookSigning.objects.create(event_date=datetime.datetime(2008, 4, 2, 
12, 0, tzinfo=timezone.utc))
+bs = BookSigning.objects.create(event_date=datetime.datetime(2008, 4, 
2, 12, 0, tzinfo=timezone.utc))
 res = self.client.get('/dates/booksignings/2008/apr/2/')
 self.assertEqual(res.status_code, 200)
 # 2008-04-02T00:00:00+03:00 (beginning of day) > 
2008-04-01T22:00:00+00:00 (book signing event date)
-
BookSigning.objects.filter(pk=1).update(event_date=datetime.datetime(2008, 4, 
1, 22, 0, tzinfo=timezone.utc))
+bs.event_date = datetime.datetime(2008, 4, 1, 22, 0, 
tzinfo=timezone.utc)
+bs.save()
 res = self.client.get('/dates/booksignings/2008/apr/2/')
 self.assertEqual(res.status_code, 200)
 # 2008-04-03T00:00:00+03:00 (end of day) > 2008-04-02T22:00:00+00:00 
(book signing event date)
-
BookSigning.objects.filter(pk=1).update(event_date=datetime.datetime(2008, 4, 
2, 22, 0, tzinfo=timezone.utc))
+bs.event_date = datetime.datetime(2008, 4, 2, 22, 0, 
tzinfo=timezone.utc)
+bs.save()
 res = self.client.get('/dates/booksignings/2008/apr/2/')
 self.assertEqual(res.status_code, 404)
 
@@ -524,20 +526,22 @@ def test_get_object_custom_queryset(self):
 self.assertEqual(res.status_code, 404)
 
 def test_datetime_date_detail(self):
-BookSigning.objects.create(event_date=datetime.datetime(2008, 4, 2, 
12, 0))
-res = self.client.get('/dates/booksignings/2008/apr/2/1/')
+bs = BookSigning.objects.create(event_date=datetime.datetime(2008, 4, 
2, 12, 0))
+res = self.client.get('/dates/booksignings/2008/apr/2/%d/' % bs.pk)
 self.assertEqual(res.status_code, 200)
 
 @override_settings(USE_TZ=True, TIME_ZONE='Africa/Nairobi')
 def test_aware_datetime_date_detail(self):
-BookSigning.objects.create(event_date=datetime.datetime(2008, 4, 2, 
12, 0, tzinfo=timezone.utc))
-res = self.client.get('/dates/booksignings/2008/apr/2/1/')
+bs = BookSigning.objects.create(event_date=datetime.datetime(2008, 4, 
2, 12, 0, tzinfo=timezone.utc))
+res = self.client.get('/dates/booksignings/2008/apr/2/%d/' % bs.pk)
 self.assertEqual(res.status_code, 200)
 # 2008-04-02T00:00:00+03:00 (beginning of day) > 
2008-04-01T22:00:00+00:00 (book signing event date)
-
BookSigning.objects.filter(pk=1).update(event_date=datetime.datetime(2008, 4, 
1, 22, 0, tzinfo=timezone.utc))
-res = self.client.get('/dates/booksignings/2008/apr/2/1/')
+bs.event_date = datetime.datetime(2008, 4, 1, 22, 0, 
tzinfo=timezone.utc)
+bs.save()
+res = self.client.get('/dates/booksignings/2008/apr/2/%d/' % bs.pk)
 self.assertEqual(res.status_code, 200)
 # 2008-04-03T00:00:00+03:00 (end of day) > 2008-04-02T22:00:00+00:00 
(book signing event date)
-
BookSigning.objects.filter(pk=1).update(event_date=datetime.datetime(2008, 4, 
2, 22, 0, tzinfo=timezone.utc))
-res = self.client.get('/dates/booksignings/2008/apr/2/1/')
+bs.event_date = datetime.datetime(2008, 4, 2, 22, 0, 
tzinfo=timezone.utc)
+bs.save()
+res = self.client.get('/dates/booksignings/2008/apr/2/%d/' % bs.pk)
 self.assertEqual(res.status_code, 404)




-- 
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] #17050: add id attribute to individual model divs in the admin index

[Django]

#17050: add id attribute to individual model divs in the admin index
---+
 Reporter:  scytale|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+
Changes (by H0ff1):

 * needs_better_patch:  1 => 0


Comment:

 I fixed it and added a Unit-Test

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

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

Re: [Django] #18252: Multi-table inheritance + ForeignKey to parent => corrupted save

[Django]

#18252: Multi-table inheritance + ForeignKey to parent => corrupted save
-+-
 Reporter:  magon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

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


Comment:

 You are going to face problems with your model definition. You have two
 "id" fields in your C model, one from A, and one from B. The fix is to
 forbid this behavior - it doesn't work currently, and there is no even
 remotely easy way to make it working (#12002, #16733, #17673). Can you
 check if adding
 {{{
 a_id = models.AutoField(db_column='id')
 }}}
 for model A, and similar 'b_id' field for model B solves your problem.

 In general you might face interesting problems with your model definition.
 The C model has effectively two different primary key fields and this is
 going to cause problems.

-- 
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] #18246: Geodjango documentation improvement

[Django]

#18246: Geodjango documentation improvement
--+
 Reporter:  jose  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  gis   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by jose):

 Replying to [comment:2 claudep]:
 > Thanks for the report. Fixed in aaa3382fdc35bfa5e26c029225a2eb190da66b79


 Thanks to you for taking into account.

 Cheers.

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

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

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

[Django]

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

Comment (by niwi):

 Changes:
  * add tests for proxied models.
  * remove all content from tests/modeltests/update_only_fields/__init__.py

 I confirm, testcases covers the first point (save related objects) and
 works 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] #18214: Serializers do not serialize iterators

[Django]

#18214: Serializers do not serialize iterators
-+-
 Reporter:  moritzs  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  serialization json   |  Needs documentation:  0
  xml|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by claudep):

 Did you purposely left the first occurrence of "Django objects" in the
 first paragraph?

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

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

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

[Django]

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

Comment (by niwi):

 Replying to [comment:87 aaugustin]:
 > The code looks generally sane to me.
 >
 > A few remarks:
 > * Does the code behave properly with related models -- ie. you can
 `save(update_fields=['related'])` rather than
 `save(update_fields=['related_id'])`? I haven't seen a test for this.

 I will check this part and add more tests if necessary.

 > * There are tests for inherited models, which is a good idea. I'm not
 sufficiently familiar with the implementation of the ORM to tell if other
 features (like proxy models) are worth testing. If you think they are, a
 few more tests would be nice.

 In my opinion, this does not affect these things. Only does the filter
 fields that enter the UPDATE statement. The rest of the default behavior
 is as if suddenly the model happens to have less fields than actually
 have.
 In any case, I see to do more tests to be sure.

 > * This isn't a minor feature, it deserves a full paragraph in the
 release notes.

 This part of me is complicated for me. My English is not very good.

 > * `tests/modeltests/update_only_fields/__init__.py` should be totally
 empty.

 ;)

-- 
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/django] aaa338: Fixed #18246 -- Replaced bash-specific syntax in g...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: aaa3382fdc35bfa5e26c029225a2eb190da66b79
  
https://github.com/django/django/commit/aaa3382fdc35bfa5e26c029225a2eb190da66b79
  Author: Claude Paroz 
  Date:   2012-05-01 (Tue, 01 May 2012)

  Changed paths:
M docs/ref/contrib/gis/create_template_postgis-debian.sh

  Log Message:
  ---
  Fixed #18246 -- Replaced bash-specific syntax in geodjango postgis helper 
script.

Thanks jose for the report.


diff --git a/docs/ref/contrib/gis/create_template_postgis-debian.sh 
b/docs/ref/contrib/gis/create_template_postgis-debian.sh
index ac9641d..3e62183 100755
--- a/docs/ref/contrib/gis/create_template_postgis-debian.sh
+++ b/docs/ref/contrib/gis/create_template_postgis-debian.sh
@@ -38,7 +38,7 @@ psql -d template_postgis -f 
$POSTGIS_SQL_PATH/spatial_ref_sys.sql && \
 psql -d template_postgis -c "GRANT ALL ON geometry_columns TO PUBLIC;" && \
 psql -d template_postgis -c "GRANT ALL ON spatial_ref_sys TO PUBLIC;"
 
-if ((GEOGRAPHY))
+if [ $GEOGRAPHY -eq 1 ]
 then
 psql -d template_postgis -c "GRANT ALL ON geography_columns TO PUBLIC;"
 fi




-- 
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] #18246: Geodjango documentation improvement

[Django]

#18246: Geodjango documentation improvement
--+
 Reporter:  jose  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  gis   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

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


Comment:

 Thanks for the report. Fixed in aaa3382fdc35bfa5e26c029225a2eb190da66b79

-- 
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] #18246: Geodjango documentation improvement

[Django]

#18246: Geodjango documentation improvement
--+
 Reporter:  jose  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 OK, it seems that the `((` syntax is not supported by dash, for example.

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

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

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

[Django]

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

Comment (by aaugustin):

 The code looks generally sane to me.

 A few remarks:
 * Does the code behave properly with related models -- ie. you can
 `save(update_fields=['related'])` rather than
 `save(update_fields=['related_id'])`? I haven't seen a test for this.
 * There are tests for inherited models, which is a good idea. I'm not
 sufficiently familiar with the implementation of the ORM to tell if other
 features (like proxy models) are worth testing. If you think they are, a
 few more tests would be nice.
 * This isn't a minor feature, it deserves a full paragraph in the release
 notes.
 * `tests/modeltests/update_only_fields/__init__.py` should be totally
 empty.

-- 
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] #18252: Multi-table inheritance + ForeignKey to parent => corrupted save

[Django]

#18252: Multi-table inheritance + ForeignKey to parent => corrupted save
--+
 Reporter:  magon@…   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I have a models like in this minimal test case:
 {{{
 class A(models.Model):
 title = models.CharField(max_length=100)

 def __str__(self):
 return "Title(%s)" % self.title

 class B(models.Model):
 more = models.CharField(max_length=100)

 def __str__(self):
 return "More(%s)" % (self.more)

 #class C(B, A):
 class C(A, B):
 def __str__(self):
 return "%s %s %s" % (self.problem, self.title, self.more)
 problem = models.ForeignKey(B, related_name='problem')

 }}}

 Saving "C" is corrupted in this case.[[BR]]
 It is best ilustrated here:
 {{{
 Presave:
 More(more 1) title more 2
 Retrieved afted save:
 More(more 2) title more 2
 }}}

 It should output the same two lines, but the the second is
 different.[[BR]]
 Here are the queries performed:
 {{{
 {'time': '0.000', 'sql': u'INSERT INTO "save_b" ("more") VALUES (more 1)'}
 {'time': '0.000', 'sql': u'INSERT INTO "save_a" ("title") VALUES (title)'}
 {'time': '0.000', 'sql': u'SELECT (1) AS "a" FROM "save_b" WHERE
 "save_b"."id" = 1  LIMIT 1'}
 {'time': '0.000', 'sql': u'UPDATE "save_b" SET "more" = more 2 WHERE
 "save_b"."id" = 1 '}
 {'time': '0.000', 'sql': u'SELECT (1) AS "a" FROM "save_c" WHERE
 "save_c"."a_ptr_id" = 1  LIMIT 1'}
 {'time': '0.000', 'sql': u'INSERT INTO "save_c" ("b_ptr_id", "a_ptr_id",
 "problem_id") SELECT 1 AS "b_ptr_id", 1 AS "a_ptr_id", 1 AS "problem_id"'}
 {'time': '0.000', 'sql': u'SELECT "save_a"."id", "save_a"."title",
 "save_b"."id", "save_b"."more", "save_c"."b_ptr_id", "save_c"."a_ptr_id",
 "save_c"."problem_id" FROM "save_c" INNER JOIN "save_b" ON
 ("save_c"."b_ptr_id" = "save_b"."id") INNER JOIN "save_a" ON
 ("save_c"."a_ptr_id" = "save_a"."id") WHERE "save_c"."b_ptr_id" = 1 '}
 {'time': '0.000', 'sql': u'SELECT "save_b"."id", "save_b"."more" FROM
 "save_b" WHERE "save_b"."id" = 1 '}
 }}}
 The problem is in the "UPDATE" there. It should be an insert. It seems
 like it have set "pk" after the first line, but it should be unset.

 Interchanging the commented line with the one below solves the problem.
 But for another reasons I need them this way, not the other way around.

-- 
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] #18163: Use a faster password hasher in test_sqlite.py

[Django]

#18163: Use a faster password hasher in test_sqlite.py
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  contrib.auth |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * stage:  Accepted => Ready for checkin


Comment:

 LGTM.

-- 
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] #18243: Management shell should make it easy to force LOGGING_CONFIG=None

[Django]

#18243: Management shell should make it easy to force LOGGING_CONFIG=None
-+-
 Reporter:  ncoghlan@…   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 Thanks Vinay, your input is much appreciated.

 I'm still not sure about what you recommend to do.

 Currently, the logging configuration is an opt-out process in all cases.
 As described in the ticket description, an opt-out method can be to set
 LOGGING_CONFIG to None in the settings file.

 Do you think that this should be an opt-in process? Currently, my opinion
 is that logging configuration is wanted in 95% of use cases, and for the
 remaining 5%, the current opt-out method is available. I'm afraid that if
 we don't configure logging by default, this will be forgotten most of the
 time.

-- 
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] #17742: `DateTimeField` may not behave very well when it is set or compared to a `date` and time zone support is active

[Django]

#17742: `DateTimeField` may not behave very well when it is set or compared to a
`date` and time zone support is active
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 Fixed in 46b082e05ccedffeb623028caf70adbaba7bce6f.

-- 
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] #18194: File-based session never expire

[Django]

#18194: File-based session never expire
--+
 Reporter:  ej|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.4
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by crodjer):

 * cc: crodjer@… (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] #18243: Management shell should make it easy to force LOGGING_CONFIG=None

[Django]

#18243: Management shell should make it easy to force LOGGING_CONFIG=None
-+-
 Reporter:  ncoghlan@…   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by vsajip):

 I'm not a core Django committer, but as the maintainer of logging I do
 agree with Nick that doing logging configuration as a side-effect of
 import is not good. It's fine to provide a convenience API (ideally, an
 idempotent one) to configure logging, and to document that; that API can
 be called either by client code or by Django code in code paths where
 Django is being run as a management script. The problem with assuming
 you'll always want to configure logging automagically is that you can't be
 sure how people want to use Django, which might not be in a conventional
 way. For example, I've seen people trying to use just the ORM part. And
 since Django is used as part of a bigger system, that system's developers
 might want to choose exactly when to configure logging. It should always
 be under the control of the application (as opposed to library or
 framework) developer.

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

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

Re: [Django] #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:  master
 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 carlospalol):

 * cc: carlospalol (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] #18249: strange error with django-admin.py startproject myproject. Run with /bin/zsh

[Django]

#18249: strange error with django-admin.py startproject myproject.  Run with
/bin/zsh
-+-
 Reporter:  lucassrod@…  |Owner:  Lucas
 Type:  Uncategorized|  Simon
Component:  Testing framework|   Status:  closed
 Severity:  Normal   |  Version:  1.4
 Keywords:  django-  |   Resolution:  duplicate
  admin.py,django,ksh,bash   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by ramiro):

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


Comment:

 It is most surely you have a previous global installation of Django
 alreadyinstalled and things are mixing. You need to manually cleanup any
 older Django version you had installed we are trying to figure out how to
 get the Django installation process/procedure to do/document that in
 #18115.  I'm closing this ticket as duplicate.

 This is related to this: Why are you running your ``pip install Packages``
 with sudo? I suspect with that you are installing Django to the global
 level.

 Precisely the point of using virtualenv (i.e. creating a virtual
 environment and activating it) it to be able to install these packages
 locally (inside the virtualenv) and as a normal user.

-- 
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] #18250: Comparing two unsaved model objects

[Django]

#18250: Comparing two unsaved model objects
-+-
 Reporter:  yrdnsa@… |Owner:  Yarden
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  compare model|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_better_patch:   => 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] #18233: file_move_safe overwrites destination file

[Django]

#18233: file_move_safe overwrites destination file
--+
 Reporter:  anonymous |Owner:  aviraldg
 Type:  Bug   |   Status:  assigned
Component:  File uploads/storage  |  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 |UI/UX:  0
--+
Changes (by moritzs):

 * needs_better_patch:  0 => 1


Comment:

 The attached file should contain the tests, even if they're in the pull
 request, until the core devs announce how to deal with pull requests.

 Besides, the IOError's message should read 'Destination file already
 exists'

-- 
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] #18182: Raw password echoed on authentication if no hashing used

[Django]

#18182: Raw password echoed on authentication if no hashing used
--+
 Reporter:  danielr   |Owner:  moritzs
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by moritzs):

 * cc: moritzs (added)
 * has_patch:  0 => 1


Comment:

 Added patch ([https://github.com/django/django/pull/34 Github Pull
 Request])

 contrib.auth.hashers.is_password_usable now checks if the encoded string
 contains a $ character. For backward compatibilty to unsalted md5 hashes
 all encoded 32-character-long strings without a $ character are assumed to
 be usable. check_password won't return True for a 32-character-long plain
 password, though.

-- 
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] #12728: loadata/flush issues given GenericRelation, model inheritance and postgres

[Django]

#12728: loadata/flush issues given GenericRelation, model inheritance and 
postgres
-+-
 Reporter:  pragmar  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  contrib.contenttypes   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
  psycopg2.ProgrammingError, |  Patch needs improvement:  0
  GenericRelation|UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by chrischambers):

 * cc: magma.chambers@… (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] #4136: NULL fields and Unique keys

[Django]

#4136: NULL fields and Unique keys
-+-
 Reporter:  David Cramer |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:  1.3-rc1
Component:  Forms|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by aashu_dwivedi):

 * cc: aashu_dwivedi (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] #5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")

[Django]

#5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")
-+
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  sprintdec01  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by aashu_dwivedi):

 * cc: aashu_dwivedi (added)


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

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

[Django] #18251: multithreading deadlock in django.models.loading.get_apps

[Django]

#18251: multithreading deadlock in django.models.loading.get_apps
---+
 Reporter:  harm   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 On a production site we have encountered  deadlocks, which after fierce
 investigation pointed to the django internals.

 We use a deployment: apache/mod_wsgi
 apache config:
 {{{
 WSGIDaemonProcess  processes=1 threads=10 umask=0002 display-
 name=%{GROUP} stack-size=524288
 }}}


 == details of deadlock ==
 During the bootstrap of django, so the first requests it handles,  a
 classic ABBA deadlock can occur.
 This results in that django never boots, and that NO requests are handled.
 Just restarting apache works, (hoping that the same deadlock does not
 appear again).

 description of deadlock
 {{{
 thread A   thread B

  request foo
  import foo.views.py
  import foo.models.py  request 'bar'
import
 bar.models.py (acquires import lock B)
  bootstraps django
  calls django.models.loading.get_apps()
 self.write_lock.acquire()  (lock A!)
 load app apps
 . . .
 django.models.loading.get_apps()
 import bar.models.py  (takes import lock. lock B!)
 self.write_lock.acquire()  (lock A!)

   

 }}}


 NB: this exact deadlock was '''actually''' seen in stracktraces. This is
 not a guess.

 == How to reproduce ==
 its hard to reproduce, you need high volume traffic + multithreaded
 deployement + a big enough application that different urls trigger
 compelete different code paths in your project.

 I am not able to produce a simple test project that demonstrates this
 problem

 We had a 100% reproducible setup, where the site would lock up (almost)
 every time when we touched wsgi.py during peak hours of the day.

 1. When you have a projects that is not multithreaded deployed -> this
 problem does not happen
 2. When your application has a limited set of urls/views so that all
 initial calls follow same code paths -> this problem does not happen
 3. When application has low traffic (the very first request can finish,
 without other requests beeing made) -> this problem does not happen.


 == Workaround ==
 We use the attached {{{DjangoWSGIHandler}}} wrapper as a workaround. That
 solved the problem 100 % for us.
 Its a drop-in replacement for {{{ DjangoWSGIHandler }}} and effectively
 disables multithreading the first few request (allowing django to
 bootstrap properly), and only afther the first requests act multitheading
 again.

 Please consider if this workaround should be applied to django itself.
 (Put the Lock HIGHER the chain, to the wsgi handler level)

 == Fix ==
 Some init locking should be adding to  {{{ DjangoWSGIHandler }}}  around
 the complete request.
 django.core.handlers.wsgi.WSGIHandler() has such lock around middleware
 loading.
 {{{
 #!python

if self._request_middleware is None:
self.initLock.acquire()
 }}}

 Something similar should be around the complete request, not just
 middleware loading.
 But only the very first 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] #4102: Allow UPDATE of only specific fields in model.save()

[Django]

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

Comment (by niwi):

 Current pull request in one commit
 https://github.com/django/django/pull/33

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

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

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

[Django]

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

Comment (by niwi):

 Here is the latest patch, reviewed by akaariai in the pull request
 (https://github.com/django/django/pull/4)

-- 
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] #18182: Raw password echoed on authentication if no hashing used

[Django]

#18182: Raw password echoed on authentication if no hashing used
--+
 Reporter:  danielr   |Owner:  moritzs
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by moritzs):

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


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

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

[Django] #18250: Comparing two unsaved model objects

[Django]

#18250: Comparing two unsaved model objects
--+---
 Reporter:  yrdnsa@…  |  Owner:  Yarden
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:  compare model
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 if i do this:

 User(email="exm...@example.com") == User(email="exmpl...@example22.com")

 it will return True!

 but if i save them- it will return False.
 this is because the __eq__ magic method tries to compare their PK's. if no
 pk it will return None. so None == None...

 django.db.models.base line 383
 def __eq__

-- 
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/django] 6ac8af: Add @gsong to AUTHORS

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6ac8afc3f927f5e41c84dcc16c56ff6458338d87
  
https://github.com/django/django/commit/6ac8afc3f927f5e41c84dcc16c56ff6458338d87
  Author: George Song 
  Date:   2012-04-30 (Mon, 30 Apr 2012)

  Changed paths:
M AUTHORS

  Log Message:
  ---
  Add @gsong to AUTHORS

See  for my contribution.


diff --git a/AUTHORS b/AUTHORS
index e3aec98..db6ce11 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -478,6 +478,7 @@ answer newbie questions, and generally made Django that 
much better:
 Warren Smith 
 sm...@smurf.noris.de
 Vsevolod Solovyov
+George Song 
 sopel
 Leo Soto 
 Wiliam Alves de Souza 



  Commit: f8cfc83ec6642c24966c90bf99248bf8fafbfd8d
  
https://github.com/django/django/commit/f8cfc83ec6642c24966c90bf99248bf8fafbfd8d
  Author: Adrian Holovaty 
  Date:   2012-04-30 (Mon, 30 Apr 2012)

  Changed paths:
M AUTHORS

  Log Message:
  ---
  Merge pull request #31 from gsong/add-to-authors

Added @gsong to AUTHORS


diff --git a/AUTHORS b/AUTHORS
index e3aec98..db6ce11 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -478,6 +478,7 @@ answer newbie questions, and generally made Django that 
much better:
 Warren Smith 
 sm...@smurf.noris.de
 Vsevolod Solovyov
+George Song 
 sopel
 Leo Soto 
 Wiliam Alves de Souza 



Compare: https://github.com/django/django/compare/ddfc7c2...f8cfc83

-- 
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/django] 4fdd37: Skip model validation when models are known good.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 4fdd378beb81a86d826d7ee83c7d2250ed958be1
  
https://github.com/django/django/commit/4fdd378beb81a86d826d7ee83c7d2250ed958be1
  Author: Anssi Kääriäinen 
  Date:   2012-04-30 (Mon, 30 Apr 2012)

  Changed paths:
M django/core/management/base.py
M django/core/management/commands/syncdb.py
M django/test/testcases.py

  Log Message:
  ---
  Skip model validation when models are known good.

In some situations Django calls model validation when the models are
already known good. This is most visible in tests, which use flush
and loaddata commands. This resulted in around 10% overhead when
running tests under sqlite.


diff --git a/django/core/management/base.py b/django/core/management/base.py
index 2a04c25..a936877 100644
--- a/django/core/management/base.py
+++ b/django/core/management/base.py
@@ -198,9 +198,9 @@ def execute(self, *args, **options):
 """
 Try to execute this command, performing model validation if
 needed (as controlled by the attribute
-``self.requires_model_validation``). If the command raises a
-``CommandError``, intercept it and print it sensibly to
-stderr.
+``self.requires_model_validation``, except if force-skipped). If the
+command raises a ``CommandError``, intercept it and print it sensibly
+to stderr.
 """
 show_traceback = options.get('traceback', False)
 
@@ -226,7 +226,7 @@ def execute(self, *args, **options):
 try:
 self.stdout = options.get('stdout', sys.stdout)
 self.stderr = options.get('stderr', sys.stderr)
-if self.requires_model_validation:
+if self.requires_model_validation and not 
options.get('skip_validation'):
 self.validate()
 output = self.handle(*args, **options)
 if output:
diff --git a/django/core/management/commands/syncdb.py 
b/django/core/management/commands/syncdb.py
index 91f0aec..88caea1 100644
--- a/django/core/management/commands/syncdb.py
+++ b/django/core/management/commands/syncdb.py
@@ -160,4 +160,5 @@ def model_installed(model):
 # Load initial_data fixtures (unless that has been disabled)
 if load_initial_data:
 from django.core.management import call_command
-call_command('loaddata', 'initial_data', verbosity=verbosity, 
database=db)
+call_command('loaddata', 'initial_data', verbosity=verbosity,
+ database=db, skip_validation=True)
diff --git a/django/test/testcases.py b/django/test/testcases.py
index c9fe1b3..e2d7b3f 100644
--- a/django/test/testcases.py
+++ b/django/test/testcases.py
@@ -468,13 +468,14 @@ def _fixture_setup(self):
 else:
 databases = [DEFAULT_DB_ALIAS]
 for db in databases:
-call_command('flush', verbosity=0, interactive=False, database=db)
+call_command('flush', verbosity=0, interactive=False, database=db,
+ skip_validation=True)
 
 if hasattr(self, 'fixtures'):
 # We have to use this slightly awkward syntax due to the fact
 # that we're using *args and **kwargs together.
 call_command('loaddata', *self.fixtures,
- **{'verbosity': 0, 'database': db})
+ **{'verbosity': 0, 'database': db, 
'skip_validation': True})
 
 def _urlconf_setup(self):
 if hasattr(self, 'urls'):
@@ -826,7 +827,8 @@ def _fixture_setup(self):
  **{
 'verbosity': 0,
 'commit': False,
-'database': db
+'database': db,
+'skip_validation': True,
  })
 
 def _fixture_teardown(self):




-- 
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/django] 1f0f68: Add @leereilly to contributor list.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1f0f686852f056deee4f8b340f9888a3bfc392db
  
https://github.com/django/django/commit/1f0f686852f056deee4f8b340f9888a3bfc392db
  Author: Lee Reilly 
  Date:   2012-04-30 (Mon, 30 Apr 2012)

  Changed paths:
M AUTHORS

  Log Message:
  ---
  Add @leereilly to contributor list.

See commit message at for https://code.djangoproject.com/changeset/16324 
verification.


diff --git a/AUTHORS b/AUTHORS
index e3aec98..30ef369 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -563,6 +563,7 @@ answer newbie questions, and generally made Django that 
much better:
 Gasper Zejn 
 Jarek Zgoda 
 Cheng Zhang
+Lee Reilly 
 
 A big THANK YOU goes to:
 



  Commit: f5a80f58e1848aefe6688d93b08b33457b370799
  
https://github.com/django/django/commit/f5a80f58e1848aefe6688d93b08b33457b370799
  Author: Lee Reilly 
  Date:   2012-04-30 (Mon, 30 Apr 2012)

  Changed paths:
M AUTHORS

  Log Message:
  ---
  Moved Lee Reilly's entry to the correct location


diff --git a/AUTHORS b/AUTHORS
index 30ef369..5943a27 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -433,6 +433,7 @@ answer newbie questions, and generally made Django that 
much better:
 Philippe Raoult 
 Massimiliano Ravelli 
 Brian Ray 
+Lee Reilly 
 Łukasz Rekucki 
 re...@diji.biz
 Marc Remolt 
@@ -563,7 +564,6 @@ answer newbie questions, and generally made Django that 
much better:
 Gasper Zejn 
 Jarek Zgoda 
 Cheng Zhang
-Lee Reilly 
 
 A big THANK YOU goes to:
 



  Commit: 583f1d74256861994543f060290ee73020be35da
  
https://github.com/django/django/commit/583f1d74256861994543f060290ee73020be35da
  Author: Adrian Holovaty 
  Date:   2012-04-30 (Mon, 30 Apr 2012)

  Changed paths:
M AUTHORS

  Log Message:
  ---
  Merge pull request #27 from leereilly/update-authors

Added @leereilly to contributor list.


diff --git a/AUTHORS b/AUTHORS
index db6ce11..ded2ff6 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -433,6 +433,7 @@ answer newbie questions, and generally made Django that 
much better:
 Philippe Raoult 
 Massimiliano Ravelli 
 Brian Ray 
+Lee Reilly 
 Łukasz Rekucki 
 re...@diji.biz
 Marc Remolt 



Compare: https://github.com/django/django/compare/f8cfc83...583f1d7

-- 
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/django] 46b082: Fixed #17742 -- Handled aware datetimes in DateFie...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 46b082e05ccedffeb623028caf70adbaba7bce6f
  
https://github.com/django/django/commit/46b082e05ccedffeb623028caf70adbaba7bce6f
  Author: Aymeric Augustin 
  Date:   2012-05-01 (Tue, 01 May 2012)

  Changed paths:
M django/db/models/fields/__init__.py
M tests/modeltests/timezones/models.py
M tests/modeltests/timezones/tests.py

  Log Message:
  ---
  Fixed #17742 -- Handled aware datetimes in DateField

Converted aware datetimes to the default time zone before using them
in the context of a DateField.


diff --git a/django/db/models/fields/__init__.py 
b/django/db/models/fields/__init__.py
index 3e97f6c..79fb373 100644
--- a/django/db/models/fields/__init__.py
+++ b/django/db/models/fields/__init__.py
@@ -667,6 +667,11 @@ def to_python(self, value):
 if value is None:
 return value
 if isinstance(value, datetime.datetime):
+if settings.USE_TZ and timezone.is_aware(value):
+# Convert aware datetimes to the current time zone
+# before casting them to dates (#17742).
+default_timezone = timezone.get_default_timezone()
+value = timezone.make_naive(value, default_timezone)
 return value.date()
 if isinstance(value, datetime.date):
 return value
diff --git a/tests/modeltests/timezones/models.py 
b/tests/modeltests/timezones/models.py
index f0cc792..c49e42f 100644
--- a/tests/modeltests/timezones/models.py
+++ b/tests/modeltests/timezones/models.py
@@ -16,3 +16,6 @@ class SessionEvent(models.Model):
 class Timestamp(models.Model):
 created = models.DateTimeField(auto_now_add=True)
 updated = models.DateTimeField(auto_now=True)
+
+class AllDayEvent(models.Model):
+day = models.DateField()
diff --git a/tests/modeltests/timezones/tests.py 
b/tests/modeltests/timezones/tests.py
index 90bc1f3..ddfbc04 100644
--- a/tests/modeltests/timezones/tests.py
+++ b/tests/modeltests/timezones/tests.py
@@ -23,7 +23,7 @@
 from django.utils.unittest import skipIf, skipUnless
 
 from .forms import EventForm, EventSplitForm, EventModelForm
-from .models import Event, MaybeEvent, Session, SessionEvent, Timestamp
+from .models import Event, MaybeEvent, Session, SessionEvent, Timestamp, 
AllDayEvent
 
 
 # These tests use the EAT (Eastern Africa Time) and ICT (Indochina Time)
@@ -244,6 +244,14 @@ def test_raw_sql(self):
 [event],
 transform=lambda d: d)
 
+def test_filter_date_field_with_aware_datetime(self):
+# Regression test for #17742
+day = datetime.date(2011, 9, 1)
+event = AllDayEvent.objects.create(day=day)
+# This is 2011-09-02T01:30:00+03:00 in EAT
+dt = datetime.datetime(2011, 9, 1, 22, 30, 0, tzinfo=UTC)
+self.assertTrue(AllDayEvent.objects.filter(day__gte=dt).exists())
+
 
 @override_settings(TIME_ZONE='Africa/Nairobi', USE_TZ=True)
 class NewDatabaseTests(TestCase):
@@ -456,8 +464,16 @@ def test_raw_sql(self):
 [event],
 transform=lambda d: d)
 
+def test_filter_date_field_with_aware_datetime(self):
+# Regression test for #17742
+day = datetime.date(2011, 9, 1)
+event = AllDayEvent.objects.create(day=day)
+# This is 2011-09-02T01:30:00+03:00 in EAT
+dt = datetime.datetime(2011, 9, 1, 22, 30, 0, tzinfo=UTC)
+self.assertFalse(AllDayEvent.objects.filter(day__gte=dt).exists())
+
 def test_null_datetime(self):
-# Regression for #17294
+# Regression test for #17294
 e = MaybeEvent.objects.create()
 self.assertEqual(e.dt, None)
 



  Commit: 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3
  
https://github.com/django/django/commit/80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3
  Author: Aymeric Augustin 
  Date:   2012-05-01 (Tue, 01 May 2012)

  Changed paths:
M docs/ref/class-based-views.txt

  Log Message:
  ---
  Clarified warning about date-based generic views.


diff --git a/docs/ref/class-based-views.txt b/docs/ref/class-based-views.txt
index 5d30869..174539d 100644
--- a/docs/ref/class-based-views.txt
+++ b/docs/ref/class-based-views.txt
@@ -750,9 +750,15 @@ DateMixin
 
 When :doc:`time zone support ` is enabled and
 ``date_field`` is a ``DateTimeField``, dates are assumed to be in the
-current time zone. As a consequence, if you have implemented per-user
-time zone selection, users living in different time zones may view a
-different set of objects at the same URL.
+current time zone. Otherwise, the queryset could include objects from
+the previous or the next day in the end user's time zone.
+
+.. warning::
+
+In this situation, if you have implemented per-user time zone
+selection, the same URL may show a different set o

Re: [Django] #17742: `DateTimeField` may not behave very well when it is set or compared to a `date` and time zone support is active

[Django]

#17742: `DateTimeField` may not behave very well when it is set or compared to a
`date` and time zone support is active
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * has_patch:  0 => 1
 * needs_tests:  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] #17742: `DateTimeField` may not behave very well when it is set or compared to a `date` and time zone support is active

[Django]

#17742: `DateTimeField` may not behave very well when it is set or compared to a
`date` and time zone support is active
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 All other automatic conversions in the database layer use the default time
 zone. The current time zone is only used in the forms and template layers.
 For predictability, I'm leaning towards using the default time zone.

 For single time zone sites, this doesn't matter, because the current time
 zone is always the default time zones. For multi time zones sites, I
 suppose the programmer can understand the issue and create explicitly the
 date he wants. (Also, I don't see that many use cases for comparing a
 DateField to a datetime.)

-- 
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] #1028: High-level feed framework should make more feed elements available

[Django]

#1028: High-level feed framework should make more feed elements available
-+-
 Reporter:  ubernostrum  |Owner:
 Type:  New feature  |  tylerdavis
Component:  contrib.syndication  |   Status:  assigned
 Severity:  Normal   |  Version:  1.2-alpha
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by tylerdavis):

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


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