Re: [Django] #13839: select_related caches None for non-existent objects in reverse one-to-one relations

[Django]

#13839: select_related caches None for non-existent objects in reverse 
one-to-one
relations
--+-
  Reporter:  shauncutts   | Owner: 
Status:  new  | Milestone: 
 Component:  ORM aggregation  |   Version:  1.2
Resolution:   |  Keywords: 
 Stage:  Unreviewed   | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by shauncutts):

 The patch seems to do the trick... at the very least though, the error
 message probably needs a tweak -- what info do you typically put into
 them? Also, still needs a test.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #10154: allow the combination of an F expression with a timedelta

[Django]

#10154: allow the combination of an F expression with a timedelta
---+
  Reporter:  Koen Biermans   | 
Owner:  nobody 
Status:  new   | 
Milestone: 
 Component:  Database layer (models, ORM)  |   
Version:  SVN
Resolution:|  
Keywords:  expressions
 Stage:  Accepted  | 
Has_patch:  1  
Needs_docs:  0 |   
Needs_tests:  1  
Needs_better_patch:  1 |  
---+
Comment (by kmtracey):

 Updated patch.
  * Reimplemented the sqlite support using a custom function; use of the
 sqlite-provided strftime causes problems because it will only format 3
 digits of fractional second information, plus I do not see how to properly
 format both dates and datetimes in a way that will make them compare
 properly -- including trailing zeros for time information breaks
 comparisons against simple DATE values in sqlite.
  * Disallowed any ops other than addition and subtraction, letting others
 through to be caught by the DB leads to varying and potentially puzzling
 database errors, so it is better to make them fail early.
  * Beefed up the tests and made them unit tests, not doctests.
  * Some of the mixed (date, datetime) comparison tests fail on sqlite.
 That may be unavoidable due to the way it is just (I believe) comparing
 string values. I'm not sure we can code this to know when it is and is not
 right to drop zero-time information, but I have not fully looked into that
 so for now I have not yet coded that test to be skipped on sqlite.

-- 
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] #7284: foreign_key__related_fieldname documentation could be clearer

[Django]

#7284: foreign_key__related_fieldname documentation could be clearer
---+
  Reporter:  rbell01...@earthlink.net  | Owner:  DrMeers
Status:  assigned  | Milestone:  1.3
 Component:  Documentation |   Version:  SVN
Resolution:|  Keywords:  foreign_key
 Stage:  Ready for checkin | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by DrMeers):

  * owner:  nobody => DrMeers
  * status:  new => assigned
  * stage:  Accepted => Ready for checkin
  * 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] #13839: select_related caches None for non-existent objects in reverse one-to-one relations

[Django]

#13839: select_related caches None for non-existent objects in reverse 
one-to-one
relations
--+-
  Reporter:  shauncutts   | Owner: 
Status:  new  | Milestone: 
 Component:  ORM aggregation  |   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] #13839: select_related caches None for non-existent objects in reverse one-to-one relations

[Django]

#13839: select_related caches None for non-existent objects in reverse 
one-to-one
relations
-+--
 Reporter:  shauncutts   |   Owner:
   Status:  new  |   Milestone:
Component:  ORM aggregation  | Version:  1.2   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Suppose we have the following:
 {{{
 class AM( models.Manager ):
 def get_query_set( self ):
 q = super( AM, self ).get_query_set()
 q = q.select_related( 'b' )
 return q

 class A( models.Model ):
 objects = AM()

 pass

 class B( A ):
 pass

 }}}
 Then when we create an A, and retrieve via the manager we have:
 {{{
 >>> A.objects.create()
 
 >>> a = A.objects.all()[ 0 ]
 >>> a.__dict__
 {'_b_cache': None,
  '_state': ,
  'id': 2}
 }}}

 This causes problems, as {{{ a.b }}} yields None rather than triggering
 ObjectDoesNotExist, which causes problems -- e.g.:

 {{{
 >>> a.delete()
 /Users/shauncutts/dev/django/db/models/base.pyc in delete(self, using)
 645 # Find all the objects than need to be deleted.

 646 seen_objs = CollectedObjects()
 --> 647 self._collect_sub_objects(seen_objs)
 648
 649 # Actually delete the objects.


 /Users/shauncutts/dev/django/db/models/base.pyc in
 _collect_sub_objects(self, seen_objs, parent, nullable)
 --> 580 sub_obj._collect_sub_objects(seen_objs, self,
 related.field.null)
 581 else:
 582 # To make sure we can access all elements, we
 can't use the


 AttributeError: 'NoneType' object has no attribute '_collect_sub_objects'
 }}}

-- 
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] #13617: USE_L10N results in faulty javascript code in GeoDjango with some locales

[Django]

#13617: USE_L10N results in faulty javascript code in GeoDjango with some 
locales
+---
  Reporter:  piquadrat  | Owner:  jbronn
Status:  assigned   | Milestone:  1.3   
 Component:  GIS|   Version:  1.2   
Resolution: |  Keywords:  L10N gis gmaps
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by piquadrat):

 Although I didn't change the component to "Template system", I have some
 sympathies with the anonymous change. IMHO, this is a bug (or an
 oversight, or a missing feature) in the template system, and the GIS
 component is affected by the bug. Incorporating a workaround in the GIS
 JavaScript code may solve the particular issue I did report in the first
 place. But it doesn't solve the deeper problem that L10N can't be used
 (bar some ugly workarounds) in a project that outputs strictly structured
 information through the templating system.

-- 
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] #13834: Dumpdata/loaddata cycle fails when using a single-field natural key

[Django]

#13834: Dumpdata/loaddata cycle fails when using a single-field natural key
+---
  Reporter:  claudep| Owner:  nobody
Status:  closed | Milestone:
 Component:  Serialization  |   Version:  1.2   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by claudep):

 Argh... My bad!

 But what about adding an assertion? This would help to catch the error
 sooner in the process.

-- 
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] #13834: Dumpdata/loaddata cycle fails when using a single-field natural key

[Django]

#13834: Dumpdata/loaddata cycle fails when using a single-field natural key
+---
  Reporter:  claudep| Owner:  nobody
Status:  closed | Milestone:
 Component:  Serialization  |   Version:  1.2   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ramiro):

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

Comment:

 Your `natural_key()` model method should always return a tuple, no special
 treatment is given to a natural key with one element:

 {{{
 def natural_key(self):
 return (self.name,)
 }}}

 Reproduced the problem here with an your example code, then made that
 change and serializing/deserializing again worked flawlessly. From
 http://docs.djangoproject.com/en/dev/topics/serialization/#serialization-
 of-natural-keys: ''That method should always return a natural key tuple --
 in this example, (first name, last name)''

 Closing 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-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] #7284: foreign_key__related_fieldname documentation could be clearer

[Django]

#7284: foreign_key__related_fieldname documentation could be clearer
---+
  Reporter:  rbell01...@earthlink.net  | Owner:  nobody 
Status:  new   | Milestone: 
 Component:  Documentation |   Version:  SVN
Resolution:|  Keywords:  foreign_key
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by DrMeers):

  * has_patch:  0 => 1

Comment:

 Clarifying example added as requested.

-- 
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] #2569: [patch] Admin page Foreign Key improvements

[Django]

#2569: [patch] Admin page Foreign Key improvements
--+-
  Reporter:  joelh-dja...@planetjoel.com  | Owner:  nobody
Status:  closed   | Milestone:
 Component:  django.contrib.admin |   Version:  SVN   
Resolution:  duplicate|  Keywords:
 Stage:  Someday/Maybe| Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by DrMeers):

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

Comment:

 The admin code has changed too much since this patch was created; I
 suggest moving discussions to #13165 (which I guess is technically the
 ''real'' duplicate), which has a newer patch. We still have some admin
 permission issues to solve before getting the patches committed. There are
 some design decisions to be made regarding dynamic linking using
 JavaScript also. See discussions at http://groups.google.com/group/django-
 developers/browse_thread/thread/8812e50dfa1a3a8

-- 
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] #11251: Australian Local Flavo(u)r models would be nice

[Django]

#11251: Australian Local Flavo(u)r models would be nice
--+-
  Reporter:  Simon Meers   | Owner:  DrMeers 
 
Status:  new  | Milestone:  1.3 
 
 Component:  django.contrib.localflavor   |   Version:  SVN 
 
Resolution:   |  Keywords:  
Australia
 Stage:  Accepted | Has_patch:  1   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Changes (by jezdez):

  * milestone:  => 1.3

Comment:

 No, that's fine, the patch looks good.

-- 
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] #11251: Australian Local Flavo(u)r models would be nice

[Django]

#11251: Australian Local Flavo(u)r models would be nice
--+-
  Reporter:  Simon Meers   | Owner:  DrMeers 
 
Status:  new  | Milestone:  
 
 Component:  django.contrib.localflavor   |   Version:  SVN 
 
Resolution:   |  Keywords:  
Australia
 Stage:  Accepted | Has_patch:  1   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Comment (by DrMeers):

 Would we be better off closing this and leaving such things out of Django
 core/contrib? DDN I guess...

-- 
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] #13165: Display edit link beside add button for ForeignKey fields in admin

[Django]

#13165: Display edit link beside add button for ForeignKey fields in admin
--+-
  Reporter:  DrMeers  | Owner:  DrMeers 
   
Status:  new  | Milestone:  1.3 
   
 Component:  User Experience  |   Version:  SVN 
   
Resolution:   |  Keywords:  admin foreign key edit 
link
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by DrMeers):

 Replying to [comment:8 anonymous]:
 > It has some issues with the hungarian accented strings: If there is
 accent in the object's name, it does not render either the select widget,
 nor the add/edit buttons.

 I cannot reproduce this problem; please provide an example problematic
 accented string.

-- 
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:  DrMeers  
Status:  assigned | Milestone:  1.3  
 Component:  User Experience  |   Version:  SVN  
Resolution:   |  Keywords:  admin, date_hierarchy
 Stage:  Accepted | Has_patch:  1
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Changes (by DrMeers):

  * owner:  => DrMeers
  * status:  new => assigned
  * has_patch:  0 => 1

Comment:

 Pretty dead-simple patch really. Much nicer to use now. I don't think the
 aggregate query has any major efficiency issues?

-- 
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] #2445: [patch] allow callable values for limit_choices_to

[Django]

#2445: [patch] allow callable values for limit_choices_to
+---
  Reporter:  mich...@actrix.gen.nz  | Owner:  nobody
Status:  new| Milestone:
 Component:  Core framework |   Version:
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  1  |   Needs_tests:  1 
Needs_better_patch:  1  |  
+---
Changes (by jspiros):

 * cc: joseph.spi...@ithinksw.com (added)

Comment:

 I'm not sure if this covers every use case, or if this is just a stupid
 hack that shouldn't be considered a proper solution to this problem, but
 what I've done is create classes that implement add_to_query (instances of
 which can be supplied to, I believe, any method that also accepts a Q
 object), and which dynamically create and add appropriate Q objects to the
 query upon invocation. My use case for the moment is limiting the choice
 of ContentTypes on the content type ForeignKey used by a
 GenericForeignKey. See
 
[http://github.com/ithinksw/philo/blob/46fdca9049d4b7806bc4d6ec33973a3fc19153c4/utils.py
 ContentTypeLimiter and subclasses] in my 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] #7722: EMail Message with CC - Carbon Copy

[Django]

#7722: EMail Message with CC - Carbon Copy
-+--
  Reporter:  roberto.digirolamo   | Owner:  
nobody
Status:  new | Milestone:   
 
 Component:  django.core.mail|   Version:  
SVN   
Resolution:  |  Keywords:   
 
 Stage:  Design decision needed  | Has_patch:  
1 
Needs_docs:  1   |   Needs_tests:  
1 
Needs_better_patch:  0   |  
-+--
Changes (by adehnert):

 * cc: alex-sort.dja...@dehnerts.com (added)

Comment:

 I'd like to see this feature. It looks like nobody's spoken against this
 feature in almost two years. Is this still something that people are
 opposed to?

 Thanks, Alex.

-- 
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] #13838: Enhancements to Japanese localflavor module

[Django]

#13838: Enhancements to Japanese localflavor module
+---
 Reporter:  IanLewis|   Owner:  nobody
   Status:  new |   Milestone:
Component:  django.contrib.localflavor  | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 This is a patch for the Japanese localflavor module that fixes a long
 standing problem with the ordering of the JPPrefectureSelect widget and
 adds new form fields for doing common validation on Japanese text.

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