Re: [Django] #13091: admin list_editable with unique_together raises Integrity Error

[Django]

#13091: admin list_editable with unique_together raises Integrity Error
--+-
   Reporter:  slafs   | Owner:  nobody  

 Status:  new | Milestone:  1.3 

  Component:  django.contrib.admin|   Version:  SVN 

 Resolution:  |  Keywords:  
list_editable unique_together IntegrityError
   Triage Stage:  Design decision needed  | Has patch:  1   

Needs documentation:  0   |   Needs tests:  0   

Patch needs improvement:  0   |  
--+-

Comment (by julien):

 Just a note about the first patch above: the reason why I'm only testing
 the presence of the message "Please correct the errors below." in the
 response is because the actual specific error message currently isn't
 displayed at all. If/when the patch in #13126 gets committed (to allow the
 display of non-field error messages), then the test for this patch can be
 made slightly more robust by asserting the presence of the specific
 unique_together error message.

-- 
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] #15339: Please document the behaviour of RelatedManager when the same object is added twice

[Django]

#15339: Please document the behaviour of RelatedManager when the same object is
added twice
-+--
   Reporter:  jammon | Owner:  nobody  
 Status:  new| Milestone:  
  Component:  Documentation  |   Version:  1.3-beta
 Resolution: |  Keywords:  
   Triage Stage:  Accepted   | Has patch:  0   
Needs documentation:  0  |   Needs tests:  0   
Patch needs improvement:  0  |  
-+--
Changes (by gabrielhurley):

  * needs_docs:  => 0
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * 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] #15337: cyclic import dependency when extend builtin backend

[Django]

#15337: cyclic import dependency when extend builtin backend
---+
   Reporter:  yi.codeplayer@…  | Owner:  nobody  
 Status:  closed   | Milestone:  
  Component:  Cache system |   Version:  1.3-beta
 Resolution:  worksforme   |  Keywords:  
   Triage Stage:  Unreviewed   | Has patch:  1   
Needs documentation:  0|   Needs tests:  0   
Patch needs improvement:  0|  
---+

Comment (by anonymous):

 I was wrong, there's no bug in django ;-)

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

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

[Django] #15339: Please document the behaviour of RelatedManager when the same object is added twice

[Django]

#15339: Please document the behaviour of RelatedManager when the same object is
added twice
---+
 Reporter:  jammon |  Owner:  nobody
   Status:  new|  Milestone:
Component:  Documentation  |Version:  1.3-beta  
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 As I understand the code in `django.db.models.fields.related` the
 `_add_items` method of `ManyRelatedManager` takes care that the same
 object isn't added twice.

 So I suggest to document that in
 `/ref/models/relations/#django.db.models.fields.related.RelatedManager.add`,
 maybe like this: "Adding a model that is already in the related object set
 has no effect, it won't be contained twice afterwards."

 (I looked it up in the code, but just a year ago that would have been
 difficult for me.)

-- 
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] #13091: admin list_editable with unique_together raises Integrity Error

[Django]

#13091: admin list_editable with unique_together raises Integrity Error
--+-
   Reporter:  slafs   | Owner:  nobody  

 Status:  new | Milestone:  1.3 

  Component:  django.contrib.admin|   Version:  SVN 

 Resolution:  |  Keywords:  
list_editable unique_together IntegrityError
   Triage Stage:  Design decision needed  | Has patch:  1   

Needs documentation:  0   |   Needs tests:  0   

Patch needs improvement:  0   |  
--+-

Comment (by russellm):

 #15326 is another report of this problem, slightly closer to the root
 cause.

-- 
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] #15326: ModelForm doesn't do unique checks if any of the fields is exluded

[Django]

#15326: ModelForm doesn't do unique checks if any of the fields is exluded
--+-
   Reporter:  liorsion| Owner:  nobody
 Status:  closed  | Milestone:  1.3   
  Component:  Forms   |   Version:  SVN   
 Resolution:  duplicate   |  Keywords:
   Triage Stage:  Unreviewed  | Has patch:  1 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-
Changes (by russellm):

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


Comment:

 As far as I can make out, this is the same problem -- you may not be
 seeing an IntegrityError, but that's just a missing symptom, not an
 indication that it's a different problem.

 This report seems to be the underlying root cause of the problem described
 by #13091 -- i.e., the fact that uniqueness validation isn't performed
 when you have a form with a subset of the unique_together fields.
 list_editable is just a different way of creating such a form, and #13091
 is seeing integrity errors because the uniqueness condition is causing a
 database level failure, rather than just a failure to enforce a specific
 uniqueness condition.

-- 
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] #11864: Relationship backreference documentation is hard to find

[Django]

#11864: Relationship backreference documentation is hard to find
-+--
   Reporter:  anonymous  | Owner:  dwillis  
  
 Status:  assigned   | Milestone:  1.3  
  
  Component:  Documentation  |   Version:  1.1  
  
 Resolution: |  Keywords:  relationships 
foreigkey
   Triage Stage:  Accepted   | Has patch:  1
  
Needs documentation:  0  |   Needs tests:  0
  
Patch needs improvement:  1  |  
-+--

Comment (by gabrielhurley):

 The solution here is fairly simple, in line with danielr's suggestion.

 The whole ending of the
 [http://docs.djangoproject.com/en/dev/topics/db/models/#many-to-one-
 relationships Many-to-One Relationships] section should be cleaned up as
 follows:

   1. The "see also" section should become the last item in that section.
   2. The text under the "see also" about the model field reference is also
 a "see also" and should be in the "see also" box.
   3. The new information (the subject of this ticket) is *yet another*
 "see also" and should be in that box as well.

 There should be no problem presenting the three distinctly within that
 callout.

 We don't need to provide separate information about backwards
 relationships in this document, only make it easier to arrive at the
 existing information.

-- 
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] #15337: cyclic import dependency when extend builtin backend

[Django]

#15337: cyclic import dependency when extend builtin backend
---+
   Reporter:  yi.codeplayer@…  | Owner:  nobody  
 Status:  closed   | Milestone:  
  Component:  Cache system |   Version:  1.3-beta
 Resolution:  worksforme   |  Keywords:  
   Triage Stage:  Unreviewed   | Has patch:  1   
Needs documentation:  0|   Needs tests:  0   
Patch needs improvement:  0|  
---+
Changes (by russellm):

  * status:  reopened => closed
  * resolution:  => worksforme


Comment:

 And that's exactly what I did. If you want to convince me, you'll need to
 provide a sample project.

-- 
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] #15337: cyclic import dependency when extend builtin backend

[Django]

#15337: cyclic import dependency when extend builtin backend
---+
   Reporter:  yi.codeplayer@…  | Owner:  nobody  
 Status:  reopened | Milestone:  
  Component:  Cache system |   Version:  1.3-beta
 Resolution:   |  Keywords:  
   Triage Stage:  Unreviewed   | Has patch:  1   
Needs documentation:  0|   Needs tests:  0   
Patch needs improvement:  0|  
---+
Changes (by anonymous):

  * status:  closed => reopened
  * resolution:  worksforme =>


Comment:

 You need to config this custom backend to the default cache backend in
 settings.py to reproduce this problem, django.core.cache would import the
 default cache backend.
 sorry for poor english description.

-- 
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] #15338: django.utils.decorators isn't documented

[Django]

#15338: django.utils.decorators isn't documented
-+--
   Reporter:  gabrielhurley  | Owner:  gabrielhurley
 Status:  new| Milestone:   
  Component:  Documentation  |   Version:  SVN  
 Resolution: |  Keywords:   
   Triage Stage:  Accepted   | Has patch:  0
Needs documentation:  0  |   Needs tests:  0
Patch needs improvement:  0  |  
-+--
Changes (by gabrielhurley):

  * version:  1.2 => SVN


Comment:

 Haha, the fact that it's not officially stable by virtue of *omission*
 from that list would be why grepping it didn't help.

 I didn't mean to imply that everything in it should be documented
 publicly, but at least a couple of them (as you say) have become de facto
 public APIs.

 My new favorite toy is the `-n` flag on the sphinx builder which shows
 warnings for every broken crossref... so I see lots of things that aren't
 documented now ;-)

-- 
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] #15337: cyclic import dependency when extend builtin backend

[Django]

#15337: cyclic import dependency when extend builtin backend
---+
   Reporter:  yi.codeplayer@…  | Owner:  nobody  
 Status:  closed   | Milestone:  
  Component:  Cache system |   Version:  1.3-beta
 Resolution:  worksforme   |  Keywords:  
   Triage Stage:  Unreviewed   | Has patch:  1   
Needs documentation:  0|   Needs tests:  0   
Patch needs improvement:  0|  
---+
Changes (by russellm):

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


Old description:

> When writing a custom cache backend which inherit from django's builtin
> memcache backend, say mycache.py:
>

> {{{
> from django.core.cache.backends.memcached import CacheClass as
> BaseCacheClass
> class MyCache(BaseCacheClass):
> 
> }}}
>

> and set backend to "mycache.MyCache" in settings.py, then mycache.py and
> django.core.cache.__init__.py import each other.
> Turn django.core.cache.__init__.py::cache object to be a SimpleLazyObject
> would solve this problem.

New description:

 When writing a custom cache backend which inherit from django's builtin
 memcache backend, say mycache.py:


 {{{
 from django.core.cache.backends.memcached import CacheClass as
 BaseCacheClass
 class MyCache(BaseCacheClass):
 
 }}}


 and set backend to "mycache.MyCache" in settings.py, then mycache.py and
 django.core.cache.!__init!__.py import each other.
 Turn django.core.cache.!__init!__.py::cache object to be a
 SimpleLazyObject would solve this problem.

--

Comment:

 Can't reproduce -- I dropped a custom cache class defined as you describe,
 and don't the problem you describe. Looking at the code, I can't even work
 out what set of conditions would allow this to be reproduced -- I don't
 see any circular dependency. memcached doesn't import anything from the
 django.core.cache.

-- 
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] #15338: django.utils.decorators isn't documented

[Django]

#15338: django.utils.decorators isn't documented
-+--
   Reporter:  gabrielhurley  | Owner:  gabrielhurley
 Status:  new| Milestone:   
  Component:  Documentation  |   Version:  1.2  
 Resolution: |  Keywords:   
   Triage Stage:  Accepted   | Has patch:  0
Needs documentation:  0  |   Needs tests:  0
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

  * stage:  Unreviewed => Accepted


Comment:

 Technically, the reason that it's not documented is because it's
 [http://docs.djangoproject.com/en/1.2/misc/api-stability/#django-utils not
 officially stable API]. However, given that tools like method_decorator
 are pretty much essential now, we should probably formalize the contents
 of utils.decorators.

-- 
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] #15338: django.utils.decorators isn't documented

[Django]

#15338: django.utils.decorators isn't documented
-+--
   Reporter:  gabrielhurley  | Owner:  gabrielhurley
 Status:  new| Milestone:   
  Component:  Documentation  |   Version:  1.2  
   Keywords: |  Triage Stage:  Unreviewed   
  Has patch:  0  |   Needs documentation:  0
Needs tests:  0  |   Patch needs improvement:  0
-+--
 It's certainly not the only thing that's not documented in django.utils,
 but there are a few useful decorators there. In particular,
 `method_decorator` which is discussed in the CBV docs would be good to
 document.

-- 
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] #15327: TEST_USER setting has become mandatory on Oracle

[Django]

#15327: TEST_USER setting has become mandatory on Oracle
+---
   Reporter:  depaolim  | Owner:  
nobody 
 Status:  new   | Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  1.2   
 
 Resolution:|  Keywords:  
TEST_USER Oracle blocker regression
   Triage Stage:  Accepted  | Has patch:  0 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  0 |  
+---
Changes (by russellm):

  * 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] #15325: Please include a reference to the 'Related objects reference' in '/en/1.x/ref/models/fields/#manytomanyfield'

[Django]

#15325: Please include a reference to the 'Related objects reference' in
'/en/1.x/ref/models/fields/#manytomanyfield'
-+--
   Reporter:  jammon | Owner:  nobody
 Status:  new| Milestone:
  Component:  Documentation  |   Version:  1.2   
 Resolution: |  Keywords:
   Triage Stage:  Accepted   | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * needs_tests:  => 0
  * 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] #15324: memcached cache backend creating new connection for every action

[Django]

#15324: memcached cache backend creating new connection for every action
-+--
   Reporter:  dlowe  | Owner:  nobody   
 
 Status:  new| Milestone:  1.3  
 
  Component:  Cache system   |   Version:  1.3-beta 
 
 Resolution: |  Keywords:  blocker 
regression
   Triage Stage:  Ready for checkin  | Has patch:  1
 
Needs documentation:  0  |   Needs tests:  0
 
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

  * keywords:  => blocker regression
  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * needs_tests:  => 0
  * stage:  Unreviewed => Ready for checkin


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

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

Re: [Django] #15327: TEST_USER setting has become mandatory on Oracle

[Django]

#15327: TEST_USER setting has become mandatory on Oracle
+---
   Reporter:  depaolim  | Owner:  
nobody 
 Status:  new   | Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  1.2   
 
 Resolution:|  Keywords:  
TEST_USER Oracle blocker regression
   Triage Stage:  Unreviewed| Has patch:  0 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  0 |  
+---
Changes (by russellm):

  * keywords:  TEST_USER Oracle => TEST_USER Oracle blocker regression
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0


Comment:

 Sounds like an oversight of the database uniqueness check that was added
 recently. That makes this a blocking regression.

-- 
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] #15333: syncdb should use commit_on_success

[Django]

#15333: syncdb should use commit_on_success
---+
   Reporter:  corbellini.andrea@…  | Owner:  nobody
 Status:  closed   | Milestone:
  Component:  Uncategorized|   Version:  1.2   
 Resolution:  wontfix  |  Keywords:
   Triage Stage:  Unreviewed   | Has patch:  0 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+
Changes (by russellm):

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


Comment:

 I'm not convinced that this is worth the effort. For starters, it wouldn't
 be completely reliable -- MySQL, for example, has an implicit internal
 transaction for DDL statements. In addition, Initial data insertion is
 already handled as a single transaction, which is the only really 'risky'
 part of a sycndb.

 I'm willing to be convinced otherwise, but you'll need to provide
 convincing hard data to demonstrate the advantage.

-- 
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] #15337: cyclic import dependency when extend builtin backend

[Django]

#15337: cyclic import dependency when extend builtin backend
-+--
 Reporter:  yi.codeplayer@…  |  Owner:  nobody
   Status:  new  |  Milestone:
Component:  Cache system |Version:  1.3-beta  
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  1|  
-+--
 When writing a custom cache backend which inherit from django's builtin
 memcache backend, say mycache.py:


 {{{
 from django.core.cache.backends.memcached import CacheClass as
 BaseCacheClass
 class MyCache(BaseCacheClass):
 
 }}}


 and set backend to "mycache.MyCache" in settings.py, then mycache.py and
 django.core.cache.__init__.py import each other.
 Turn django.core.cache.__init__.py::cache object to be a SimpleLazyObject
 would solve this problem.

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

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

Re: [Django] #15332: Model Field "default" attribute: clarify relationship with blank and null attributes

[Django]

#15332: Model Field "default" attribute: clarify relationship with blank and 
null
attributes
-+--
   Reporter:  ijstokes   | Owner:  nobody
 Status:  closed | Milestone:
  Component:  Documentation  |   Version:  SVN   
 Resolution:  wontfix|  Keywords:
   Triage Stage:  Unreviewed | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

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


Comment:

 Erm... the default is the value that is used for a field when a value
 hasn't been provided. That's what "default" means. The interaction with
 blank, null, unique and choices is exactly the same as it would be if you
 had a user-provided value.

 Closing wontfix, because I can't see what is unclear in all this, without
 getting into dictionary level definitions of terms. Feel free to reopen if
 you can clarify exactly what you see as unclear.

-- 
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] #15330: Django 1.2.3 (and 1.2.1) release note are missing

[Django]

#15330: Django 1.2.3 (and 1.2.1) release note are missing
-+--
   Reporter:  Jorge Vargas   | 
Owner:  nobody
 Status:  closed | 
Milestone:
  Component:  Django Web site|   
Version:  1.2   
 Resolution:  wontfix|  
Keywords:
   Triage Stage:  Unreviewed | Has 
patch:  0 
Needs documentation:  0  |   Needs 
tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

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


Comment:

 We only do release notes for point releases when there is some notable
 change -- either a new feature (not normally allowed, but sometimes
 necessary in order to fix a bug), or if there is a backwards compatibility
 or security issue.

 In the case of 1.2.1 and 1.2.3, the release notes would say nothing more
 than "Hi, these are the release notes", so we don't add them.

-- 
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] #15336: Spurious DeprecationWarning when no database settings present

[Django]

#15336: Spurious DeprecationWarning when no database settings present
-+--
   Reporter:  isagalaev  | Owner:  isagalaev
 Status:  new| Milestone:   
  Component:  Core framework |   Version:  1.2  
 Resolution: |  Keywords:   
   Triage Stage:  Ready for checkin  | Has patch:  1
Needs documentation:  0  |   Needs tests:  0
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

  * component:  Uncategorized => Core framework
  * stage:  Unreviewed => Ready for checkin


Comment:

 This is inherently difficult to test, so I'm happy to accept this RFC
 based on inspection and manual testing.

-- 
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] #15328: Class-based Views (CBV) documentation mistake on method_decorator approach for @login_required

[Django]

#15328: Class-based Views (CBV) documentation mistake on method_decorator 
approach
for @login_required
-+--
   Reporter:  airstrike  | Owner:  gabrielhurley

  
 Status:  assigned   | Milestone:  1.3  

  
  Component:  Documentation  |   Version:  1.3-beta 

  
 Resolution: |  Keywords:  CBV, class-based 
views, method_decorator, login_required, decorators, documentation, docs, 
mixin, login
   Triage Stage:  Accepted   | Has patch:  0

  
Needs documentation:  0  |   Needs tests:  0

  
Patch needs improvement:  0  |  
-+--
Changes (by gabrielhurley):

  * status:  new => assigned
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * owner:  nobody => gabrielhurley
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted


Comment:

 Yep, taking `*args` as a parameter is gonna be necessary with the way
 `method_decorator` works...

 As for `LoginMixin`, I think it should be treated as a separate issue and
 ought to have it's own ticket. I have no strong feelings on it,
 personally. It's a useful recipe, but it strikes me that if it's useful
 enough to be formally written out in the docs it might as well be included
 as a mixin OTB. Either way I'm going to treat it as an extraneous issue
 and not part of the resolution for the actual error in the docs.

-- 
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] #12950: urlresolvers.reverse returns '/$' when including namespaced '^$' pattern at root '^$'

[Django]

#12950: urlresolvers.reverse returns '/$' when including namespaced '^$' 
pattern at
root '^$'
--+-
   Reporter:  ungenio | Owner:  nobody  
  
 Status:  reopened| Milestone:  
  
  Component:  Core framework  |   Version:  SVN 
  
 Resolution:  |  Keywords:  urlresolvers 
reverse namespace
   Triage Stage:  Accepted| Has patch:  1   
  
Needs documentation:  0   |   Needs tests:  0   
  
Patch needs improvement:  0   |  
--+-
Changes (by ungenio):

  * needs_better_patch:  1 => 0


Comment:

 New patch passes tests.

 What patch does is copy namespaced resolver into non-namespace resolver,
 then wraps with root resolver so that everything works.

-- 
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] #15334: Documentation on namespaced URL reversing has an error

[Django]

#15334: Documentation on namespaced URL reversing has an error
-+--
   Reporter:  RaceCondition  | Owner:  nobody
 Status:  closed | Milestone:  1.3   
  Component:  Documentation  |   Version:  SVN   
 Resolution:  wontfix|  Keywords:
   Triage Stage:  Unreviewed | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by gabrielhurley):

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


Comment:

 To my reading the current docs are correct.

 If, as you suggested, the first instance of "last registered instance"
 were changed to "default instance" the paragraph would contradict itself,
 saying that it will resolve to the default instance when there is no
 default instance.

 The only way I could see improving that snippet would be to change the
 period before "since" to a semicolon or an em dash so that the two
 sentences are more clearly logically connected.

 If the word "since" were an "if", what you say would be true.

 If I am misunderstanding or misreading, please reopen the ticket with
 further explanation.

-- 
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] #12950: urlresolvers.reverse returns '/$' when including namespaced '^$' pattern at root '^$'

[Django]

#12950: urlresolvers.reverse returns '/$' when including namespaced '^$' 
pattern at
root '^$'
--+-
   Reporter:  ungenio | Owner:  nobody  
  
 Status:  reopened| Milestone:  
  
  Component:  Core framework  |   Version:  SVN 
  
 Resolution:  |  Keywords:  urlresolvers 
reverse namespace
   Triage Stage:  Accepted| Has patch:  1   
  
Needs documentation:  0   |   Needs tests:  0   
  
Patch needs improvement:  1   |  
--+-
Changes (by ungenio):

  * needs_tests:  1 => 0


Comment:

 Added a simple regression test. Will see if I can figure out how to
 resolve.

-- 
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] #15336: Spurious DeprecationWarning when no database settings present

[Django]

#15336: Spurious DeprecationWarning when no database settings present
-+--
   Reporter:  isagalaev  | Owner:  isagalaev
 Status:  new| Milestone:   
  Component:  Uncategorized  |   Version:  1.2  
 Resolution: |  Keywords:   
   Triage Stage:  Unreviewed | Has patch:  1
Needs documentation:  0  |   Needs tests:  0
Patch needs improvement:  0  |  
-+--
Changes (by isagalaev):

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


Comment:

 I'm not really sure how to write a test for this because tests require
 database settings. However the fix seems to be pretty trivial and may be
 we could leave out tests in this case.

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

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

[Django] #15336: Spurious DeprecationWarning when no database settings present

[Django]

#15336: Spurious DeprecationWarning when no database settings present
---+
 Reporter:  isagalaev  |  Owner:  isagalaev 
   Status:  new|  Milestone:
Component:  Uncategorized  |Version:  1.2   
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 If a db-less project doesn't set up database settings management commands
 produce a spurious DeprecationWarning:

 {{{
 django/db/__init__.py:18: DeprecationWarning: settings.DATABASE_* is
 deprecated; use settings.DATABASES instead.
   DeprecationWarning
 }}}

 This breaks running cron scripts due to cron considering any output from a
 program as a reason to yell into your email about something possibly
 broken.

 The warning is raised on a single condition of empty settings.DATABASES.
 This is easily fixed by also checking if a deprecated
 settings.DATABASE_ENGINE is set. A patch is following.

-- 
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] #15335: No crossref targets for sites and flatpages classes

[Django]

#15335: No crossref targets for sites and flatpages classes
-+--
   Reporter:  gabrielhurley  | Owner:  gabrielhurley
 Status:  new| Milestone:   
  Component:  Documentation  |   Version:  1.2  
   Keywords: |  Triage Stage:  Unreviewed   
  Has patch:  0  |   Needs documentation:  0
Needs tests:  0  |   Patch needs improvement:  0
-+--
 There are several classes (`RequestSite`, `FlatPagesFallbackMiddleware`,
 etc.) which do not have formal Sphinx crossref targets (not defined with
 the `.. class` directive). There are several more in the sites and
 flatpages ref docs which have broken crossref targets due to bad indenting
 and/or module directives. General cleanup is needed.

 (p.s. -- for future reference, using the `-n` flag when building the docs
 with Sphinx will yield warnings for any and all broken references. Very
 handy, if a bit intimidating.)

-- 
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] #15334: Documentation on namespaced URL reversing has an error

[Django]

#15334: Documentation on namespaced URL reversing has an error
---+
 Reporter:  RaceCondition  |  Owner:  nobody
   Status:  new|  Milestone:  1.3   
Component:  Documentation  |Version:  SVN   
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 "If there is no current instance - say, if we were rendering a page
 somewhere else on the site - myapp:index will resolve to the LAST
 REGISTERED instance of myapp. Since there is NO DEFAULT INSTANCE, the LAST
 INSTANCE of myapp that is registered will be used."

 I assume the first "last registered" should instead be "default".

-- 
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] #12028: Generic Inline doesn't validate unique_together

[Django]

#12028: Generic Inline doesn't validate unique_together
--+-
   Reporter:  diverman| Owner:  

 Status:  new | Milestone:  1.3 

  Component:  Contrib apps|   Version:  1.2 

 Resolution:  |  Keywords:  content 
type generic inline unique validation formset admin modeladmin model
   Triage Stage:  Design decision needed  | Has patch:  0   

Needs documentation:  0   |   Needs tests:  0   

Patch needs improvement:  0   |  
--+-
Changes (by jnns):

 * cc: jvajen@… (added)
  * stage:  Accepted => Design decision needed


Comment:

 The reason for this exception being raised is that both fields
 `content_type` and `object_id` are being excluded from the inline formset
 as a default. `_get_unique_checks()` omits the excluded fields from
 checking for unique constraints and therefore no ValidationError is raised
 during form validation.

 I don't know whether a patch is needed or if the form validation should be
 done manually in this case.

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

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

Re: [Django] #9007: Restore model examples in the new docs system

[Django]

#9007: Restore model examples in the new docs system
-+--
   Reporter:  julien | Owner:  nobody
 Status:  closed | Milestone:
  Component:  Documentation  |   Version:  1.0   
 Resolution:  fixed  |  Keywords:
   Triage Stage:  Accepted   | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by gabrielhurley):

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


Comment:

 The "official repository of model examples" works correctly (pointing to
 the `tests/modeltests` directory in the repo). Closing as fixed until
 someone confirms there's something still amiss here.

-- 
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] #9535: File uploads documentation is patchy

[Django]

#9535: File uploads documentation is patchy
-+--
   Reporter:  Daniel Pope | 
Owner:  jacob
 Status:  assigned   | 
Milestone:   
  Component:  Documentation  |   
Version:  1.0  
 Resolution: |  
Keywords:   
   Triage Stage:  Accepted   | Has 
patch:  0
Needs documentation:  0  |   Needs 
tests:  0
Patch needs improvement:  0  |  
-+--

Comment (by gabrielhurley):

 I find myself dealing with the docs related to Django's file handling APIs
 a lot lately for one reason or another. It seems to be a corner of the
 docs that have languished for some time. As such, I'm in complete
 agreement that this can be improved substantially.

 Organizationally, A lot of what's in `topics/http/file-uploads` belongs in
 a reference document. It's a pet peeve of mine when the only reference for
 entire classes winds up in a topic or how-to guide. `FileUploadHandler`
 and `UploadedFile` ought to be spec'd out somewhere else.

 With those bits moved out of the way, the topic guide can then focus on
 the nitty gritty of how to actually accomplish things using those APIs
 rather than just showing them to you.

 All of the bits mentioned in the ticket description and in the comments
 would make worthy additions to the document. I'm happy to review patches
 if anyone wants to take a stab at 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] #1873: [patch] multi-select admin filter for RelatedFields

[Django]

#1873: [patch] multi-select admin filter for RelatedFields
+---
   Reporter:  marc@…| Owner:  nobody
 Status:  new   | Milestone:
  Component:  django.contrib.admin  |   Version:
 Resolution:|  Keywords:  nfa-changelist
   Triage Stage:  Someday/Maybe | Has patch:  1 
Needs documentation:  1 |   Needs tests:  0 
Patch needs improvement:  1 |  
+---
Changes (by russellm):

  * owner:  russellm => nobody


Comment:

 Don't assign tickets to other people. If you want someone to take a look
 at it, raise the issue on Django-dev, and see who takes the bait.

-- 
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] #14013: 'django.db.backends.postgresql_psycopg2' isn't an available database backend. (?!?!?)

[Django]

#14013: 'django.db.backends.postgresql_psycopg2' isn't an available database
backend. (?!?!?)
+---
   Reporter:  kessler.bm@…  | Owner:  nobody
 Status:  closed| Milestone:
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 Resolution:  invalid   |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by grahamd):

 For reference as to likely cause of this problem, see:

 http://psycopg.lighthouseapp.com/projects/62710/tickets/20

 Although the description of psyocpg2 issue tracker suggests it should also
 occur for Python 2.6, so may not be exact same issue or users environment
 is somehow different.

 The psycopg2 people are trialling a fix for this issue at this time. See:

 https://groups.google.com/d/topic/modwsgi/_xU1U9Hrr_I/discussion

-- 
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] #14013: 'django.db.backends.postgresql_psycopg2' isn't an available database backend. (?!?!?)

[Django]

#14013: 'django.db.backends.postgresql_psycopg2' isn't an available database
backend. (?!?!?)
+---
   Reporter:  kessler.bm@…  | Owner:  nobody
 Status:  closed| Milestone:
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 Resolution:  invalid   |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by oban):

 I now have django working on Windows 7...
 psycopg2 2.0.14 apache 2.2.17 python 2.6.6 mod_wsgi-win32-ap22py26-3.3.so
 postgresql 9.0.3-1 django-1.2.5
 I don't want to admit to how long this has taken me...  started off days
 ago trying to get everything working 64 bit!

-- 
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] #15233: Docs misidentify modules for classes/functions

[Django]

#15233: Docs misidentify modules for classes/functions
-+--
   Reporter:  Aryeh Leib Taurog   | 
Owner:  gabrielhurley  
 Status:  new| 
Milestone: 
  Component:  Documentation  |   
Version:  SVN
 Resolution: |  
Keywords:  module directives index
   Triage Stage:  Accepted   | Has 
patch:  1  
Needs documentation:  0  |   Needs 
tests:  0  
Patch needs improvement:  0  |  
-+--
Changes (by gabrielhurley):

  * owner:  nobody => gabrielhurley
  * status:  reopened => new


Comment:

 Darn, that's what I get for not keeping my copy of Sphinx up-to-date. That
 error wasn't reported in previous versions, but now that I've got 1.0.7
 I'm seeing it. I'll fix that momentarily.

-- 
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] #15331: xgettext skips some translation strings in javascript files when using the "condition ? true_result : false_result" pattern

[Django]

#15331: xgettext skips some translation strings in javascript files when using 
the
"condition ? true_result : false_result" pattern
+---
   Reporter:  aarranz@… | Owner:  nobody
 Status:  closed| Milestone:
  Component:  Internationalization  |   Version:  1.2   
 Resolution:  duplicate |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by ramiro):

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


Comment:

 Duplicate of #14045.

-- 
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] #12534: django.contrib.auth.views.login refuses to redirect to urls with spaces

[Django]

#12534: django.contrib.auth.views.login refuses to redirect to urls with spaces
--+-
   Reporter:  sharky  | Owner:  nobody
 Status:  reopened| Milestone:  1.3   
  Component:  Authentication  |   Version:  1.1   
 Resolution:  |  Keywords:
   Triage Stage:  Accepted| Has patch:  1 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-
Changes (by jnns):

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

[Django] #15333: syncdb should use commit_on_success

[Django]

#15333: syncdb should use commit_on_success
-+--
 Reporter:  corbellini.andrea@…  |  Owner:  nobody
   Status:  new  |  Milestone:
Component:  Uncategorized|Version:  1.2   
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  
-+--
 The "syncdb" command of the manager should use commit_on_success(). This
 will make the script faster and also a bit safer.

-- 
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] #15233: Docs misidentify modules for classes/functions

[Django]

#15233: Docs misidentify modules for classes/functions
-+--
   Reporter:  Aryeh Leib Taurog   | 
Owner:  nobody 
 Status:  reopened   | 
Milestone: 
  Component:  Documentation  |   
Version:  SVN
 Resolution: |  
Keywords:  module directives index
   Triage Stage:  Accepted   | Has 
patch:  1  
Needs documentation:  0  |   Needs 
tests:  0  
Patch needs improvement:  0  |  
-+--
Changes (by Aryeh Leib Taurog ):

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


Comment:

 Hm.  Now I get the following error when I build the documents:

 /home/altaurog/djangodoc/trunk/docs/topics/http/urls.txt:3: (SEVERE/4)
 Duplicate ID: "module-django.core.urlresolvers".

 I don't know why I didn't see this earlier.  I did compile the docs before
 submitting the patch.  Perhaps it was a different version of sphinx which
 is less picky.  Anyway, I think changing the second `module` directive to
 `currentmodule` would solve this problem.

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

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

Re: [Django] #13260: urlresolvers.reverse() generates invalid URLs when an argument contains % character

[Django]

#13260: urlresolvers.reverse() generates invalid URLs when an argument contains 
%
character
--+-
   Reporter:  semenov | Owner:  stumbles
 Status:  assigned| Milestone:  
  Component:  Core framework  |   Version:  SVN 
 Resolution:  |  Keywords:  
   Triage Stage:  Design decision needed  | Has patch:  1   
Needs documentation:  0   |   Needs tests:  0   
Patch needs improvement:  0   |  
--+-
Changes (by erikrose):

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

[Django]

#6148: Add generic support for database schemas
+---
   Reporter:  ikelly| Owner:
 
 Status:  new   | Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 
 Resolution:|  Keywords:  
oracle postgresql mysql schemas
   Triage Stage:  Accepted  | Has patch:  1 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  1 |  
+---
Changes (by mgventura):

 * cc: mgventura (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] #2723: yes/no option for BooleanField

[Django]

#2723: yes/no option for BooleanField
---+
   Reporter:  Gary Wilson   | Owner: 
 shanx   
 Status:  closed   | Milestone: 
 
  Component:  django.contrib.admin |   Version: 
 SVN 
 Resolution:  invalid  |  Keywords: 
 nfa-someday, sprintdec01, sprint-pycon08
   Triage Stage:  Accepted | Has patch: 
 1   
Needs documentation:  0|   Needs tests: 
 0   
Patch needs improvement:  1|  
---+
Changes (by Leo):

  * status:  assigned => closed
  * resolution:  => invalid


Comment:

 @beer was close, and @tobias is correct, you can't just use `bool`. Try
 this instead:

 {{{
 TypedChoiceField(coerce=lambda x: x =='True', choices=((False, 'No'),
 (True, 'Yes')), widget=forms.RadioSelect)
 }}}

 Considering that this is a three year old ticket with a totally out of
 date patch and there's a one line solution for what it's trying to
 achieve, I think it's prudent to close this ticket.

-- 
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] #1873: [patch] multi-select admin filter for RelatedFields

[Django]

#1873: [patch] multi-select admin filter for RelatedFields
+---
   Reporter:  marc@…| Owner:  russellm  
 Status:  new   | Milestone:
  Component:  django.contrib.admin  |   Version:
 Resolution:|  Keywords:  nfa-changelist
   Triage Stage:  Someday/Maybe | Has patch:  1 
Needs documentation:  1 |   Needs tests:  0 
Patch needs improvement:  1 |  
+---
Changes (by lbruno):

  * owner:  nobody => russellm


Comment:

 Sorry for putting this on your plate, but I think this ticket has slipped
 through the gaps; mind keeping an eye on it, or putting the ticket on the
 right guy's plate?

-- 
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] #15332: Model Field "default" attribute: clarify relationship with blank and null attributes

[Django]

#15332: Model Field "default" attribute: clarify relationship with blank and 
null
attributes
---+
 Reporter:  ijstokes   |  Owner:  nobody
   Status:  new|  Milestone:
Component:  Documentation  |Version:  SVN   
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 The documentation needs a short note stating under what conditions the
 specified "default" value is applied to a ModelField.  My best guess would
 be if the field is blank *or* null then the default will be applied and
 stored in the DB.  Also, knowing how this default value relates to
 "unique" and any "choices" list would be nice.

 Ian

-- 
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] #15326: ModelForm doesn't do unique checks if any of the fields is exluded

[Django]

#15326: ModelForm doesn't do unique checks if any of the fields is exluded
--+-
   Reporter:  liorsion| Owner:  nobody
 Status:  reopened| Milestone:  1.3   
  Component:  Forms   |   Version:  SVN   
 Resolution:  |  Keywords:
   Triage Stage:  Unreviewed  | Has patch:  1 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-
Changes (by liorsion):

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


Comment:

 thanks for the formatting fix.

 This is not a duplicate - ticket:13091 throws ntegrity Error, while this
 error just doesn't do the uniqueness test. The line that I showed is where
 the magic happens.

 The issue is an issue of definition: if a field is excluded from a form,
 is the form still responsible to test other fields that related to that
 excluded field? I think it does.

-- 
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] #15331: xgettext skips some translation strings in javascript files when using the "condition ? true_result : false_result" pattern (was: xgettext skips some translation strings in javasc

[Django]

#15331: xgettext skips some translation strings in javascript files when using 
the
"condition ? true_result : false_result" pattern
+---
   Reporter:  aarranz@… | Owner:  nobody
 Status:  new   | Milestone:
  Component:  Internationalization  |   Version:  1.2   
 Resolution:|  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by anonymous):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * needs_tests:  => 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.

[Django] #15331: xgettext skips some translation strings in javascript files

[Django]

#15331: xgettext skips some translation strings in javascript files
--+-
 Reporter:  aarranz@… |  Owner:  nobody
   Status:  new   |  Milestone:
Component:  Internationalization  |Version:  1.2   
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  
--+-
 Javascript example code:
 {{{
 gettext("foo");

 true ? true : false;

 gettext("bar");

 true ? true : false;

 gettext("baz");

 true ? true : false; // ?

 gettext("quz");

 "?";

 gettext("foobar");

 }}}

 "bar" is ignored when running "manage.py makemessages". Apparently this is
 related to the presence of "?" commonly used in the "condition ?
 true_result : false_result" pattern.

 This bug is similar to #4695

-- 
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] #13091: admin list_editable with unique_together raises Integrity Error

[Django]

#13091: admin list_editable with unique_together raises Integrity Error
--+-
   Reporter:  slafs   | Owner:  nobody  

 Status:  new | Milestone:  1.3 

  Component:  django.contrib.admin|   Version:  SVN 

 Resolution:  |  Keywords:  
list_editable unique_together IntegrityError
   Triage Stage:  Design decision needed  | Has patch:  1   

Needs documentation:  0   |   Needs tests:  0   

Patch needs improvement:  0   |  
--+-

Comment (by ramiro):

 See #12521, #12901 and related commits.

-- 
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] #15330: Django 1.2.3 (and 1.2.1) release note are missing

[Django]

#15330: Django 1.2.3 (and 1.2.1) release note are missing
---+
 Reporter:  Jorge Vargas   |  Owner:  nobody
   Status:  new|  Milestone:
Component:  Django Web site|Version:  1.2   
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 The URL
 http://docs.djangoproject.com/en/dev/releases/1.2.3/
 Should contain them.

 and should be linked from http://docs.djangoproject.com/en/dev/releases/

-- 
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] #15319: _get_next_or_previous_by_FIELD populated from Meta

[Django]

#15319: _get_next_or_previous_by_FIELD populated from Meta
+---
   Reporter:  alexr | Owner:  nobody
 Status:  new   | Milestone:
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 Resolution:|  Keywords:
   Triage Stage:  Design decision needed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by alexr):

 
http://code.djangoproject.com/browser/django/trunk/django/db/models/base.py#L589

 I think the idea is to fall back to ordering by pk so that nothing is
 missed if the seekable field has duplicate values.

 If we ordered by FOO, which was also the pk field, we'd end up with a
 query like this (for get_next):

 {{{#!python
 MyObj.objects.filter(Q(FOO__gt=self.FOO)|Q(FOO__gt=self.FOO)).order_by('FOO',
 'FOO')
 }}}

 Looking at it, I guess that query would run ok, it just looks weird.

-- 
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] #15329: get_template_names() should use getattr() on object

[Django]

#15329: get_template_names() should use getattr() on object
-+--
   Reporter:  tribaal@…  | Owner:  nobody  
 Status:  closed | Milestone:  1.3 
  Component:  Generic views  |   Version:  1.3-beta
 Resolution:  invalid|  Keywords:  
   Triage Stage:  Unreviewed | Has patch:  1   
Needs documentation:  0  |   Needs tests:  0   
Patch needs improvement:  0  |  
-+--
Changes (by lrekucki):

  * status:  new => closed
  * keywords:  blocker =>
  * resolution:  => invalid


Comment:

 I disagree. This is [http://docs.djangoproject.com/en/dev/ref/class-based-
 views/#django.views.generic.detail.SingleObjectTemplateResponseMixin
 documented]:

 > class SingleObjectTemplateResponseMixin
 > A mixin class that performs template-based response rendering for
 views that operate upon a single object instance. **Requires that the view
 it is mixed with provides self.object**, the object instance that the view
 is operating on. self.object will usually be, but is not required to be,
 an instance of a Django model. It may be None if the view is in the
 process of constructing a new instance.

 You didn't provide any details on how/what you're overriding/subclassing
 the UpdateView that includes this mixin, so it's hard to judge if it's a
 user error or a limitation of the API. Please reopen with more details
 about your use case.

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

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

Re: [Django] #15329: get_template_names() should use getattr() on object

[Django]

#15329: get_template_names() should use getattr() on object
-+--
   Reporter:  tribaal@…  | Owner:  nobody  
 Status:  new| Milestone:  1.3 
  Component:  Generic views  |   Version:  1.3-beta
 Resolution: |  Keywords:  blocker 
   Triage Stage:  Unreviewed | Has patch:  1   
Needs documentation:  0  |   Needs tests:  0   
Patch needs improvement:  0  |  
-+--
Changes (by rasca):

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


Comment:

 Tagging it as a blocker so it get's to trunk before RC1 (if 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] #15326: ModelForm doesn't do unique checks if any of the fields is exluded

[Django]

#15326: ModelForm doesn't do unique checks if any of the fields is exluded
--+-
   Reporter:  liorsion| Owner:  nobody
 Status:  closed  | Milestone:  1.3   
  Component:  Forms   |   Version:  SVN   
 Resolution:  duplicate   |  Keywords:
   Triage Stage:  Unreviewed  | Has patch:  1 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-
Changes (by kmtracey):

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


Old description:

> If a model exists with unique_together fields, and a form doesn't display
> all the fields in the unique_together (at least one of them is excluded)
> the entire condition is ignored in the code. This is the wrong behavior,
> only if ALL the fields are excluded then the test should be ignore.
>
> Use case:
>
> House (class H) has Windows (class W) with different colors. A house has
> different colors for different windows, and a person can change the
> qualities of the window as long as they don't change the color to an
> existing one:
>
> So:
>
> class H(models.Model):
> 
>
> Class W(models.Model):
> color:Models.IntegerField()
> house:Models.ForeignKey(H)
> . # other qualities of the window
>
> class Meta:
> unique_together = (("color", "house"),)
>
> And the form:
>
> class ChangeWindowForm(ModelForm):
> class Meta:
> model = W
> fields = ('color',  # other qualities)
>
> in this scenario, a form validation would pass if a H,C with the same
> values exist.
>
> The line that is the problem is in django.db.models.base.py, in def
> _get_unique_checks(self, exclude=None):
>
> if name in exclude:
> break
>
> a possible change:
> if any(check[i:i + len(exclude)] == exclude for i in range(len(check) -
> len(exclude) + 1)):
> break

New description:

 If a model exists with unique_together fields, and a form doesn't display
 all the fields in the unique_together (at least one of them is excluded)
 the entire condition is ignored in the code. This is the wrong behavior,
 only if ALL the fields are excluded then the test should be ignore.

 Use case:

 House (class H) has Windows (class W) with different colors. A house has
 different colors for different windows, and a person can change the
 qualities of the window as long as they don't change the color to an
 existing one:

 So:
 {{{
 class H(models.Model):
 

 Class W(models.Model):
 color:Models.IntegerField()
 house:Models.ForeignKey(H)
 . # other qualities of the window

 class Meta:
 unique_together = (("color", "house"),)
 }}}
 And the form:
 {{{
 class ChangeWindowForm(ModelForm):
 class Meta:
 model = W
 fields = ('color',  # other qualities)
 }}}
 in this scenario, a form validation would pass if a H,C with the same
 values exist.

 The line that is the problem is in django.db.models.base.py, in def
 _get_unique_checks(self, exclude=None):
 {{{
 if name in exclude:
 break
 }}}
 a possible change:
 {{{
 if any(check[i:i + len(exclude)] == exclude for i in range(len(check) -
 len(exclude) + 1)):
 break
 }}}

--

Comment:

 Fixed formatting. Please use WikiFormatting and preview before posting.

 This is the same problem as #13091, I believe, so closing as a dup of that
 one.

-- 
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] #15326: ModelForm doesn't do unique checks if any of the fields is exluded

[Django]

#15326: ModelForm doesn't do unique checks if any of the fields is exluded
--+-
   Reporter:  liorsion| Owner:  nobody
 Status:  new | Milestone:  1.3   
  Component:  Forms   |   Version:  SVN   
 Resolution:  |  Keywords:
   Triage Stage:  Unreviewed  | Has patch:  1 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-
Changes (by liorsion):

 * cc: liorsion (added)
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 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.

[Django] #15329: get_template_names() should use getattr() on object

[Django]

#15329: get_template_names() should use getattr() on object
---+
 Reporter:  tribaal@…  |  Owner:  nobody
   Status:  new|  Milestone:  1.3   
Component:  Generic views  |Version:  1.3-beta  
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  
---+
 I discovered by writing unit tests for a subclass of DetailView that the
 get_template_names() method of SingleObjectTemplateResponseMixin
 (django.views.generic.detail) does not use getattr to access the object
 attribute.

 In the context of writing tests for a subclass overriding (and/or
 extending) the behavior of get_template_names, "object" may not be
 present.

 The following patch solves the problem permanently:

 {{{
 --- a/django/views/generic/detail.py
 +++ b/django/views/generic/detail.py
 @@ -119,14 +119,15 @@ class
 SingleObjectTemplateResponseMixin(TemplateResponseMixin):
  # If self.template_name_field is set, grab the value of the field
  # of that name from the object; this is the most specific
 template
  # name, if given.
 -if self.object and self.template_name_field:
 +if (getattr(self, 'object', None) and
 +getattr(self, 'template_name_field', None)):
  name = getattr(self.object, self.template_name_field, None)
  if name:
  names.insert(0, name)

  # The least-specific option is the default
 /_detail.html;
  # only use this if the object in question is a model.
 -if hasattr(self.object, '_meta'):
 +if hasattr(self, 'object') and hasattr(self.object, '_meta'):
  names.append("%s/%s%s.html" % (
  self.object._meta.app_label,
  self.object._meta.object_name.lower(),
 }}}

-- 
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] #3615: Can't define forward references in fixtures using MySQL with InnoDB

[Django]

#3615: Can't define forward references in fixtures using MySQL with InnoDB
+---
   Reporter:  russellm  | Owner:  
nobody   
 Status:  new   | Milestone:
   
  Component:  Database layer (models, ORM)  |   Version:  SVN   
   
 Resolution:|  Keywords:  mysql 
innodb myisam reference fixture
   Triage Stage:  Accepted  | Has patch:  0 
   
Needs documentation:  0 |   Needs tests:  0 
   
Patch needs improvement:  0 |  
+---
Changes (by eduardocereto):

 * cc: eduardocereto@… (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] #15274: UpdateView raises exception about overiding get_object

[Django]

#15274: UpdateView raises exception about overiding get_object
--+-
   Reporter:  sergeybe@…  | Owner:  nobody  
 Status:  closed  | Milestone:  1.3 
  Component:  Generic views   |   Version:  1.3-beta
 Resolution:  fixed   |  Keywords:  blocker 
   Triage Stage:  Accepted| Has patch:  0   
Needs documentation:  0   |   Needs tests:  0   
Patch needs improvement:  0   |  
--+-

Comment (by Sergey N. Belinsky ):

 It works now. Thank you!

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

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

[Django] #15328: Class-based Views (CBV) documentation mistake on method_decorator approach for @login_required

[Django]

#15328: Class-based Views (CBV) documentation mistake on method_decorator 
approach
for @login_required
-+
 Reporter:  airstrike   
 |  Owner:  nobody
   Status:  new 
 |  Milestone:  1.3   
Component:  Documentation   
 |Version:  1.3-beta  
 Keywords:  CBV, class-based views, method_decorator, login_required, 
decorators, documentation, docs, mixin, login  |   Triage Stage:  Unreviewed
Has patch:  0   
 |  
-+
 http://docs.djangoproject.com/en/dev//topics/class-based-views
 /#decorating-the-class

 The code described in the documentation does not work. My attempt to run
 the code is registered here: http://dpaste.com/hold/423359/

 Per Łukasz Rekucki, on django-users, it should be changed to:

 {{{
 class ProtectedView(TemplateView):
template_name = 'secret.html'

@method_decorator(login_required)
def dispatch(self, *args, **kwargs):
return super(ProtectedView, self).dispatch(*args, **kwargs)
 }}}

 I also recommend mentioning alternatives to providing the same
 functionality, such as the LoginMixin that was suggested by on the same
 django-users thread:

 {{{
 import settings

 class LoginMixin(object):
 def get_test_func(self):
 return getattr(self, 'test_func', lambda u: u.is_authenticated())
 def get_login_url(self):
 return getattr(self, 'login_url', settings.LOGIN_URL)
 def get_redirect_field_name(self):
 return getattr(self, 'redirect_field_name', None)
 def dispatch(self, request, *args, **kwargs):
 from django.contrib.auth.decorators import user_passes_test

 return user_passes_test(
 self.get_test_func(),
 login_url = self.get_login_url(),
 redirect_field_name = self.get_redirect_field_name()
 )(super(LoginMixin, self).dispatch
 )(request, *args, **kwargs)

 }}}

 Finally, thank you for providing us with this functionality and
 documentation. It really makes the code for my views leaner, cleaner,
 meaner.

 [[BR]]
 [[BR]]
 Best regards,
 [[BR]]
 André Terra

-- 
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] #15317: TransactionManagementError exception on a clean transaction

[Django]

#15317: TransactionManagementError  exception on a clean transaction
+---
   Reporter:  jbl1  | Owner:  nobody
 Status:  closed| Milestone:
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 Resolution:  invalid   |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by jbl1):

 Replying to [comment:1 russellm]:
 > Sounds like you've been tripped up by r15493. However, since you haven't
 provided any details that would allow us to reproduce your problem, I
 can't confirm or deny this.
 >
 > If you are reporting a problem, you need to provide enough detail for
 someone else to reproduce the problem *exactly*. It's no good giving vague
 descriptions -- we need specific code samples, or at the very least,
 precise instructions that will allow someone else to reproduce the problem
 you are seeing.
 >
 > Closing invalid. Please reopen if you can provide the necessary detail.

 Indeed, I was quite vague. My test view was:


 {{{
 @transaction.commit_manually
 def test(request):
 return render_to_response("bdo/test.html", RequestContext(request))
 }}}

 and it failed in my environment with the !TransactionManagementError
 exception. When trying to further minimize the example for the purpose of
 reopening this ticket, I removed the call to !RequestContext like so:


 {{{
 @transaction.commit_manually
 def test(request):
 return render_to_response("bdo/test.html")
 }}}

 and then the view passed.
 It turned out that I have a custom context processor which accesses the
 database to determine the menu functions available to the logged on user
 thus dirtying the transaction. I now do a conditional transaction.commit()
 in the context processor:


 {{{
 def create_menu(request):
# ...
# a database read
if transaction.is_managed() :
   transaction.commit()
# ...
 }}}
 which seems to solve the problem.

 So it turns out that the ticket as stated is indeed invalid. Nonetheless,
 to prevent others tripping over in similar circumstances it might be
 helpful to amend at least the 1.3 release notes
 (http://docs.djangoproject.com/en/dev/releases/1.3/#transaction-
 management) and perhaps also the Managing database transactions section of
 the documentation
 (http://docs.djangoproject.com/en/dev/topics/db/transactions/). Sorry for
 not providing a sample wording...

-- 
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] #15327: TEST_USER setting has become mandatory on Oracle

[Django]

#15327: TEST_USER setting has become mandatory on Oracle
--+-
 Reporter:  depaolim  |  Owner:  nobody
   Status:  new   |  Milestone:
Component:  Database layer (models, ORM)  |Version:  1.2   
 Keywords:  TEST_USER Oracle  |   Triage Stage:  Unreviewed
Has patch:  0 |  
--+-
 upgrade from django 1.2.1 to django 1.2.5
 I run tests and I obtained[[BR]]
 {{{
 KeyError: 'TEST_USER'
 }}}

 My box is:
  * CentOS 5.4
  * oracle-instantclient-basic-10.2.0.4-1.i386.zip
  * oracle-instantclient-devel-10.2.0.4-1.i386.zip
  * cx_Oracle 5.0.4
  * Django 1.2.5

 You can easily reproduce the problem:

 {{{
 django-admin.py startproject testdjango
 cd testdjango
 python manage.py startapp testapp
 # edit settings to configure connection to db
 python manage.py test
 # KeyError: 'TEST_USER'
 }}}

 according to http://code.djangoproject.com/wiki/OracleTestSetup and
 http://docs.djangoproject.com/en/1.2/ref/settings/#test-user

 The TEST_USER setting is optional: ''The username of such user isn't the
 same as the 'USER' var, is derived from it by adding a 'test_' prefix. It
 '''can''' be overridden with the value of the 'TEST_USER' var.''

 Since 1.2.1 this behavior has changed and now the setting is
 mandatory[[BR]]
 Working settings for django 1.2.5 are:
 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.oracle',
 'NAME': 'test',
 'USER': 'dslcm',
 'PASSWORD': '',
 'TEST_USER': 'test_dslcm',
 'HOST': '',
 'PORT': '',
 },
 }
 }}}

 I wasn't able to find this information in release notes nor in
 documentation[[BR]]

 My humble :) advice is to restore the optionality of this setting, or,
 otherwise, upgrade 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.

[Django] #15326: ModelForm doesn't do unique checks if any of the fields is exluded

[Django]

#15326: ModelForm doesn't do unique checks if any of the fields is exluded
--+-
 Reporter:  liorsion  |  Owner:  nobody
   Status:  new   |  Milestone:  1.3   
Component:  Forms |Version:  SVN   
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  
--+-
 If a model exists with unique_together fields, and a form doesn't display
 all the fields in the unique_together (at least one of them is excluded)
 the entire condition is ignored in the code. This is the wrong behavior,
 only if ALL the fields are excluded then the test should be ignore.

 Use case:

 House (class H) has Windows (class W) with different colors. A house has
 different colors for different windows, and a person can change the
 qualities of the window as long as they don't change the color to an
 existing one:

 So:

 class H(models.Model):
 

 Class W(models.Model):
 color:Models.IntegerField()
 house:Models.ForeignKey(H)
 . # other qualities of the window

 class Meta:
 unique_together = (("color", "house"),)

 And the form:

 class ChangeWindowForm(ModelForm):
 class Meta:
 model = W
 fields = ('color',  # other qualities)

 in this scenario, a form validation would pass if a H,C with the same
 values exist.

 The line that is the problem is in django.db.models.base.py, in def
 _get_unique_checks(self, exclude=None):

 if name in exclude:
 break

 a possible change:
 if any(check[i:i + len(exclude)] == exclude for i in range(len(check) -
 len(exclude) + 1)):
 break

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