Re: [Django] #13494: Bad default for EMAIL_SUBJECT_PREFIX

[Django]

#13494: Bad default for EMAIL_SUBJECT_PREFIX
---+
  Reporter:  hcarvalhoalves| Owner:  nobody
Status:  new   | Milestone:
 Component:  django.core.mail  |   Version:  1.1   
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] #13492: get_or_create(field__iexact=value) fails to set value.

[Django]

#13492: get_or_create(field__iexact=value) fails to set value.
-+--
  Reporter:  Chris Dukes   | Owner:  
nobody
Status:  closed  | Milestone:   
 
 Component:  Uncategorized   |   Version:  1.1  
 
Resolution:  invalid |  Keywords:   
 
 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
  * needs_tests:  => 0
  * needs_docs:  => 0
  * resolution:  => invalid

Old description:

> I'm not sure if this is a documentation bug, or a code bug, or operator
> headspace error.
>
> I have a model where a column needs to be unique in a case insensitive
> fashion, but should be stored in a case sensitive fashion.
> I have applied custom SQL for that constraint.
>
> As I am bulk loading the table, I am making use of
> get_or_create(field0__iexact=value0, field1=value1).
> When I use this invocation, field0 ends up being set as null.
>
> If I invoke it as get_or_create(field0__iexact=value0, field0=value0,
> ...)
> I eventually have a constraint error.
>
> I would expect a FieldError if field0__iexact were not permitted, and I
> would expect the fieldname to be calculated from field0__iexact if it
> were permitted.
>
> I am currently avoiding the problem by catching an exception on
> psycopg2.IntegrityError, but that does not seem to be the right solution.
>
> Thanks,
> Chris Dukes

New description:

 I'm not sure if this is a documentation bug, or a code bug, or operator
 headspace error.

 I have a model where a column needs to be unique in a case insensitive
 fashion, but should be stored in a case sensitive fashion.
 I have applied custom SQL for that constraint.

 As I am bulk loading the table, I am making use of
 get_or_create(field0!__iexact=value0, field1=value1).
 When I use this invocation, field0 ends up being set as null.

 If I invoke it as get_or_create(field0!__iexact=value0, field0=value0,
 ...)
 I eventually have a constraint error.

 I would expect a FieldError if field0!__iexact were not permitted, and I
 would expect the fieldname to be calculated from field0!__iexact if it
 were permitted.

 I am currently avoiding the problem by catching an exception on
 psycopg2.IntegrityError, but that does not seem to be the right solution.

 Thanks,
 Chris Dukes

Comment:

 Sounds like you've missed
 [http://docs.djangoproject.com/en/dev/ref/models/querysets/#get-or-create-
 kwargs the section on defaults in the docs].

 For future reference, if you're uncertain if you've found a bug, it's
 better to ask on django-users first.

-- 
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] #13269: "Overriding the default widgets" docs missing import statement

[Django]

#13269: "Overriding the default widgets" docs missing import statement
+---
  Reporter:  mattrowbum | Owner:  gabrielhurley 
   
Status:  assigned   | Milestone:  1.2   
   
 Component:  Documentation  |   Version:  1.2-beta  
   
Resolution: |  Keywords:  widgets, form field 
types
 Stage:  Ready for checkin  | Has_patch:  1 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Changes (by timo):

  * 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] #12313: Mention some cautions in section overriding delete()

[Django]

#12313: Mention some cautions in section overriding delete()
+---
  Reporter:  FunkyELF   | Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.1 
Resolution: |  Keywords:  delete admin signals
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

  * 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] #13336: Document example for setting HttpResponse headers is misleading because it users wrong cache header

[Django]

#13336: Document example for setting HttpResponse headers is misleading because 
it
users wrong cache header
+---
  Reporter:  dnjuls | Owner:  nobody   
Status:  new| Milestone:  1.2  
 Component:  Documentation  |   Version:  SVN  
Resolution: |  Keywords:  cache reponse headers
 Stage:  Ready for checkin  | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

  * 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] #13488: Exceptions in GEOS I/O object destructor at process exit

[Django]

#13488: Exceptions in GEOS I/O object destructor at process exit
---+
  Reporter:  mro...@arinc.com  | Owner:  jbronn  
Status:  assigned  | Milestone:  
 Component:  GIS   |   Version:  1.2-beta
Resolution:|  Keywords:  gis 
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

  * summary:  GeoDjango => Exceptions in GEOS I/O object destructor at
  process exit

-- 
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] #13488: GeoDjango

[Django]

#13488: GeoDjango
---+
  Reporter:  mro...@arinc.com  | Owner:  jbronn  
Status:  assigned  | Milestone:  
 Component:  GIS   |   Version:  1.2-beta
Resolution:|  Keywords:  gis 
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

  * milestone:  1.2 =>

Comment:

 This isn't a 1.2 release blocker.

-- 
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] #13488: GeoDjango

[Django]

#13488: GeoDjango
---+
  Reporter:  mro...@arinc.com  | Owner:  jbronn  
Status:  assigned  | Milestone:  1.2 
 Component:  GIS   |   Version:  1.2-beta
Resolution:|  Keywords:  gis 
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by jbronn):

 I can't reproduce.  I need details on the platform you're using.  What
 version of Python/Django/GEOS/PostGIS?  What OS are you running on
 (instinct tells me RHEL)?

 I don't think memory leakage is occurring.  !GeoDjango instantiates up to
 5 GEOS I/O objects per-thread.  These references are cleaned up by the
 `__del__` method on the I/O objects, however in your particular install of
 Python the GC order has the I/O object destructor wrapper destroyed before
 the Python object -- hence why it doesn't exist at the time of interpreter
 exit.  The GEOS I/O references aren't being cleaned upon exit of the
 process, so even though the references aren't released the process memory
 space should be reclaimed by the OS regardless because the process is
 terminating.

 In other words, it may look bad but it's relatively benign.  But again, I
 need more details so I can confirm what's going on and possibly tweak
 variable names so it won't occur on platforms of your type.

-- 
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] #13488: GeoDjango

[Django]

#13488: GeoDjango
---+
  Reporter:  mro...@arinc.com  | Owner:  jbronn  
Status:  assigned  | Milestone:  1.2 
 Component:  GIS   |   Version:  1.2-beta
Resolution:|  Keywords:  gis 
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

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

Old description:

> I see this traceback in GeoDjango when the application exits.  Not
> exactly
> sure but there may be some memory leakage here.
>
> Exception TypeError: "'NoneType' object is not callable" in  method_WKTReader.__del__
> ofdjango.contrib.gis.geos.prototypes.io._WKTReader object at 0x6b1a790>>
> ignored
>
> Exception TypeError: "'NoneType' object is not callable" in  _WKBReader.__del__ of  object at 0x6b43690>> ignored
>
> Exception TypeError: "'NoneType' object is not callable" in  WKBWriter.__del__ of  object at 0x6b1ad50>> ignored
>
> To reproduce, just run a distance function (for example:
>
> airport.objects.distance("POINT (-74.31667536
> 40.90002494)")
>
> Whent the application exits (or exit from a python prompt),  you'll get
> the
> exceptions.

New description:

 I see this traceback in GeoDjango when the application exits.  Not exactly
 sure but there may be some memory leakage here.
 {{{

 Exception TypeError: "'NoneType' object is not callable" in >
 ignored

 Exception TypeError: "'NoneType' object is not callable" in > ignored

 Exception TypeError: "'NoneType' object is not callable" in > ignored
 }}}

 To reproduce, just run a distance function (for example:
 {{{
 airport.objects.distance("POINT (-74.31667536
 40.90002494)")
 }}}

 Whent the application exits (or exit from a python prompt),  you'll get
 the
 exceptions.

-- 
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] #13494: Bad default for EMAIL_SUBJECT_PREFIX

[Django]

#13494: Bad default for EMAIL_SUBJECT_PREFIX
---+
  Reporter:  hcarvalhoalves| Owner:  nobody
Status:  new   | Milestone:
 Component:  django.core.mail  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Comment:

 A couple of workarounds could be wrapping your translatable subject with a
 [http://docs.djangoproject.com/en/1.1/ref/unicode/#translated-strings call
 to call unicode()] before passing it to `mail_managers()` or using
 [http://docs.djangoproject.com/en/1.1/topics/i18n/internationalization
 /#working-with-lazy-translation-objects string_concat()].

-- 
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] #13493: ImportError when trying to use models from standalone script.

[Django]

#13493: ImportError when trying to use models from standalone script.
---+
  Reporter:  e...@justin.tv| Owner:  nobody
Status:  reopened  | Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta  
Resolution:|  Keywords:  regression
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by e...@justin.tv):

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

Comment:

 My script does import and use checkpoint.app.models (which Exam is one
 of).  I would rather not pollute the module namespace of my script with
 that of my django project if possible.  I have attached a reproducible
 test case.

 From the django-bug-report directory, "./runpy.sh fail.py" will throw the
 error if run against 1.2-rc-1, but succeed when run against 1.2-beta-1

 Historically, Django hasn't required the project root to be in the Python
 path to use the models, so long as you can import them.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13477: Slovenian translation of Django

[Django]

#13477: Slovenian translation of Django
+---
  Reporter:  gand...@owca.info  | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Translations   |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Comment (by jezdez):

 There is only one item left:

 {{{
 #: contrib/admin/options.py:1071
 #, fuzzy, python-format
 msgid "0 of %(cnt)s selected"
 msgstr ""
 }}}

-- 
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] #13493: ImportError when trying to use models from standalone script.

[Django]

#13493: ImportError when trying to use models from standalone script.
---+
  Reporter:  e...@justin.tv| Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta  
Resolution:  invalid   |  Keywords:  regression
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 This is likely due to r12950, and it appears to me that that fix is
 revealing an existing problem in the environment setup for the script. It
 looks to me like `/Users/kd5bjo/sentinel/checkpoint` should be included in
 the PYTHONPATH for this script. When you try to execute the
 `Exam.objects.get(id=id)` query, Django needs to load all models from all
 INSTALLED_APPS to ensure all the model relationships are set up properly.
 It cannot load the models for `app` because `app` isn't found on the
 Python path. Due to the bug fixed by r12950, that legitimate !ImportError
 was being suppressed, when it should not have been: it's a real problem.

 Does your script not actually use any of the `app` models? That may be why
 you were not seeing any problems with it. Or have you elsewhere caused
 these models to get loaded by importing `checkpoint.app.models`? (I'm not
 entirely sure if that would work to get things set up properly when you
 have just `app` listed in INSTALLED_APPS.)

 If you've got a script running using settings that refer to an app, that
 app needs to be findable via the Python path for things to work properly.
 The fix here should be to properly set the PYTHONPATH for this script.

-- 
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] r13123 - django/trunk/django/conf/locale/fy_NL

[noreply]

Author: jezdez
Date: 2010-05-07 13:53:58 -0500 (Fri, 07 May 2010)
New Revision: 13123

Added:
   django/trunk/django/conf/locale/fy_NL/__init__.py
   django/trunk/django/conf/locale/fy_NL/formats.py
Log:
Added preliminary Frisian formats.

Added: django/trunk/django/conf/locale/fy_NL/__init__.py
===

Added: django/trunk/django/conf/locale/fy_NL/formats.py
===
--- django/trunk/django/conf/locale/fy_NL/formats.py
(rev 0)
+++ django/trunk/django/conf/locale/fy_NL/formats.py2010-05-07 18:53:58 UTC 
(rev 13123)
@@ -0,0 +1,18 @@
+# -*- encoding: utf-8 -*-
+# This file is distributed under the same license as the Django package.
+#
+
+# DATE_FORMAT = 
+# TIME_FORMAT = 
+# DATETIME_FORMAT = 
+# YEAR_MONTH_FORMAT = 
+# MONTH_DAY_FORMAT = 
+# SHORT_DATE_FORMAT = 
+# SHORT_DATETIME_FORMAT = 
+# FIRST_DAY_OF_WEEK = 
+# DATE_INPUT_FORMATS = 
+# TIME_INPUT_FORMATS = 
+# DATETIME_INPUT_FORMATS = 
+# DECIMAL_SEPARATOR = 
+# THOUSAND_SEPARATOR = 
+# NUMBER_GROUPING = 

-- 
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] r13122 - django/trunk/django/conf/locale/sv

[noreply]

Author: jezdez
Date: 2010-05-07 13:53:37 -0500 (Fri, 07 May 2010)
New Revision: 13122

Modified:
   django/trunk/django/conf/locale/sv/formats.py
Log:
Fixed #13485 - Updated Swedish formats. Thanks, algestam.

Modified: django/trunk/django/conf/locale/sv/formats.py
===
--- django/trunk/django/conf/locale/sv/formats.py   2010-05-07 18:53:19 UTC 
(rev 13121)
+++ django/trunk/django/conf/locale/sv/formats.py   2010-05-07 18:53:37 UTC 
(rev 13122)
@@ -11,13 +11,24 @@
 SHORT_DATETIME_FORMAT = 'Y-m-d H:i'
 FIRST_DAY_OF_WEEK = 1
 DATE_INPUT_FORMATS = (
-'%Y-%m-%d', # '2006-10-25'
+'%Y-%m-%d',  # '2006-10-25'
+'%m/%d/%Y',  # '10/25/2006'
+'%m/%d/%y',  # '10/25/06'
 )
 TIME_INPUT_FORMATS = (
-'%H:%i',# '14:30'
+'%H:%M:%S', # '14:30:59'
+'%H:%M',# '14:30'
 )
 DATETIME_INPUT_FORMATS = (
-'%Y-%m-%d %H:%i',   # '2006-10-25 14:30'
+'%Y-%m-%d %H:%M:%S', # '2006-10-25 14:30:59'
+'%Y-%m-%d %H:%M',# '2006-10-25 14:30'
+'%Y-%m-%d',  # '2006-10-25'
+'%m/%d/%Y %H:%M:%S', # '10/25/2006 14:30:59'
+'%m/%d/%Y %H:%M',# '10/25/2006 14:30'
+'%m/%d/%Y',  # '10/25/2006'
+'%m/%d/%y %H:%M:%S', # '10/25/06 14:30:59'
+'%m/%d/%y %H:%M',# '10/25/06 14:30'
+'%m/%d/%y',  # '10/25/06'
 )
 DECIMAL_SEPARATOR = '.'
 THOUSAND_SEPARATOR = ' '

-- 
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] r13121 - django/trunk/django/conf/locale/bs

[noreply]

Author: jezdez
Date: 2010-05-07 13:53:19 -0500 (Fri, 07 May 2010)
New Revision: 13121

Added:
   django/trunk/django/conf/locale/bs/__init__.py
   django/trunk/django/conf/locale/bs/formats.py
Log:
Added preliminary Bosnian formats.

Added: django/trunk/django/conf/locale/bs/__init__.py
===

Added: django/trunk/django/conf/locale/bs/formats.py
===
--- django/trunk/django/conf/locale/bs/formats.py   
(rev 0)
+++ django/trunk/django/conf/locale/bs/formats.py   2010-05-07 18:53:19 UTC 
(rev 13121)
@@ -0,0 +1,18 @@
+# -*- encoding: utf-8 -*-
+# This file is distributed under the same license as the Django package.
+#
+
+DATE_FORMAT = 'j. N Y.'
+TIME_FORMAT = 'G:i'
+DATETIME_FORMAT = 'j. N. Y. G:i T'
+YEAR_MONTH_FORMAT = 'F Y.'
+MONTH_DAY_FORMAT = 'j. F'
+SHORT_DATE_FORMAT = 'Y M j'
+# SHORT_DATETIME_FORMAT = 
+# FIRST_DAY_OF_WEEK = 
+# DATE_INPUT_FORMATS = 
+# TIME_INPUT_FORMATS = 
+# DATETIME_INPUT_FORMATS = 
+DECIMAL_SEPARATOR = ','
+THOUSAND_SEPARATOR = '.'
+# NUMBER_GROUPING = 

-- 
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] r13120 - django/trunk/django/conf/locale/sq

[noreply]

Author: jezdez
Date: 2010-05-07 13:52:59 -0500 (Fri, 07 May 2010)
New Revision: 13120

Added:
   django/trunk/django/conf/locale/sq/__init__.py
   django/trunk/django/conf/locale/sq/formats.py
Log:
Added preliminary Albanian formats.

Added: django/trunk/django/conf/locale/sq/__init__.py
===

Added: django/trunk/django/conf/locale/sq/formats.py
===
--- django/trunk/django/conf/locale/sq/formats.py   
(rev 0)
+++ django/trunk/django/conf/locale/sq/formats.py   2010-05-07 18:52:59 UTC 
(rev 13120)
@@ -0,0 +1,18 @@
+# -*- encoding: utf-8 -*-
+# This file is distributed under the same license as the Django package.
+#
+
+DATE_FORMAT = 'd F Y'
+TIME_FORMAT = 'g.i.s.A'
+# DATETIME_FORMAT = 
+YEAR_MONTH_FORMAT = 'F Y'
+MONTH_DAY_FORMAT = 'j F'
+SHORT_DATE_FORMAT = 'Y-m-d'
+# SHORT_DATETIME_FORMAT = 
+# FIRST_DAY_OF_WEEK = 
+# DATE_INPUT_FORMATS = 
+# TIME_INPUT_FORMATS = 
+# DATETIME_INPUT_FORMATS = 
+DECIMAL_SEPARATOR = ','
+THOUSAND_SEPARATOR = '.'
+# NUMBER_GROUPING = 

-- 
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] #13491: Irish translations for django 1.2 Release Candidate

[Django]

#13491: Irish translations for django 1.2 Release Candidate
---+
  Reporter:  mt| Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  Translations  |   Version:  1.2-beta
Resolution:|  Keywords:  Irish   
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Changes (by jezdez):

  * needs_better_patch:  0 => 1

Comment:

 Please also make sure to update the translation of the JavaScript? files.
 You can update the djangojs.po files by running django-admin.py
 makemessages -l  -d djangojs

-- 
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] #13494: Bad default for EMAIL_SUBJECT_PREFIX

[Django]

#13494: Bad default for EMAIL_SUBJECT_PREFIX
--+-
 Reporter:  hcarvalhoalves|   Owner:  nobody
   Status:  new   |   Milestone:  2.0   
Component:  django.core.mail  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The 'EMAIL_SUBJECT_PREFIX' setting is, by default, a string. This makes it
 break loud and needlessly if you pass a translation as the subject to
 'mail_managers()':


 {{{
 TypeError
 cannot concatenate 'str' and '__proxy__' objects
 }}}


 The culprit line of django/core/mail.py:

 {{{
  424. EmailMessage(settings.EMAIL_SUBJECT_PREFIX + subject, message, ...
 }}}

 Seems like an easy fix (just change the default setting to unicode?).

-- 
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] #13493: ImportError when trying to use models from standalone script.

[Django]

#13493: ImportError when trying to use models from standalone script.
---+
  Reporter:  e...@justin.tv| Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta  
Resolution:|  Keywords:  regression
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by e...@justin.tv):

 * cc: e...@justin.tv (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] #13493: ImportError when trying to use models from standalone script.

[Django]

#13493: ImportError when trying to use models from standalone script.
--+-
 Reporter:  e...@justin.tv|   Owner:  nobody
   Status:  new   |   Milestone:  1.2   
Component:  Database layer (models, ORM)  | Version:  1.2-beta  
 Keywords:  regression|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 This is a regression between 1.2-beta-1 and 1.2-rc-1

 I have a maintenance script that accesses the database via the same django
 models I'm using for the website.  When I upgraded from 1.2-beta-1 to
 1.2-rc-1, this script started failing with the following traceback unless
 the PWD is the django project directory:

 {{{
 Traceback (most recent call last):
   File "test.py", line 19, in 
 exam = Exam.objects.get(id=id)
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/manager.py",
 line 132, in get
 return self.get_query_set().get(*args, **kwargs)
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/query.py",
 line 333, in get
 clone = self.filter(*args, **kwargs)
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/query.py",
 line 550, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/query.py",
 line 568, in _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File
 
"/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/sql/query.py",
 line 1131, in add_q
 can_reuse=used_aliases)
   File
 
"/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/sql/query.py",
 line 1026, in add_filter
 negate=negate, process_extras=process_extras)
   File
 
"/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/sql/query.py",
 line 1182, in setup_joins
 field, model, direct, m2m = opts.get_field_by_name(name)
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/options.py",
 line 291, in get_field_by_name
 cache = self.init_name_map()
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/options.py",
 line 321, in init_name_map
 for f, model in self.get_all_related_m2m_objects_with_model():
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/options.py",
 line 396, in get_all_related_m2m_objects_with_model
 cache = self._fill_related_many_to_many_cache()
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/options.py",
 line 410, in _fill_related_many_to_many_cache
 for klass in get_models():
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/loading.py",
 line 167, in get_models
 self._populate()
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/loading.py",
 line 61, in _populate
 self.load_app(app_name, True)
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/db/models/loading.py",
 line 76, in load_app
 app_module = import_module(app_name)
   File
 "/Users/kd5bjo/sentinel/packages/Django-1.2-rc-1/django/utils/importlib.py",
 line 35, in import_module
 __import__(name)
 ImportError: No module named app
 }}}

 The script is being executed with the following environment variables:

 {{{
 
PYTHONPATH=.:./packages/Django-1.2-rc-1:./packages/south:.:/Users/kd5bjo/Library/Python/2.5
 /site-packages:/Library/Python/2.5/site-
 packages:/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
 DJANGO_SETTINGS_MODULE=checkpoint.settings
 PWD=/Users/kd5bjo/sentinel
 }}}

 The django project root is /Users/kd5bjo/sentinel/checkpoint, and the
 django app in question is called "app"

-- 
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] #13492: get_or_create(field__iexact=value) fails to set value.

[Django]

#13492: get_or_create(field__iexact=value) fails to set value.
+---
 Reporter:  Chris Dukes   |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Uncategorized   | Version:  1.1   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 I'm not sure if this is a documentation bug, or a code bug, or operator
 headspace error.

 I have a model where a column needs to be unique in a case insensitive
 fashion, but should be stored in a case sensitive fashion.
 I have applied custom SQL for that constraint.

 As I am bulk loading the table, I am making use of
 get_or_create(field0__iexact=value0, field1=value1).
 When I use this invocation, field0 ends up being set as null.

 If I invoke it as get_or_create(field0__iexact=value0, field0=value0, ...)
 I eventually have a constraint error.

 I would expect a FieldError if field0__iexact were not permitted, and I
 would expect the fieldname to be calculated from field0__iexact if it were
 permitted.

 I am currently avoiding the problem by catching an exception on
 psycopg2.IntegrityError, but that does not seem to be the right solution.

 Thanks,
 Chris Dukes

-- 
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] #13491: Irish translations for django 1.2 Release Candidate

[Django]

#13491: Irish translations for django 1.2 Release Candidate
---+
  Reporter:  mt| Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  Translations  |   Version:  1.2-beta
Resolution:|  Keywords:  Irish   
 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.

[Django] #13491: Irish translations for django 1.2 Release Candidate

[Django]

#13491: Irish translations for django 1.2 Release Candidate
--+-
 Reporter:  mt|   Owner:  nobody
   Status:  new   |   Milestone:  1.2   
Component:  Translations  | Version:  1.2-beta  
 Keywords:  Irish |   Stage:  Unreviewed
Has_patch:  0 |  
--+-


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13490: Django's `order_by` Performs Differently Based on Environment

[Django]

#13490: Django's `order_by` Performs Differently Based on Environment
+---
  Reporter:  b14ck  | Owner:  nobody
  
Status:  closed | Milestone:  1.3   
  
 Component:  Uncategorized  |   Version:  SVN   
  
Resolution:  invalid|  Keywords:  database, query, 
order_by, inconsistency
 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:

 I can't find any evidence that this is happening. A queryset is a
 queryset, and querysets have an order_by method. You haven't provided
 sample view code; I can only presume that your view has an error of some
 kind.

-- 
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] #13490: Django's `order_by` Performs Differently Based on Environment

[Django]

#13490: Django's `order_by` Performs Differently Based on Environment
--+-
 Reporter:  b14ck |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Uncategorized | Version:  SVN   
 Keywords:  database, query, order_by, inconsistency  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Hi there. I came across the following (seemingly) inconsistency with
 Django's `order_by` method, that is usually used on DB queries. It appears
 to act differently when used in production vs. when used through python
 manage.py shell:

 # from python manage.py shell
 {{{
 rdeg...@web01:~/partyline_portal$ python manage.py shell
 Python 2.6.4 (r264:75706, Dec  7 2009, 18:43:55)
 [GCC 4.4.1] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> from partyline_portal.partylines.models import Partyline
 >>> partylines = Partyline.objects.all()
 >>> partylines
 []
 >>> partylines = Partyline.objects.all().order_by('name')
 >>> partylines
 []
 >>> partylines = Partyline.objects.all()
 >>> partylines
 []
 >>> partylines.order_by('name')
 []
 >>>
 }}}

 As you can see above, I can use the `order_by` function on both queries:
 Partyline.objects.all().order_by('name') as well as lists:
 partylines.order_by('name')

 However, if I run this same code in a view, and render a page to the user,
 Django spits an error saying that partylines has no method `order_by`
 available to it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13486: TIME_INPUT_FORMATS %P doesn't work

[Django]

#13486: TIME_INPUT_FORMATS %P doesn't work
+---
  Reporter:  Bufke   | Owner:  nobody  
Status:  closed | Milestone:  
 Component:  Uncategorized  |   Version:  1.2-beta
Resolution:  invalid|  Keywords:  
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 %P isn't a valid formatting character, %p is. Hence the failure. Closing
 invalid.

 As for Karen's reported problem: I couldn't reproduce this, and speaking
 with Karen on IRC, she couldn't reproduce her earlier failure.

-- 
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] #5390: Add signals to ManyRelatedManager

[Django]

#5390: Add signals to ManyRelatedManager
--+-
  Reporter:  Ludovico Magnocavallo   | Owner:  
rvdrijst   
Status:  closed   | Milestone:  1.2 
   
 Component:  Database layer (models, ORM) |   Version:  SVN 
   
Resolution:  fixed|  Keywords:  
manytomanyfield feature signals
 Stage:  Design decision needed   | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  1|  
--+-
Changes (by muanis):

 * cc: mua...@pobox.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] #13479: Support of settings.ADMIN_FOR in django.contrib.sites

[Django]

#13479: Support of settings.ADMIN_FOR in django.contrib.sites
--+-
  Reporter:  bernhard   | Owner:  nobody  
   
Status:  closed   | Milestone:  
   
 Component:  Contrib apps |   Version:  1.1 
   
Resolution:  invalid  |  Keywords:  
django.contrib.sites, sites framework, settings,  ADMIN_FOR
 Stage:  Unreviewed   | Has_patch:  0   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

-- 
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] #13478: Session backends should all refuse user-defined, non-existant IDs

[Django]

#13478: Session backends should all refuse user-defined, non-existant IDs
--+-
  Reporter:  jdunck   | Owner:  nobody
Status:  new  | Milestone:
 Component:  django.contrib.sessions  |   Version:  1.1   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 This should be enforced consistently.

-- 
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] #13484: Update Sphinx Makefile for the latest sphinx

[Django]

#13484: Update Sphinx Makefile for the latest sphinx
+---
  Reporter:  Alex   | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Documentation  |   Version:  SVN   
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] #13485: Input formats for Swedish locale needs improvement

[Django]

#13485: Input formats for Swedish locale needs improvement
---+
  Reporter:  algestam  | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Internationalization  |   Version:  SVN   
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] #13489: Arbitrary Q filter on related model fields

[Django]

#13489: Arbitrary Q filter on related model fields
+---
  Reporter:  jnothman   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution:  wontfix|  Keywords:
 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:  => wontfix
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This is getting into the territory where you need to move into raw SQL.

 Django's ORM isn't trying to be a 100% solution. It tries to make simple
 things trivial, and hard things possible. However, if you are making a
 serious attempt at optimizing a query, you shouldn't be trying to use the
 ORM - you should be using raw SQL.

-- 
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] #13482: multidb and RelatedManager

[Django]

#13482: multidb and RelatedManager
+---
  Reporter:  climbus| Owner:  nobody  
Status:  closed | Milestone:  
 Component:  Uncategorized  |   Version:  1.2-beta
Resolution:  fixed  |  Keywords:  
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by climbus):

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

Comment:

 It seems it works on rc1.

 Sorry for mess.

-- 
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] #13: Related objects interface should be tighter (edit_inline)

[Django]

#13: Related objects interface should be tighter (edit_inline)
---+
  Reporter:  adrian| Owner:  barbuza
   
Status:  reopened  | Milestone: 
   
 Component:  django.contrib.admin  |   Version:  SVN
   
Resolution:|  Keywords:  nfa-someday 
nfa-changelist
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 Who do I need to talk to [http://www.guccishopping.com/ ed hardy]if I want
 to help implement this?
 That would be me. I go by "coderanger" on IRC, and can be found there most
 of the time.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13489: Arbitrary Q filter on related model fields

[Django]

#13489: Arbitrary Q filter on related model fields
---+
 Reporter:  jnothman   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Given a model with a foreign key, e.g. the classic Entry / Blog example,
 we may want to select/aggregate over entries contained in blogs with
 certain features. We can e.g. perform a filter over the joined relation:

 {{{
 Entry.objects.filter(blog__tagline__contains="foobar")
 }}}

 As far as I know, we cannot define a Q instance defined to filter Blog
 (which may be pre-defined for other purposes) to perform the same filter
 over a join:

 The closest we can get (in 1.1) is:

 {{{
 q = Q(tagline__contains="foobar")
 Entry.objects.filter(blog_in=q)
 }}}

 which performs a sub-select query, with the same results, but different
 efficiency, and different fields available for output.

 I propose one of two syntax options:

 {{{
 Entry.objects.filter(blog_has=q)
 }}}

 or:

 {{{
 Entry.objects.filter(q.apply_to_field('blog'))
 }}}

-- 
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] #13: Related objects interface should be tighter (edit_inline)

[Django]

#13: Related objects interface should be tighter (edit_inline)
---+
  Reporter:  adrian| Owner:  barbuza
   
Status:  reopened  | Milestone: 
   
 Component:  django.contrib.admin  |   Version:  SVN
   
Resolution:|  Keywords:  nfa-someday 
nfa-changelist
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 Who do I need to talif I want

 to help implement this?
 That would be me. I go by "coderanger" on IRC, and can be found there most

 of thA (simple) ticket can be attached

 to an (aggregate) ticket:
 •to a milestone, as it is done now (display in the combobox only available

 milestone tickets)
 •to a master ticket (display in that combobox only available master

 tickets)
 [http://www.maslou.com/ louis vuitton]It remains to be seen if an

 (aggregate) ticket could itself be attached to another (aggregate)
 You're quite right - reworking the modules and

 breaking down the tickets into different types seems a good solution, and

 more flexible than simply 'bolting on' master tickets.
 Master tickets should be children of Milestone tickets, but not other

 Master tickets.

-- 
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] #17: Metasystem optimization: Share select_related in memory

[Django]

#17: Metasystem optimization: Share select_related in memory
---+
  Reporter:  adrian| Owner:  PhiR   

Status:  assigned  | Milestone: 

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

Resolution:|  Keywords:  feature 
caching
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  1 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 was talking with PhiR in the IRC channel. [http://www.gln2008.com/ ed
 hardy t shirt] I would just like to mention two issues: 1. Thread safety
 -- for python > 2.3 we can wrap the storage in threading.local to avoid
 issues. Though maybe making it thread-aware could lead to other
 enhancements (and lots of trouble).

 Each thread gets it's own view of the cache- trying to allow instance
 sharing across threads means that thread 1 (which is doing an edit that
 will ultimately fail) is screwing with the data thread 2 (which is doing a
 simple view rendering) uses, meaning bad mojo... and if someone suggests
 locking to try and duck that, I wedgie them, that's even worse mojo ;)

 As I understand it the storage is part of the class object, which is
 global, no? So currently the patch does not behave like this and this will
 need to be addressed.

-- 
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] #17: Metasystem optimization: Share select_related in memory

[Django]

#17: Metasystem optimization: Share select_related in memory
---+
  Reporter:  adrian| Owner:  PhiR   

Status:  assigned  | Milestone: 

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

Resolution:|  Keywords:  feature 
caching
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  1 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 was talking with PhiR in the IRC channel. [http://www.guccishopping.com/
 ed hardy] I would just like to mention two issues: 1. Thread safety -- for
 python > 2.3 we can wrap the storage in threading.local to avoid issues.
 Though maybe making it thread-aware could lead to other enhancements (and
 lots of trouble).

 Each thread gets it's own view of the cache- trying to allow instance
 sharing across threads means that thread 1 (which is doing an edit that
 will ultimately fail) is screwing with the data thread 2 (which is doing a
 simple view rendering) uses, meaning bad mojo... and if someone suggests
 locking to try and duck that, I wedgie them, that's even worse mojo ;)

 As I understand it the storage is part of the class object, which is
 global, no? So currently the patch does not behave like this and this will
 need to be addressed.

-- 
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] #13: Related objects interface should be tighter (edit_inline)

[Django]

#13: Related objects interface should be tighter (edit_inline)
---+
  Reporter:  adrian| Owner:  barbuza
   
Status:  reopened  | Milestone: 
   
 Component:  django.contrib.admin  |   Version:  SVN
   
Resolution:|  Keywords:  nfa-someday 
nfa-changelist
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 Who do I need to talif I want

 to help implement this?
 That would be me. I go by "coderanger" on IRC, and can be found there most

 of the time.A (simple) ticket can be attached

 to an (aggregate) ticket:
 •to a milestone, as it is done now (display in the combobox only available

 milestone tickets)
 •to a master ticket (display in that combobox only available master

 tickets) It remains to be seen if an

 (aggregate) ticket could itself be attached to another (aggregate)

 ticket... A master ticket attached to a milestone makes sense.
 [http://www.cc1c.com/ micro bikini]You're quite right - reworking the
 modules and

 breaking down the tickets into different types seems a good solution, and

 more flexible than simply 'bolting on' master tickets.
 Master tickets should be
  children of Milestone tickets, but not other

 Master tickets.

-- 
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] #13: Related objects interface should be tighter (edit_inline)

[Django]

#13: Related objects interface should be tighter (edit_inline)
---+
  Reporter:  adrian| Owner:  barbuza
   
Status:  reopened  | Milestone: 
   
 Component:  django.contrib.admin  |   Version:  SVN
   
Resolution:|  Keywords:  nfa-someday 
nfa-changelist
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 Who do I need to talk to if I want

 to help implement this?
 That would be me. I go by "coderanger" on IRC, and can be found there most

 of the time.
 [http://www.gln2008.com/ ed hardy]A (simple) ticket can be attached

 to an (aggregate) ticket:
 •to a milestone, as it is done now (display in the combobox only available

 milestone tickets)
 •to a master ticket (display in that combobox only available master

 tickets)
 It remains to be seen if an

 (aggregate) ticket could itself be attached to another (aggregate)

 ticket... A master ticket attached to a milestone makes seYou're quite
 right - reworking the modules and

 breaking down the tickets into different types seems a good solution, and

 more flexible than simply 'bolting on' master tickets.
 Master tickets should be children of Milestone tickets, but not other

 Master tickets.

-- 
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] #13: Related objects interface should be tighter (edit_inline)

[Django]

#13: Related objects interface should be tighter (edit_inline)
---+
  Reporter:  adrian| Owner:  barbuza
   
Status:  reopened  | Milestone: 
   
 Component:  django.contrib.admin  |   Version:  SVN
   
Resolution:|  Keywords:  nfa-someday 
nfa-changelist
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 Who do I need to talk to [http://www.guccishopping.com/ ed hardy]if I want

 to help implement this?
 That would be me. I go by "coderanger" on IRC, and can be found there most

 of the time.
 A (simple) ticket can be attached

 to an (aggregate) ticket:
 •to a milestone, as it is done now (display in the combobox only available

 milestone tickets)
 •to a master ticket (display in that combobox only available master

 tickets)
 It remains to be seen if an

 (aggregate) ticket could itself be attached to another (aggregate)

 ticket... A master ticket attached to a milestone makes sense.
 You're quite right - reworking the modules and

 breaking down the tickets into different types seems a good solution, and

 more flexible than simply 'bolting on' master tickets.
 Master tickets should be children of Milestone tickets, but not other

 Master tickets.

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