Re: [Django] #10808: Multiple inheritance (model-based) broken for __init__ of common fields in diamond inheritance

[Django]

#10808: Multiple inheritance (model-based) broken for __init__ of common fields 
in
diamond inheritance
---+
  Reporter:  mikemintz | Owner:  jianhuang
Status:  assigned  | Milestone:   
 Component:  Database layer (models, ORM)  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Ready for checkin | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by shauncutts):

 * cc: sh...@cuttshome.net (added)

Comment:

 It seems to me that the "real underlying problem" is that Options (in
 source:trunk/django/db/models/options.py) doesn't have anything like the
 "method resolution order" (__mro__) list that python uses to linearize
 name resolution. The ORM should probably mimic python in resolving this
 problem.

 This may be the underlying problem in #13781 as well. As Russellm points
 out, multiple inheritance support is claimed, but not necessarily thought
 through completely, yet.

-- 
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-upda...@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] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
---+
  Reporter:  shauncutts| Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  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-upda...@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] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
---+
  Reporter:  shauncutts| Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 Huh. Ok... that's interesting. Thanks for setting me straight -- I wasn't
 aware we explicitly said that in the docs.

 In that case, there's definitely a bug 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-upda...@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] #12002: Models inherited from multiple Models

[Django]

#12002: Models inherited from multiple Models
---+
  Reporter:  vlastimil.z...@nic.cz | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Design decision needed => Accepted

Comment:

 As pointed out on #13781 -- the decision has already been made, and at
 least partially implemented. Multiple model inheritance is apparently ok,
 but buggy.

-- 
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-upda...@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] #12002: Models inherited from multiple Models

[Django]

#12002: Models inherited from multiple Models
---+
  Reporter:  vlastimil.z...@nic.cz | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by shauncutts):

 * cc: sha...@cuttshome.net (added)

Comment:

 A workaround I have used (but with some discomfort -- and it probably
 works only on some backends) is to change the database default of the id
 fields of all the base classes to get their next value from the same
 database sequence object.

-- 
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-upda...@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] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
---+
  Reporter:  shauncutts| Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by shauncutts):

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

Comment:

 Um .. ok: but may I suggest that you have a documentation bug then? See:

 http://docs.djangoproject.com/en/1.2/topics/db/models/#multiple-
 inheritance

 It certainly doesn't say its not supported.

-- 
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-upda...@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] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
---+
  Reporter:  shauncutts| Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:  wontfix   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 Multiple inheritance of models isn't officially supported (see #12002,
 #10808, amongst others). It *may* work under certain conditions, but it's
 certainly not guaranteed to work.

 The closest you'll be able to get is to do single inheritance, then use a
 OneToOne field to point at the second class.

 Closing wontfix since it's a bug in a configuration that we don't support.

-- 
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-upda...@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] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
---+
  Reporter:  shauncutts| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by shauncutts):

 * cc: sh...@cuttshome.net (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-upda...@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] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
--+-
 Reporter:  shauncutts|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I have a "Profile" model that inherits both from auth.User and Person --
 representing people who are users.
 Such people also have accounts -- Account has a OneToOneField relating it
 to a Profile.

 A particular user has an account.


 {{{
 >>> profile = Profile.objects.get( pk = 9819 )
 >>> profile
 
 >>> profile.account
 
 }}}

 


 But when I use a select_related, an error occurs:

 {{{
 In [36]: profile = Profile.objects.select_related( 'account' ).get( pk =
 9819 )
 ---
 TypeError Traceback (most recent call
 last)

 /Users/shauncutts/ in ()

 /Users/shauncutts/dev/django/db/models/query.pyc in get(self, *args,
 **kwargs)
 334 if self.query.can_filter():
 335 clone = clone.order_by()
 --> 336 num = len(clone)
 337 if num == 1:
 338 return clone._result_cache[0]

 /Users/shauncutts/dev/django/db/models/query.pyc in __len__(self)
  79 self._result_cache = list(self._iter)
  80 else:
 ---> 81 self._result_cache = list(self.iterator())
  82 elif self._iter:
  83 self._result_cache.extend(list(self._iter))

 /Users/shauncutts/dev/django/db/models/query.pyc in iterator(self)
 267
 268 compiler = self.query.get_compiler(using=self.db)
 --> 269 for row in compiler.results_iter():
 270 if fill_cache:
 271 obj, _ = get_cached_row(self.model, row,

 /Users/shauncutts/dev/django/db/models/sql/compiler.pyc in
 results_iter(self)
 670 resolve_columns = hasattr(self, 'resolve_columns')
 671 fields = None
 --> 672 for rows in self.execute_sql(MULTI):
 673 for row in rows:
 674 if resolve_columns:

 /Users/shauncutts/dev/django/db/models/sql/compiler.pyc in
 execute_sql(self, result_type)
 715 """
 716 try:
 --> 717 sql, params = self.as_sql()
 718 if not sql:
 719 raise EmptyResultSet

 /Users/shauncutts/dev/django/db/models/sql/compiler.pyc in as_sql(self,
 with_limits, with_col_aliases)
  53 in the query.
  54 """
 ---> 55 self.pre_sql_setup()
  56 out_cols = self.get_columns(with_col_aliases)
  57 ordering, ordering_group_by = self.get_ordering()

 /Users/shauncutts/dev/django/db/models/sql/compiler.pyc in
 pre_sql_setup(self)
  27 self.query.setup_inherited_models()
  28 if self.query.select_related and not
 self.query.related_select_cols:
 ---> 29 self.fill_related_selections()
  30
  31 def quote_name_unless_alias(self, name):

 /Users/shauncutts/dev/django/db/models/sql/compiler.pyc in
 fill_related_selections(self, opts, root_alias, cur_depth, used,
 requested, restricted, nullable, dupe_set, avoid_set)
 608 alias = root_alias
 609 alias_chain = []
 --> 610 chain = opts.get_base_chain(f.rel.to)
 611 if chain is not None:
 612 for int_model in chain:

 /Users/shauncutts/dev/django/db/models/options.pyc in get_base_chain(self,
 model)
 427 return [model]
 428 for parent in self.parents:
 --> 429 res = parent._meta.get_base_chain(model)
 430 if res:
 431 res.insert(0, parent)

 /Users/shauncutts/dev/django/db/models/options.pyc in get_base_chain(self,
 model)
 432 return res
 433 raise TypeError('%r is not an ancestor of this model'
 --> 434 % model._meta.module_name)
 435
 436 def get_parent_list(self):

 TypeError: 'profile' is not an ancestor of this model
 }}}

 Examination of the stack trace shows that the problem may be related to
 the fact that Profile inherits from both User and Person

 {{{
 >>> pdb.pm()
 > /Users/shauncutts/dev/django/db/models/options.py(434)get_base_chain()
 -> % model._meta.module_name)
 (Pdb) u
 > /Users/shauncutts/dev/django/db/models/options.py(429)get_base_chain()
 -> res = parent._meta.get_base_chain(model)
 (Pdb) print parent
 
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadl

[Django] #13780: Admin site documentation should specify ordering directions

[Django]

#13780: Admin site documentation should specify ordering directions
---+
 Reporter:  anonymous  |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The docs for the admin site don't mention ordering directions.
 {{{
 class AscendingStoryAdmin(admin.ModelAdmin):
 ordering = ('publishing_day',)

 class DescendingStoryAdmin(admin.ModelAdmin):
 ordering = ('-publishing_day',)
 }}}
 They should. It's important and not obvious to everyone.

-- 
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-upda...@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] #13695: Django Comments Loses Ajax Headers When Redirecting (request.is_ajax() === True --> request.is_ajax() === False)

[Django]

#13695: Django Comments Loses Ajax Headers When Redirecting (request.is_ajax() 
===
True --> request.is_ajax() === False)
+---
  Reporter:  jacobstr   | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by anonymous):

 Replying to [comment:1 r1cky]:
 > There is nothing django can do here. The initial and subsequent (after
 redirect) request are coming from the browser/client. The is_ajax method
 depends on an HTTP header (HTTP_X_REQUESTED_WITH) that apparently isn't
 getting set on the second request.

 Yes. My instinct is that this was an oversight and not deliberate.

-- 
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-upda...@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] #13774: add optional rel_db_type() method for model field

[Django]

#13774: add optional rel_db_type() method for model field
---+
  Reporter:  Suor  | Owner:  Suor   
   
Status:  reopened  | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  db, 
ForeignKey, related fields
 Stage:  Unreviewed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by Suor):

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

Comment:

 Patch is needed not to avoid a hack, but to make possible custom AutoField
 subclasses as in example.[[BR]]
 I'll provide whole rel_db_type() cleanup patch to follow Yoda.

 And no, it's not a precursor for NoSQL.

-- 
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-upda...@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] #13779: GeoDjango doesn't find libgdal 1.7.0

[Django]

#13779: GeoDjango doesn't find libgdal 1.7.0
-+--
 Reporter:  Leo  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  GIS  | Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 GeoDjango currently only searches for libgdal up to 1.6.0. Lucid +
 UbuntuGIS unstable actually installs gdal 1.7.0 and GeoDjango can't find
 it without setting the GDAL_LIBRARY_PATH.

 The attached patch fixes this bug.

-- 
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-upda...@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] #13153: An rpm fails to build with python setup.py bdist_rpm

[Django]

#13153: An rpm fails to build with python setup.py bdist_rpm
+---
  Reporter:  ce...@mifprojects.com  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Ready for checkin

Comment:

 We can keep this ticket open.

 As a side note - this is why we say "one issue per 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-upda...@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] #13615: test.TestCase.assert(Not)Contains assumes response content is a page.

[Django]

#13615: test.TestCase.assert(Not)Contains assumes response content is a page.
+---
  Reporter:  DaNmarner  | Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Accepted => Ready for checkin

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13777: problems using **kwargs to create an instance of a model with an AutoField primary key

[Django]

#13777: problems using **kwargs to create an instance of a model with an 
AutoField
primary key
---+
  Reporter:  seth_a| Owner:  nobody 

Status:  closed| Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  1.2

Resolution:  worksforme|  Keywords:  **kwargs, 
AutoField
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 I can't reproduce this. Logically, it doesn't make much sense, either:
 Klass(data=foo) and Klass(**{'data':foo}) are identical at the language
 parsing level, and neither should have any effect on the metaclass (which
 is where the class it constructed), since you're dealing with the __init__
 method when you create an instance.

 I suspect you have some other error of usage; please follow this up on
 django-users.

 Also, as a minor stylistic thing: According to PEP8, class names should be
 capitalized (Simple, not simple).

-- 
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-upda...@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] #13153: An rpm fails to build with python setup.py bdist_rpm

[Django]

#13153: An rpm fails to build with python setup.py bdist_rpm
+---
  Reporter:  ce...@mifprojects.com  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by grug...@yahoo.com):

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

Comment:

 The first issue is indeed a duplicate of #9616, but the second issue does
 not appear to be duplicate at all. The doc_files.diff patch still applies
 - should a new ticket be created, or can we proceed 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-upda...@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] #12460: inspectdb and field names ending with underscores

[Django]

#12460: inspectdb and field names ending with underscores
-+--
  Reporter:  3gun   | Owner:  
nobody
Status:  new | Milestone:   
 
 Component:  django-admin.py inspectdb   |   Version:  1.1  
 
Resolution:  |  Keywords:  
inspectdb underscore characters digits
 Stage:  Accepted| Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by elijahr):

  * 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-upda...@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] #6932: Flatpages does not provide a list of available flat pages to the context

[Django]

#6932: Flatpages does not provide a list of available flat pages to the context
--+-
  Reporter:  Dmitri Fedortchenko   | Owner:  
faldridge 
Status:  new  | Milestone:  
  
 Component:  Contrib apps |   Version:  
SVN   
Resolution:   |  Keywords:  
flatpages list templatetag
 Stage:  Accepted | Has_patch:  
1 
Needs_docs:  0|   Needs_tests:  
0 
Needs_better_patch:  0|  
--+-
Changes (by mitar):

 * cc: mmi...@gmail.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-upda...@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] #6932: Flatpages does not provide a list of available flat pages to the context

[Django]

#6932: Flatpages does not provide a list of available flat pages to the context
--+-
  Reporter:  Dmitri Fedortchenko   | Owner:  
faldridge 
Status:  new  | Milestone:  
  
 Component:  Contrib apps |   Version:  
SVN   
Resolution:   |  Keywords:  
flatpages list templatetag
 Stage:  Accepted | Has_patch:  
1 
Needs_docs:  0|   Needs_tests:  
0 
Needs_better_patch:  0|  
--+-
Comment (by mitar):

 +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-upda...@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] #12460: inspectdb and field names ending with underscores

[Django]

#12460: inspectdb and field names ending with underscores
-+--
  Reporter:  3gun   | Owner:  
nobody
Status:  new | Milestone:   
 
 Component:  django-admin.py inspectdb   |   Version:  1.1  
 
Resolution:  |  Keywords:  
inspectdb underscore characters digits
 Stage:  Accepted| Has_patch:  0
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by elijahr):

  * keywords:  inspectdb underscore => inspectdb underscore characters
   digits

Comment:

 There are a few other scenarios where invalid field names could be
 generated via the inspectdb command.  For instance, a column name of
 "Foo/Bar", while unconventional, is a valid column name, at least in MySQL
 5, but the invalid field name of 'foo/bar' would be generated.

 Currently, inspectdb ensures that:
 - field names do not contain spaces or dashes
 - field names are not Python keywords

 The patch I just attached improves this by also ensuring that:
 - field names do not contain any characters outside of a-zA-Z0-9_
 - field names do not contain double underscores
 - field names neither start nor end with underscores
 - field names do not start with digits

-- 
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-upda...@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] #13778: Error in documentation code

[Django]

#13778: Error in documentation code
---+
 Reporter:  canassa|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 There is an error in this page of the documentation:

 http://docs.djangoproject.com/en/1.2/ref/models/instances/#id1

 The following code:

 {{{
 from django.core.validators import ValidationError, NON_FIELD_ERRORS
 try:
 article.full_clean():
 except ValidationError, e:
 non_field_errors = e.message_dict[NON_FIELD_ERRORS]
 }}}


 should be:


 {{{
 from django.core.validators import ValidationError, NON_FIELD_ERRORS
 try:
 article.full_clean()
 except ValidationError, e:
 non_field_errors = e.message_dict[NON_FIELD_ERRORS]
 }}}

-- 
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-upda...@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] r13354 - django/branches/soc2010/query-refactor/tests/regressiontests/mongodb

[noreply]

Author: Alex
Date: 2010-06-16 15:48:45 -0500 (Wed, 16 Jun 2010)
New Revision: 13354

Modified:
   
django/branches/soc2010/query-refactor/tests/regressiontests/mongodb/models.py
   django/branches/soc2010/query-refactor/tests/regressiontests/mongodb/tests.py
Log:
[soc2010/query-refactor] Introduced tests to show that ForeignKeys work 
correctly.

Modified: 
django/branches/soc2010/query-refactor/tests/regressiontests/mongodb/models.py
===
--- 
django/branches/soc2010/query-refactor/tests/regressiontests/mongodb/models.py  
2010-06-14 20:09:24 UTC (rev 13353)
+++ 
django/branches/soc2010/query-refactor/tests/regressiontests/mongodb/models.py  
2010-06-16 20:48:45 UTC (rev 13354)
@@ -6,5 +6,12 @@
 name = models.CharField(max_length=255)
 good = models.BooleanField()
 
+current_group = models.ForeignKey("Group", null=True)
+
 def __unicode__(self):
 return self.name
+
+
+class Group(models.Model):
+id = models.NativeAutoField(primary_key=True)
+name = models.CharField(max_length=255)

Modified: 
django/branches/soc2010/query-refactor/tests/regressiontests/mongodb/tests.py
===
--- 
django/branches/soc2010/query-refactor/tests/regressiontests/mongodb/tests.py   
2010-06-14 20:09:24 UTC (rev 13353)
+++ 
django/branches/soc2010/query-refactor/tests/regressiontests/mongodb/tests.py   
2010-06-16 20:48:45 UTC (rev 13354)
@@ -1,7 +1,7 @@
 from django.db.models import Count
 from django.test import TestCase
 
-from models import Artist
+from models import Artist, Group
 
 
 class MongoTestCase(TestCase):
@@ -44,3 +44,16 @@
 self.assertEqual(Artist.objects.filter(good=False).count(), 1)
 
 self.assertEqual(Artist.objects.aggregate(c=Count("pk")), {"c": 6})
+
+def test_foreignkey(self):
+e = Group.objects.create(name="The E Street Band")
+b = Artist.objects.create(name="Clarence Clemons", good=True,
+current_group=e)
+
+self.assertEqual(b.current_group, e)
+self.assertEqual(b.current_group_id, e.pk)
+
+b = Artist.objects.get(name="Clarence Clemons")
+self.assertEqual(b.current_group_id, e.pk)
+self.assertFalse(hasattr(b, "_current_group_cache"))
+self.assertEqual(b.current_group, e)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #10890: generic views archive_week and archive_day should have next/previous as Template Context

[Django]

#10890: generic views archive_week and archive_day should have next/previous as
Template Context
+---
  Reporter:  ee_lars| Owner:  nobody
   
Status:  new| Milestone:
   
 Component:  Generic views  |   Version:  SVN   
   
Resolution: |  Keywords:  generic views date_based 
archive_day archive_week
 Stage:  Accepted   | Has_patch:  1 
   
Needs_docs:  0  |   Needs_tests:  1 
   
Needs_better_patch:  0  |  
+---
Comment (by michelts):

 Palewire: I think you can use "day.strftime('%U')" instead of
 "day.isocalendar()[1]". With the second choice, you can't do an easy
 navigation because the week numbers of day.isocalendar() are different
 from the result of the '%U'.

 Once django itself uses the '%U' to know what week we are, using it in the
 dates will be better. I will send a patch.

 I will make the tests and documentation for it too, maybe it can appear in
 the django1.3?

-- 
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-upda...@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] #11277: Hidden fields in Inlines are displayed as empty rows

[Django]

#11277: Hidden fields in Inlines are displayed as empty rows
---+
  Reporter:  bartTC| Owner:  nobody 
  
Status:  reopened  | Milestone: 
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  admin inlines 
hiddeninput
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by narcelio):

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

Comment:

 The issue is that labels are still being rendered on forms, even when the
 field is hidden. Labels should not be rendered if field is hidden, right?

 (Maybe the problem is at
 django/contrib/admin/templates/admin/includes/fieldset.html or
 !AdminField.label_tag().)

 Checkout a discussion about that:

 [http://stackoverflow.com/questions/1408940/how-do-i-hide-the-field-label-
 for-a-hiddeninput-widget-in-django-admin How do I hide the field label for
 a HiddenInput widget in Django Admin?]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13615: test.TestCase.assert(Not)Contains assumes response content is a page.

[Django]

#13615: test.TestCase.assert(Not)Contains assumes response content is a page.
+---
  Reporter:  DaNmarner  | Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by DaNmarner):

  * needs_better_patch:  1 => 0

Comment:

 Here, now its fixed

-- 
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-upda...@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] #11624: `render_to_kmz` can't handle non-ascii data

[Django]

#11624: `render_to_kmz` can't handle non-ascii data
---+
  Reporter:  jbronn| Owner:  jbronn   
Status:  closed| Milestone:  1.2  
 Component:  GIS   |   Version:  SVN  
Resolution:  fixed |  Keywords:  gis kmz render_to_kmz
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by palewire):

 Thanks for doing this. Just patched it on 1.1 and found the fix is already
 in the trunk. You guys rock!

-- 
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-upda...@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] #13777: problems using **kwargs to create an instance of a model with an AutoField primary key

[Django]

#13777: problems using **kwargs to create an instance of a model with an 
AutoField
primary key
--+-
 Reporter:  seth_a|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:  **kwargs, AutoField   |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 I've found that if you create a simple model with an AutoField for a
 primary key, even the default one, like:

 {{{
 from django import models

 class simple(models.Model):
 data = models.CharField()
 }}}

 creating and saving an instance with:

 {{{
 temp = simple(data="example")
 temp.save()
 }}}

 causes no problems. If you use **kwargs, however:

 {{{
 temp = simple(**{'data':'example'})
 temp.save()
 }}}

 then django never defines the Autofield, so when _get_pk_val is called in
 django/trunk/django/db/models/base.py, its getattr call never finds the
 field id (or whatever you named it, I tested with explicitly defining an
 AutoField named blah).

 The solution to this is to change _get_pk_val from:

 {{{
 def _get_pk_val(self, meta=None):
 if not meta:
 meta = self._meta
 return getattr(self, meta.pk.attname)
 }}}

 to:

 {{{
 def _get_pk_val(self, meta=None):
 if not meta:
 meta = self._meta
 try:
 return getattr(self, meta.pk.attname)
 except AttributeError:
 return None
 }}}

 As None was what this function was supposed to return when the primary key
 did not exist, the rest of the calling function can now do the right thing
 and create the AutoField, which I've tested and few times with both the
 default AutoField and an explicitly defined AutoField primary key, and
 things seem to work.

 There may have been a way to handle this earlier in the code when **kwargs
 was checked, but this was the easiest fix.

 And sorry for not having an svn diff! I don't have the development code
 checked out, and this is my first patch submission.

 Also, I've noticed that the code looks the same in the dev version.
 Perhaps it has the same 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-upda...@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] #6434: auto_now and auto_now_add documentation

[Django]

#6434: auto_now and auto_now_add documentation
+---
  Reporter:  jok...@radgjafahus.is  | Owner:  adamnelson
 
Status:  new| Milestone:
 
 Component:  Documentation  |   Version:  SVN   
 
Resolution: |  Keywords:  datefield 
auto_now auto_now_add
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  1  |  
+---
Comment (by CollinAnderson):

 See also #7634 and http://code.djangoproject.com/ticket/12785#comment: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-upda...@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] #12785: Docs do not 'warn' against the use of auto_now and auto_now_add

[Django]

#12785: Docs do not 'warn' against the use of auto_now and auto_now_add
---+
  Reporter:  joshh...@massiveatom.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Documentation |   Version:  1.1   
Resolution:  wontfix   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 #7634 and #6434

-- 
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-upda...@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] #13729: UK localflavor mis-named/documentation bug.

[Django]

#13729: UK localflavor mis-named/documentation bug.
---+
  Reporter:  schinckel | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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-upda...@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] #13760: Management commands should not specify the default value twice

[Django]

#13760: Management commands should not specify the default value twice
--+-
  Reporter:  PaulM| Owner:  nobody
Status:  new  | Milestone:
 Component:  django-admin.py  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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-upda...@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] #13746: dumpdata help does not include info about custom managers

[Django]

#13746: dumpdata help does not include info about custom managers
+---
  Reporter:  PaulM  | Owner:  PaulM 
Status:  new| Milestone:
 Component:  django-admin.py|   Version:  1.2   
Resolution: |  Keywords:  django-admin, dumpdata
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Ready for checkin
  * 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-upda...@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] #13686: Asymmetry in memcached.add and memcached.set

[Django]

#13686: Asymmetry in memcached.add and memcached.set
+---
  Reporter:  nedbatchelder  | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Cache system   |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

-- 
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-upda...@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] #13699: Catalan translation: corrections and missing messages for trunk

[Django]

#13699: Catalan translation: corrections and missing messages for trunk
---+
  Reporter:  txels | Owner:  nobody 
Status:  new   | Milestone: 
 Component:  Translations  |   Version:  SVN
Resolution:|  Keywords:  catalan
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  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-upda...@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] #13645: The “local flavo r” add-ons for Turkey

[Django]

#13645: The “local flavor” add-ons for Turkey
-+--
  Reporter:  rkirmizi| Owner:  nobody   
   
Status:  new | Milestone:   
   
 Component:  django.contrib.localflavor  |   Version:  1.2  
   
Resolution:  |  Keywords:  turkish 
local flavor
 Stage:  Accepted| Has_patch:  0
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Comment:

 The starting point is to write the code and upload a patch. Use one of the
 other localflavors as a starting point if you need hint on what is
 required.

-- 
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-upda...@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] #13733: New Zealand localflavor

[Django]

#13733: New Zealand localflavor
-+--
  Reporter:  schinckel   | Owner:  nobody
Status:  new | Milestone:
 Component:  django.contrib.localflavor  |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * component:  Contrib apps => django.contrib.localflavor
  * 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-upda...@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] #13776: is_valid() on ModelForms on models with ForeignKeys cause ValueError rather than False

[Django]

#13776: is_valid() on ModelForms on models with ForeignKeys cause ValueError 
rather
than False
--+-
 Reporter:  peterbe   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Forms | Version:  1.2   
 Keywords:  ModelForm ForeignKey  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 See [http://groups.google.com/group/django-
 developers/browse_thread/thread/33e41f02c8fc5f7c this email] for a longer
 description and a traceback.

 In summary:
 If you try to use a !ModelForm to create a form without the intention of
 running the {{{save()}}}  method it will raise a !ValueError when you call
 {{{is_valid()}}}. This is because the !ForeignKey field has a __setattr__
 override which prevents it from being None at all, ever. When you're just
 testing the form it should wrap this in a case so that it doesn't
 immediately complain.

-- 
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-upda...@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] #13775: Clarify in docs that filters don't work in ifequal

[Django]

#13775: Clarify in docs that filters don't work in ifequal
+---
  Reporter:  jogwen | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  wontfix|  Keywords:  ifequal filter
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by lukeplant):

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

Comment:

 The 1.0 branch is no longer receiving bugfixes (and that includes
 documentation).  Why not use Django 1.2?  Then you can do:

 {{{
 #!html+django
 {% if request.GET.ds_doc_type == type.id|toUnicode %}
 }}}

 which will do what you want.

-- 
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-upda...@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] #13774: add optional rel_db_type() method for model field

[Django]

#13774: add optional rel_db_type() method for model field
---+
  Reporter:  Suor  | Owner:  Suor   
   
Status:  closed| Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:  wontfix   |  Keywords:  db, 
ForeignKey, related fields
 Stage:  Unreviewed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 I'm afraid I don't see why this is required. The explanation in ticket
 says it's to avoid a hack, but doesn't describe what that hack is required
 to solve; the patch doesn't contain any test cases to demonstrate why the
 feature is required (or that it even works as suggested). I'm also not
 especially inspired by a patch for a new feature that contains a TODO
 marker. As Yoda would advise: Do or do not... there is no TODO :-)

 If this is a precursor to the NoSQL work, then it should be folded into
 that work; we're not going to accept and modify code that pre-empts the
 solution introduced by a SoC 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-upda...@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] #13773: model field's db_type() called without connection arg in pg creation.py

[Django]

#13773: model field's db_type() called without connection arg in pg creation.py
---+
  Reporter:  Suor  | Owner:  Suor
Status:  new   | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  1.2 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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-upda...@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] #13615: test.TestCase.assert(Not)Contains assumes response content is a page.

[Django]

#13615: test.TestCase.assert(Not)Contains assumes response content is a page.
+---
  Reporter:  DaNmarner  | Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Changes (by russellm):

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

Comment:

 Patch as written will break the tests in the regression test suite that
 check the exceptions that are raised by assert(Not)Contains.

-- 
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-upda...@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] #13612: Settings.py should not be mandatory

[Django]

#13612: Settings.py should not be mandatory
--+-
  Reporter:  tonnzor  | Owner:  nobody
Status:  new  | Milestone:
 Component:  django-admin.py  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 Agreed that this is a bit of a wart. It's also a case where we should be
 checking that the module exists, rather than importing and catching the
 import error.

-- 
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-upda...@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] #13611: get_next_by_FOO allows nulls

[Django]

#13611: get_next_by_FOO allows nulls
---+
  Reporter:  CarlFK| Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  wontfix   |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 You say "we" discussed this on IRC, but you don't say who "we" are. I
 don't find the behavior you describe to be obvious or non-surprising. It's
 also something you can add to your own models if you happen to need or
 want the behavior as you describe it.

 Marking wontfix; please open a discussion on django-dev if you are
 especially passionate about 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-upda...@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] #13610: Missing ENGINE setting in settings.py doesn't produce error

[Django]

#13610: Missing ENGINE setting in settings.py doesn't produce error
+---
  Reporter:  jtiai  | Owner:  gregmuellegger 
Status:  assigned   | Milestone:  1.3
 Component:  Core framework |   Version:  SVN
Resolution: |  Keywords:  settings config
 Stage:  Ready for checkin  | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Ready for checkin
  * needs_tests:  1 => 0
  * milestone:  => 1.3

Comment:

 This is one of those times when it is ok to skip having a test, and just
 eyeball it prior to checkin.

 The patch as presented looks reasonable, so I'll mark it 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-upda...@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] #13609: Using a non existent template in admin.Inlines produce error when posting the form

[Django]

#13609: Using a non existent template in admin.Inlines produce error when 
posting
the form
---+
  Reporter:  kunitoki  | Owner:  nobody 

Status:  new   | Milestone:  1.3

 Component:  django.contrib.admin  |   Version:  1.2-beta   

Resolution:|  Keywords:  Inline custom 
template ValidationError ManagementForm data missing tampered
 Stage:  Accepted  | Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

  * component:  Core framework => django.contrib.admin
  * stage:  Unreviewed => Accepted

Comment:

 This problem exists because Django's template language silently eats
 errors, so the call to {% include inline_admin.opts.template %} fails
 silently if the template doesn't exist.

 The solution here is to validate that the template exists when the
 InlineModelAdmin object is validated -- see
 django.contrib.admin.validation.validate_inline.

-- 
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-upda...@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] #13608: Clarify failure of lookups when argument to lookup is not an int

[Django]

#13608: Clarify failure of lookups when argument to lookup is not an int
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 To clarify the complaint: The issue here is that the list example foo[bar]
 implies that the list will do a lookup using the value of the variable
 'bar', when it will in fact only work with foo.3 (or other integer value).

 Given that variable lookup is an important omission from Django's template
 language, this warrants clarification.

-- 
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-upda...@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] #13607: Admin date_hierarchy drill-down should auto-initialise to appropriate level

[Django]

#13607: Admin date_hierarchy drill-down should auto-initialise to appropriate 
level
--+-
  Reporter:  DrMeers  | Owner:   
Status:  new  | Milestone:  1.3  
 Component:  User Experience  |   Version:  SVN  
Resolution:   |  Keywords:  admin, date_hierarchy
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

Comment:

 Sounds like a reasonable suggestion; implementing it in an efficient way
 could be interesting, though.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13605: Storage.listdir() missing from the reference page

[Django]

#13605: Storage.listdir() missing from the reference page
+---
  Reporter:  kopernikus | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:  custom storage
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 Agreed -- the file storage API docs could be improved.

-- 
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-upda...@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] #13604: AssertRedirects test method tests the status code of initial response instead of the last redirect

[Django]

#13604: AssertRedirects test method tests the status code of initial response
instead of the last redirect
+---
  Reporter:  jukvalim   | Owner:  nobody 
Status:  closed | Milestone: 
 Component:  Testing framework  |   Version:  1.2
Resolution:  invalid|  Keywords:  assertRedirects
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 As far as I can make out, the current behaviour is correct, and there are
 a number of test cases in the test_client_regress suite to verify that the
 behavior works as expected. If you made the change you describe, you would
 be testing against the response from the last redirect, not the response
 that served the final page.

-- 
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-upda...@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] #13600: OverflowError not caught in django.views.static.serve

[Django]

#13600: OverflowError not caught in django.views.static.serve
+---
  Reporter:  KostikVento| Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution:  worksforme |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 I can't reproduce the problem you describe -- using Python 2.6, the date
 "Mon 28 May 3121 28:25:26" actually parses correctly as "Tue, 29 May 3121
 04:25:26"; using Python 2.5, it raises a ValueError. (Both of these tests
 were running under Mac OSX).

 Closing worksforme; If you can provide more specific reproduction
 instructions, please reopen.

-- 
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-upda...@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] #13599: Incorrect HTML in change_list when list_editable is used

[Django]

#13599: Incorrect HTML in change_list when list_editable is used
---+
  Reporter:  skevy | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  list_editable, 
html, rendering, admin
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  1 |  
---+
Changes (by russellm):

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

Comment:

 I'm not a huge fan of just disappearing the problem -- the hidden field
 should be rendered such that it doesn't require an extra TD element.

-- 
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-upda...@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] #13591: SplitDateTimeField admin usability broken when using format localization

[Django]

#13591: SplitDateTimeField admin usability broken when using format localization
---+
  Reporter:  ludwik| Owner:  nobody 

Status:  new   | Milestone:  1.3

 Component:  Forms |   Version:  1.2

Resolution:|  Keywords:  localization, 
SplitDateTimeField, admin
 Stage:  Accepted  | Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 This appears to be a fault in the Admin widgets specifically (i.e.,
 AdminSplitDateTime), not SplitDateTimeField.

-- 
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-upda...@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] #13775: Clarify in docs that filters don't work in ifequal

[Django]

#13775: Clarify in docs that filters don't work in ifequal
+---
 Reporter:  jogwen  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Documentation   | Version:  1.0   
 Keywords:  ifequal filter  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Can you please make it a bit more explicit in
 http://docs.djangoproject.com/en/1.0/ref/templates/builtins/#ifequal that
 ifequal cannot evaluate its arguments - I just wasted several hours (and
 created several custom filters) trying to work out why

 ifequal request.GET.ds_doc_type type.id|toUnicode

 always evaluates to False when

 {{request.GET.ds_doc_type}}({{request.GET.ds_doc_type|getType}})
 and
 {{type.id|toUnicode}}({{type.id|toUnicode|getType}})

 looked identical when rendered to the screen.

 I've now written a custom filter to do the equality check and am using it
 in an 'if' which seems to work ok.

 Many Thanks,

 Jo

-- 
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-upda...@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] #13710: raw() sql bug when using a model with many fields with long names

[Django]

#13710: raw() sql bug when using a model with many fields with long names
---+
  Reporter:  Renskers  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.2
  
Resolution:|  Keywords:  raw sql 
joins
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by Renskers):

  * summary:  raw() sql bug when using joins => raw() sql bug when using a
  model with many fields with long names

-- 
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-upda...@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] #13712: raw() sql bug in Python 2.5.2

[Django]

#13712: raw() sql bug in Python 2.5.2
---+
  Reporter:  Renskers  | Owner:  nobody 

Status:  closed| Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  1.2

Resolution:  duplicate |  Keywords:  raw sql 
iterate
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 This ticket can be closed, see ticket #13710 for fix.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13710: raw() sql bug when using joins

[Django]

#13710: raw() sql bug when using joins
---+
  Reporter:  Renskers  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.2
  
Resolution:|  Keywords:  raw sql 
joins
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by Renskers):

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

Comment:

 I found the source of the problem. My model has a lot of fields, and most
 of them have long, verbose names.

 The error is caused in django/db/models/query_utils.py, on line 267:
 name = "%s_Deferred_%s" % (model.__name__, '_'.join(sorted(list(attrs

 This results in a *very* long string, which cannot be handled, or so it
 seems.

 When I change this line to something like this, it does work:
 name = "%s_Deferred_%s" % (model.__name__, '_lala')

 It's weird that this problem only presents itself when you don't use
 model.*. When using model.* in the raw query, everything works fine.

 This also fixes bug #13712.

-- 
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-upda...@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] #10759: UserAdmin views should use attribute or current model to lookup the template paths

[Django]

#10759: UserAdmin views should use attribute or current model to lookup the
template paths
---+
  Reporter:  jturnbull | Owner:  nobody 
  
Status:  new   | Milestone:  1.3
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  UserAdmin, 
add_view, user_change_password
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by jturnbull):

  * milestone:  => 1.3

Comment:

 This patch is ready to go and accepted - can someone push this into Django
 1.3?

-- 
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-upda...@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] #13774: add optional rel_db_type() method for model field

[Django]

#13774: add optional rel_db_type() method for model field
+---
 Reporter:  Suor|   Owner:  Suor  
   Status:  new |   Milestone:
Component:  Database layer (models, ORM)| Version:  1.2   
 Keywords:  db, ForeignKey, related fields  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 rel_db_type() method will return db_type for ForeignKey / OneToOneField to
 a field,
 if not exists value of db_type() method should be used as it's done now.

 It will remove a need for a hack in ForeignKey.db_type and make possible
 subclasses of AutoField work such as:

 {{{
 class BigAutoField(models.AutoField):
 def __init__(self, verbose_name=None, name=None,
 external_sequence=False, **kwargs):
 self.external_sequence = external_sequence
 models.AutoField.__init__(self, verbose_name, name, **kwargs)

 def db_type(self, connection):
 # now only for PostgreSQL, should be done more carefully to
 support other backends
 return 'bigint' if self.external_sequence else 'bigserial'

 def rel_db_type(self, connection):
 return 'bigint'
 }}}

-- 
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-upda...@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] #13773: model field's db_type() called without connection arg in pg creation.py

[Django]

#13773: model field's db_type() called without connection arg in pg creation.py
--+-
 Reporter:  Suor  |   Owner:  Suor  
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 In django/db/backends/postgresql/creation.py line 66 db_type() method
 called without connection argument

-- 
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-upda...@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] #13772: 'exists' parameter for pre_save signal

[Django]

#13772: 'exists' parameter for pre_save signal
+---
  Reporter:  gsakkis| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gsakkis):

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

Comment:

 Patch (including updated tests) attached; needs docs, will add 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-upda...@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] #13772: 'exists' parameter for pre_save signal

[Django]

#13772: 'exists' parameter for pre_save signal
---+
 Reporter:  gsakkis|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 As Model.save() is called both for inserts and updates, it would sometimes
 be useful for pre_save listeners to know whether the instance exists or
 not. This information is sent with post_save but by then it may be too
 late (e.g. under some conditions you may want to prevent an insertion from
 happening).

-- 
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-upda...@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] #13756: File upload not working under Tomcat

[Django]

#13756: File upload not working under Tomcat
+---
  Reporter:  SvenKlemm  | Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by txels):

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

Comment:

 I tested Sven's patch in Django 1.1.2 / Jython 2.5.1 / Tomcat 5.5. and it
 does solve the issue.

-- 
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-upda...@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] #13730: Allow db_index=False for ForeignKey

[Django]

#13730: Allow db_index=False for ForeignKey
---+
  Reporter:  Suor  | Owner:  Suor
Status:  new   | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  1.2 
Resolution:|  Keywords:  
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by Suor):

  * owner:  nobody => Suor

-- 
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-upda...@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] #13771: ForeignKey and Many2Many validation fails between databases

[Django]

#13771: ForeignKey and Many2Many validation fails between databases
---+
  Reporter:  jdetaeye  | Owner:  nobody 
Status:  new   | Milestone:  1.3
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  multidb
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  1 |  
---+
Changes (by jdetaeye):

  * needs_better_patch:  => 1
  * 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-upda...@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] #13771: ForeignKey and Many2Many validation fails between databases

[Django]

#13771: ForeignKey and Many2Many validation fails between databases
--+-
 Reporter:  jdetaeye  |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:  multidb   |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The validation of ForeignKey and Many2Many fields isn't selecting the
 right database. The validity of the PKs in the referenced table is always
 checked in the database chosen by the _default_manager. If that database
 is different than the one containing the model_instance, this validation
 check is incorrect.

 See http://groups.google.com/group/django-
 users/browse_thread/thread/639df3f9412ef1d3#

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