[Changeset] r11708 - django/branches/releases/1.1.X/django/contrib/gis/gdal

[noreply]

Author: jbronn
Date: 2009-11-03 00:18:52 -0600 (Tue, 03 Nov 2009)
New Revision: 11708

Modified:
   django/branches/releases/1.1.X/django/contrib/gis/gdal/geometries.py
Log:
[1.1.X] Fixed #12101 -- `OGRGeometry` does not need to create a clone of the 
`SpatialReference` object upon assignment.

Backport of r11707 from trunk.


Modified: django/branches/releases/1.1.X/django/contrib/gis/gdal/geometries.py
===
--- django/branches/releases/1.1.X/django/contrib/gis/gdal/geometries.py
2009-11-03 06:16:09 UTC (rev 11707)
+++ django/branches/releases/1.1.X/django/contrib/gis/gdal/geometries.py
2009-11-03 06:18:52 UTC (rev 11708)
@@ -256,11 +256,15 @@
 
 def _set_srs(self, srs):
 "Sets the SpatialReference for this geometry."
+# Do not have to clone the `SpatialReference` object pointer because
+# when it is assigned to this `OGRGeometry` it's internal OGR
+# reference count is incremented, and will likewise be released
+# (decremented) when this geometry's destructor is called.
 if isinstance(srs, SpatialReference):
-srs_ptr = srs_api.clone_srs(srs.ptr)
+srs_ptr = srs.ptr
 elif isinstance(srs, (int, long, basestring)):
 sr = SpatialReference(srs)
-srs_ptr = srs_api.clone_srs(sr.ptr)
+srs_ptr = sr.ptr
 else:
 raise TypeError('Cannot assign spatial reference with object of 
type: %s' % type(srs))
 capi.assign_srs(self.ptr, srs_ptr)


--~--~-~--~~~---~--~~
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] r11707 - django/trunk/django/contrib/gis/gdal

[noreply]

Author: jbronn
Date: 2009-11-03 00:16:09 -0600 (Tue, 03 Nov 2009)
New Revision: 11707

Modified:
   django/trunk/django/contrib/gis/gdal/geometries.py
Log:
Fixed #12101 -- `OGRGeometry` does not need to create a clone of the 
`SpatialReference` object upon assignment.


Modified: django/trunk/django/contrib/gis/gdal/geometries.py
===
--- django/trunk/django/contrib/gis/gdal/geometries.py  2009-11-02 08:27:00 UTC 
(rev 11706)
+++ django/trunk/django/contrib/gis/gdal/geometries.py  2009-11-03 06:16:09 UTC 
(rev 11707)
@@ -256,11 +256,15 @@
 
 def _set_srs(self, srs):
 "Sets the SpatialReference for this geometry."
+# Do not have to clone the `SpatialReference` object pointer because
+# when it is assigned to this `OGRGeometry` it's internal OGR
+# reference count is incremented, and will likewise be released
+# (decremented) when this geometry's destructor is called.
 if isinstance(srs, SpatialReference):
-srs_ptr = srs_api.clone_srs(srs.ptr)
+srs_ptr = srs.ptr
 elif isinstance(srs, (int, long, basestring)):
 sr = SpatialReference(srs)
-srs_ptr = srs_api.clone_srs(sr.ptr)
+srs_ptr = sr.ptr
 else:
 raise TypeError('Cannot assign spatial reference with object of 
type: %s' % type(srs))
 capi.assign_srs(self.ptr, srs_ptr)


--~--~-~--~~~---~--~~
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] #12134: contrib.admin.RelatedFieldWidgetWrapper.__deepcopy__() should copy() the widget attrs

[Django]

#12134: contrib.admin.RelatedFieldWidgetWrapper.__deepcopy__() should copy() the
widget attrs
--+-
 Reporter:  ubernostrum   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Otherwise it ends up with a shallow copy which reuses the same attrs dict
 across separate widget instances, playing merry hell with form classes
 which want to change widget attrs on a per-(form)-instance basis.

-- 
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] #12125: [patch] The tests for date-based generic views fail in november

[Django]

#12125: [patch] The tests for date-based generic views fail in november
+---
  Reporter:  brutasse   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Generic views  |   Version:  SVN   
Resolution:  fixed  |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by sztamas):

 I've just got this bug myself while running the Django tests, but checked
 if it's fixed before I raised a bug and found out that it was :)

 I don't think that test is very well written.

 You should have tests at the boundaries of years with the setUp and
 assertions values hard-coded (ex. 2004/01/01, 2003/12/01).
 I don't see what the value is in a setUp value that changes and then you
 have to calculate your assertions based on that.
 IMHO, it would be better to be able to have fixed the inputs and therefore
 fixed expectations that you can consistently run without being affected by
 external factors (like system 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
-~--~~~~--~~--~--~---

[Django] #12133: tutorial 4 - generic view and vote view

[Django]

#12133: tutorial 4 - generic view and vote view
---+
 Reporter:  dotdat |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 In the last part of tutorial 4, it mention that in order to get the vote()
 view working, just change:

 {{{return HttpResponseRedirect(reverse('poll_results', args=(p.id,))) }}}

 However in the vote() view, the exception handling code also needs to
 change to reference the new poll_detail.html template and change poll
 object name 'poll' to 'object' since the poll_detail.html was changed to
 use the generic view.

 This is more of a clarification and nothing really wrong with the
 tutorial.

-- 
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] #11952: HttpResponse Attribute docs refer to "status" when should be "status_code"

[Django]

#11952: HttpResponse Attribute docs refer to "status" when should be 
"status_code"
+---
  Reporter:  pjs| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

  * has_patch:  0 => 1

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

Re: [Django] #12131: Translation not recognized when not using requests

[Django]

#12131: Translation not recognized when not using requests
-+--
  Reporter:  dauerbaustelle  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Translations|   Version:  1.1   
Resolution:  worksforme  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jezdez):

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

Comment:

 You probably want to use {{{django.utils.translation.ugettext_lazy}}}
 instead of {{{ugettext}}} to translate strings dynamically dependending on
 the request/response cycle (e.g. with the LocaleMiddleware).

-- 
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] #12132: possibly unneccessary unique_check for primary key fields is models

[Django]

#12132: possibly unneccessary unique_check for primary key fields is models
+---
 Reporter:  Mark|   Owner:  nobody  

   Status:  new |   Milestone:  

Component:  Database layer (models, ORM)| Version:  
soc2009/model-validation
 Keywords:  model-validation validation unique  |   Stage:  Unreviewed  

Has_patch:  1   |  
+---
 Every time a clean() method of the model instance is run,
 validate_unique() is performed. It seems, that _get_unique_checks doesn't
 get into account, that the primary key doesn't need such a check. The sql
 that is run during the check is meaningless (it is only meaningless if we
 are checking a primary key field):

 {{{
 SELECT (1) AS "a" FROM "test_models_testmodel" WHERE
 ("test_models_testmodel"."id" = 1  AND NOT ("test_models_testmodel"."id" =
 1 ))
 }}}


 This results in unnecessary database hits and (possible) performance
 degradation. I have put together a simple test rack, so that the effect
 can be easily observed. It's not a real test case, but I really hope, that
 it will be sufficient.

 If I understand correctly, it can be easily fixed, by checking if a field
 is a primary key inside the _get_unique_checks model instance method
 (patch included).

-- 
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] #12131: Translation not recognized when not using requests

[Django]

#12131: Translation not recognized when not using requests
+---
 Reporter:  dauerbaustelle  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Translations| Version:  1.1   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Hi there,

 I'm currently using django's ORM and translation library
 [http://bitbucket.org/Dauerbaustelle/django-lists for a project]. I'm
 using `ugettext` for marking strings as translatable and `LANGUAGE_CODE`
 is correctly set ("de-DE" in my case). However, django does not correctly
 recognize the language, `django.utils.translation.get_language()` always
 returns the default "en-us". If I set the language manually via
 `activate(...)`, `get_language` returns that language code but the actual
 translation seems to have happened before so there's no way to get the
 translated strings.

 By the way, using django's admin interface the right language is used. I
 have added the `LocalizationMiddleware` to the list of active middlewares.
 Don't hesitate to go through the code linked above.

 Regards

-- 
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] #8995: django.contrib.sitemaps enhancements

[Django]

#8995: django.contrib.sitemaps enhancements
---+
  Reporter:  john  | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  Contrib apps  |   Version:  SVN 
Resolution:|  Keywords:  sitemaps
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by miracle2k):

 It seems yahoo is pinged twice by this patch, once with the sitemap url
 (super call), and then again with the base url. Any particular reason for
 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
-~--~~~~--~~--~--~---

Re: [Django] #11331: Memcached backend closes connection after every request

[Django]

#11331: Memcached backend closes connection after every request
-+--
  Reporter:  boo...@gmail.com| Owner:  nobody
Status:  new | Milestone:
 Component:  Cache system|   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by jhenry):

 I am also experiencing this problem while using cmemcached.  My solution
 was to remove the signal applied in #5133 in my local branch since I do
 not have problems with connection limits in a prefork multiprocess
 deployment, but the proper solution would seem to be smarter connection
 pooling instead of closing and reopening a connection to the memcached
 server on every single 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] #399: Bigint field object needed

[Django]

#399: Bigint field object needed
---+
  Reporter:  jmad...@techie.com| Owner:  permon 
 
Status:  assigned  | Milestone:  1.2
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:|  Keywords:  
sprintsept14, bigint
 Stage:  Design decision needed| Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  1 |  
---+
Comment (by mwdiers):

 Replying to [comment:59 jhovanny]:
 > I apologize. I misunderstood the comment. I'll be testing this patch as
 part of my code, and report any problems that might arise.

 "Needs Tests" refers to written Unit Tests. Please see the
 [http://docs.djangoproject.com/en/dev/internals/contributing Contributing
 to Django] page for more information about Triage, Unit Tests, and other
 useful topics.

-- 
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] #399: Bigint field object needed

[Django]

#399: Bigint field object needed
---+
  Reporter:  jmad...@techie.com| Owner:  permon 
 
Status:  assigned  | Milestone:  1.2
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:|  Keywords:  
sprintsept14, bigint
 Stage:  Design decision needed| Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  1 |  
---+
Comment (by jhovanny):

 I apologize. I misunderstood the comment. I'll be testing this patch as
 part of my code, and report any problems that might arise.

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

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

[Django]

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

Status:  new  | Milestone:  1.2 

 Component:  ORM aggregation  |   Version:  SVN 

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

Needs_docs:  0|   Needs_tests:  0   

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

 * cc: micha...@activestate.com (added)

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

Re: [Django] #7539: Add ON DELETE and ON UPDATE support to Django

[Django]

#7539: Add ON DELETE and ON UPDATE support to Django
---+
  Reporter:  glassfordm| Owner: 
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  feature
 Stage:  Design decision needed| Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by emulbreh):

 Changes between 7539.on_delete.diff and 7539.on_delete.r11706.diff:

  * Added tests.

  * Replaced class based constants with callables that do what
 `_handle_sub_object()` did before. That cleans up `_collect_sub_objects()`
 and allows `on_delete` behaviors to be added without touching any existing
 code (I added `on_delete=SET(value)`, because it's just a four line
 utility function).

  * Merged `CollectedFields` into `CollectedObjects`

  * Made all operations that require knowledge of internals methods on
 `CollectedObjects`. This makes `django.db.models.base.delete_objects` more
 readable.

  * Couldn't resist and rewrote parts of `CollectedObjects`.

-- 
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] #2304: [patch] DISABLE_TRANSACTION_MANAGEMENT is not working as described in Doc's

[Django]

#2304: [patch] DISABLE_TRANSACTION_MANAGEMENT is not working as described in 
Doc's
+---
  Reporter:  scott.benningh...@openmercury.com  | Owner:  
nobody  
Status:  new| Milestone:
  
 Component:  Database layer (models, ORM)   |   Version:
  
Resolution: |  Keywords:  Unit 
of work, commit, rollback, transactions
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  1 
  
Needs_better_patch:  0  |  
+---
Comment (by carljm):

 This patch has been sitting around for quite a while. Meanwhile, the
 [http://docs.djangoproject.com/en/dev/topics/db/transactions/#how-to-
 globally-deactivate-transaction-management documentation still claims
 DISABLE_TRANSACTION_MANAGEMENT works], when in fact it does nothing. If
 this patch isn't ready to go in, would it be worth getting a patch in
 temporarily to remove the 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] #11795: Allow use of inlines for many-to-many fields

[Django]

#11795: Allow use of inlines for many-to-many fields
+---
  Reporter:  sveri  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution: |  Keywords:  manytomanyfield inline
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by miracle2k):

 * cc: miracle2k (added)

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

Re: [Django] #12130: CSRF code requires non-POST-accepting views to be protected

[Django]

#12130: CSRF code requires non-POST-accepting views to be protected
-+--
  Reporter:  carljm  | Owner:  carljm
Status:  new | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by carljm):

  * owner:  nobody => carljm
  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I think the answer here is that get_token needs to be more robust, and
 create a new token if it doesn't find one (rather than relying on the view
 middleware / decorator to create new tokens for it).  If {% csrf_token %}
 is used in template, that means we really honestly do need a token. The
 whole 'NOTPROVIDED' special case simply needs to go away; there are no
 circumstances under which a call to {% csrf_token %} should not return a
 usable token. At least that's my take on it. Patch with tests attached.

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

Re: [Django] #2304: [patch] DISABLE_TRANSACTION_MANAGEMENT is not working as described in Doc's

[Django]

#2304: [patch] DISABLE_TRANSACTION_MANAGEMENT is not working as described in 
Doc's
+---
  Reporter:  scott.benningh...@openmercury.com  | Owner:  
nobody  
Status:  new| Milestone:
  
 Component:  Database layer (models, ORM)   |   Version:
  
Resolution: |  Keywords:  Unit 
of work, commit, rollback, transactions
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  1 
  
Needs_better_patch:  0  |  
+---
Changes (by ben):

  * keywords:  Unit of work, commit, rollback => Unit of work, commit,
   rollback, transactions

-- 
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] #10355: add support for email backends

[Django]

#10355: add support for email backends
---+
  Reporter:  wkornewald| Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  django.core.mail  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by jacob):

 This generally looks great. A couple minor points of criticism:

   * I'd prefer `EMAIL_BACKEND` to always be a full path (e.g.
 `django.core.email.backends.smtp` instead of just `smtp`). I regret the
 decision in other places in Django to treat built-in backends "specially",
 and everyone's gotta look up valid options in the docs anyway. It'd make
 the code (slightly) simpler, too.
   * I'd be nice to add a `backend` argument to `send_mail` and friends.
 That'd make sending mail using different backends nicer.
   * The console backend probably shouldn't hardcode `sys.stdout`; seems it
 should be possible to direct it to a different stream (`sys.stderr`, a
 fake output stream, etc).

 None of these are big problems. The first should be addressed (one way or
 the other) before merging to avoid moving APIs, but the other two could be
 addressed post-merge if needed.

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

Re: [Django] #12095: Login doesn`t work after django update to revision 11664

[Django]

#12095: Login doesn`t work after django update to revision 11664
+---
  Reporter:  venia  | Owner:  nobody  
Status:  closed | Milestone:  
 Component:  Uncategorized  |   Version:  SVN 
Resolution:  fixed  |  Keywords:  csrf, auth, user
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by carljm):

 I've just filed #12130, which I believe describes the continuing problems
 thornomad was experiencing.

-- 
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] #12130: CSRF code requires non-POST-accepting views to be protected

[Django]

#12130: CSRF code requires non-POST-accepting views to be protected
+---
 Reporter:  carljm  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  SVN   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 There's a very confusing failure mode for the new CSRF protection when not
 using the view middleware (i.e. when upgrading a project that didn't use
 CSRF protection before), and using contrib.comments (or any other code
 where a form is posted from one view to a different one).

 The CSRF context processor sets the csrf_token to NOTPROVIDED if the
 _current_ view is not protected by either the view middleware or the
 decorator. But it's quite possible (even likely when using
 contrib.comments) that the form-rendering view is a GET-only view that
 doesn't need to be protected, but its form POSTs to a view that is
 protected (with the decorator).

 To reproduce:

 1. Create a project using Django trunk. Leave CsrfViewMiddleware out of
 MIDDLEWARE_CLASSES.

 2. Add a simple object_detail view that calls contrib.comments' {%
 render_comment_form %} tag.

 3. Load up that view and submit a comment. You'll get the CSRF 403
 Forbidden.

 Somehow a valid CSRF token needs to be made available to templates
 rendered by any view, regardless of whether that view is itself protected
 against CSRF.

-- 
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] #10355: add support for email backends

[Django]

#10355: add support for email backends
---+
  Reporter:  wkornewald| Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  django.core.mail  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  1 => 0
  * milestone:  => 1.2

Comment:

 I've just uploaded my RC1 for this ticket. It's almost exactly the same as
 Andi's most recent patch, with a few minor cleanups here and there, and
 some polishing on the docs. Feedback welcome; I intend to land this in the
 next couple of days.

-- 
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] #11010: Add a foundation for rowlevel permissions in Django

[Django]

#11010: Add a foundation for rowlevel permissions in Django
-+--
  Reporter:  apollo13| Owner:  apollo13
Status:  new | Milestone:  1.2 
 Component:  Authentication  |   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  1   |   Needs_tests:  1   
Needs_better_patch:  1   |  
-+--
Changes (by Michael P. Jung):

 * cc: mpj...@terreon.de (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] #12129: distributions checksums

[Django]

#12129: distributions checksums
-+--
 Reporter:  while0pass   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Django Web site  | Version:
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 It will be a good practice to give links to files with checksums for any
 release download link. They can be found with google
 "site:djangoproject.com cheksums", for instance, for 1.1.1 release the
 link is

 http://media.djangoproject.com/pgp/Django-1.1.1.checksum.txt

 but it will be better to make them verbose at the django web-site.

-- 
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] #12120: documentation: get() does not work with values()

[Django]

#12120: documentation: get() does not work with values()
+---
  Reporter:  adrian_nye | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by apollo13):

 And about your workaround, you wouldn't use filter but this:
 {{{
 .values().get()
 }}}

-- 
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] r11706 - in django/branches/releases/1.1.X/tests/regressiontests: dateformat utils

[noreply]

Author: russellm
Date: 2009-11-02 02:27:00 -0600 (Mon, 02 Nov 2009)
New Revision: 11706

Modified:
   django/branches/releases/1.1.X/tests/regressiontests/dateformat/tests.py
   django/branches/releases/1.1.X/tests/regressiontests/utils/dateformat.py
Log:
[1.1.X] Fixed #12127 -- Corrected teardown of dateformat tests. Thanks to 
apollo13 for the report, and Karen Tracey for the debugging help.

Backport of r11705 from trunk.

Modified: 
django/branches/releases/1.1.X/tests/regressiontests/dateformat/tests.py
===
--- django/branches/releases/1.1.X/tests/regressiontests/dateformat/tests.py
2009-11-02 08:26:03 UTC (rev 11705)
+++ django/branches/releases/1.1.X/tests/regressiontests/dateformat/tests.py
2009-11-02 08:27:00 UTC (rev 11706)
@@ -9,12 +9,24 @@
 os.environ['TZ'] = 'Europe/Copenhagen'
 translation.activate('en-us')
 
+try:
+# Check if a timezone has been set
+time.tzset()
+self.tz_tests = True
+except AttributeError:
+# No timezone available. Don't run the tests that require a TZ
+self.tz_tests = False
+
 def tearDown(self):
 if self.old_TZ is None:
 del os.environ['TZ']
 else:
 os.environ['TZ'] = self.old_TZ
 
+# Cleanup - force re-evaluation of TZ environment variable.
+if self.tz_tests:
+time.tzset()
+
 def test_empty_format(self):
 my_birthday = datetime.datetime(1979, 7, 8, 22, 00)
 
@@ -68,10 +80,7 @@
 summertime = datetime.datetime(2005, 10, 30, 1, 00)
 wintertime = datetime.datetime(2005, 10, 30, 4, 00)
 
-try:
-# Check if a timezone has been set
-time.tzset()
-
+if self.tz_tests:
 self.assertEquals(dateformat.format(my_birthday, 'O'), u'+0100')
 self.assertEquals(dateformat.format(my_birthday, 'r'), u'Sun, 8 
Jul 1979 22:00:00 +0100')
 self.assertEquals(dateformat.format(my_birthday, 'T'), u'CET')
@@ -81,6 +90,3 @@
 self.assertEquals(dateformat.format(summertime, 'O'), u'+0200')
 self.assertEquals(dateformat.format(wintertime, 'I'), u'0')
 self.assertEquals(dateformat.format(wintertime, 'O'), u'+0100')
-except AttributeError:
-# No timezone available. Don't run the tests
-pass

Modified: 
django/branches/releases/1.1.X/tests/regressiontests/utils/dateformat.py
===
--- django/branches/releases/1.1.X/tests/regressiontests/utils/dateformat.py
2009-11-02 08:26:03 UTC (rev 11705)
+++ django/branches/releases/1.1.X/tests/regressiontests/utils/dateformat.py
2009-11-02 08:27:00 UTC (rev 11706)
@@ -5,16 +5,6 @@
 from django.utils.tzinfo import FixedOffset, LocalTimezone
 
 class DateFormatTests(TestCase):
-def setUp(self):
-self.old_TZ = os.environ.get('TZ')
-os.environ['TZ'] = 'Europe/Copenhagen'
-
-def tearDown(self):
-if self.old_TZ is None:
-del os.environ['TZ']
-else:
-os.environ['TZ'] = self.old_TZ
-
 def test_date(self):
 d = date(2009, 5, 16)
 self.assertEquals(date.fromtimestamp(int(format(d, 'U'))), d)


--~--~-~--~~~---~--~~
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] r11705 - in django/trunk/tests/regressiontests: dateformat utils

[noreply]

Author: russellm
Date: 2009-11-02 02:26:03 -0600 (Mon, 02 Nov 2009)
New Revision: 11705

Modified:
   django/trunk/tests/regressiontests/dateformat/tests.py
   django/trunk/tests/regressiontests/utils/dateformat.py
Log:
Fixed #12127 -- Corrected teardown of dateformat tests. Thanks to apollo13 for 
the report, and Karen Tracey for the debugging help.

Modified: django/trunk/tests/regressiontests/dateformat/tests.py
===
--- django/trunk/tests/regressiontests/dateformat/tests.py  2009-11-02 
02:24:01 UTC (rev 11704)
+++ django/trunk/tests/regressiontests/dateformat/tests.py  2009-11-02 
08:26:03 UTC (rev 11705)
@@ -9,12 +9,24 @@
 os.environ['TZ'] = 'Europe/Copenhagen'
 translation.activate('en-us')
 
+try:
+# Check if a timezone has been set
+time.tzset()
+self.tz_tests = True
+except AttributeError:
+# No timezone available. Don't run the tests that require a TZ
+self.tz_tests = False
+
 def tearDown(self):
 if self.old_TZ is None:
 del os.environ['TZ']
 else:
 os.environ['TZ'] = self.old_TZ
 
+# Cleanup - force re-evaluation of TZ environment variable.
+if self.tz_tests:
+time.tzset()
+
 def test_empty_format(self):
 my_birthday = datetime.datetime(1979, 7, 8, 22, 00)
 
@@ -68,10 +80,7 @@
 summertime = datetime.datetime(2005, 10, 30, 1, 00)
 wintertime = datetime.datetime(2005, 10, 30, 4, 00)
 
-try:
-# Check if a timezone has been set
-time.tzset()
-
+if self.tz_tests:
 self.assertEquals(dateformat.format(my_birthday, 'O'), u'+0100')
 self.assertEquals(dateformat.format(my_birthday, 'r'), u'Sun, 8 
Jul 1979 22:00:00 +0100')
 self.assertEquals(dateformat.format(my_birthday, 'T'), u'CET')
@@ -81,6 +90,3 @@
 self.assertEquals(dateformat.format(summertime, 'O'), u'+0200')
 self.assertEquals(dateformat.format(wintertime, 'I'), u'0')
 self.assertEquals(dateformat.format(wintertime, 'O'), u'+0100')
-except AttributeError:
-# No timezone available. Don't run the tests
-pass

Modified: django/trunk/tests/regressiontests/utils/dateformat.py
===
--- django/trunk/tests/regressiontests/utils/dateformat.py  2009-11-02 
02:24:01 UTC (rev 11704)
+++ django/trunk/tests/regressiontests/utils/dateformat.py  2009-11-02 
08:26:03 UTC (rev 11705)
@@ -5,16 +5,6 @@
 from django.utils.tzinfo import FixedOffset, LocalTimezone
 
 class DateFormatTests(TestCase):
-def setUp(self):
-self.old_TZ = os.environ.get('TZ')
-os.environ['TZ'] = 'Europe/Copenhagen'
-
-def tearDown(self):
-if self.old_TZ is None:
-del os.environ['TZ']
-else:
-os.environ['TZ'] = self.old_TZ
-
 def test_date(self):
 d = date(2009, 5, 16)
 self.assertEquals(date.fromtimestamp(int(format(d, 'U'))), d)


--~--~-~--~~~---~--~~
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] #10235: contrib.sitemaps doesn't support RequestSite

[Django]

#10235: contrib.sitemaps doesn't support RequestSite
---+
  Reporter:  arthurk   | Owner:  nobody 
Status:  new   | Milestone: 
 Component:  Contrib apps  |   Version:  1.0
Resolution:|  Keywords:  sitemap
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by miracle2k):

 * cc: miracle2k (added)

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