Re: [Django] #12399: memcached not working as expected when setting keys with a timeout > 30 days

[Django]

#12399: memcached not working as expected when setting keys with a timeout > 30
days
---+
  Reporter:  houdinihound  | Owner:  nobody 
Status:  new   | Milestone: 
 Component:  Cache system  |   Version:  1.1
Resolution:|  Keywords:  cached_db session memcached
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by houdinihound):

 gciotta's patch seems to be a much better solution to this issue.  Please
 ignore patch1.diff - too limited in scope.

-- 
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] #11877: Document that request.get_host() fails when behind multiple reverse proxies

[Django]

#11877: Document that request.get_host() fails when behind multiple reverse 
proxies
+---
  Reporter:  tomevans222| Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.0 
Resolution: |  Keywords:  proxy forwarded get_host
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by arnav):

  * has_patch:  0 => 1

Comment:

 documentation patch 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] #12616: dev server should not override directory listing of static media

[Django]

#12616: dev server should not override directory listing of static media
-+--
  Reporter:  ahebert | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.1   
Resolution:  worksforme  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by ahebert):

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

Comment:

 Added a patch that fixes the 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.

[Django] #12616: dev server should not override directory listing of static media

[Django]

#12616: dev server should not override directory listing of static media
+---
 Reporter:  ahebert |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.1   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 The dev server can serve the static admin media file from a project
 directory, which is likely if you want to modify the look of the admin.
 When set to do so with directory listing allowed by
 {{{'show_indexes':True}}}, an attempt to navigate the directory structure
 from a browser will result in a 401 "Permission Denied" page, which is
 broken when the same settings allow directory navigation of non-admin
 media.

 An example to reproduce the problem has settings:
 {{{
 SITE_ROOT = os.path.dirname(os.path.realpath(__file__))
 MEDIA_ROOT = os.path.join(SITE_ROOT,'media')
 MEDIA_URL='/media/'
 ADMIN_MEDIA_PREFIX='/media/admin/'
 }}}

 and a urlconf containing:

 {{{
 (r'^%s(?P.*)$' % settings.MEDIA_URL[1:],
 'django.views.static.serve', {'document_root': settings.MEDIA_ROOT,
 'show_indexes': True}),
 }}}

 and running the server with the command

 {{{
 ./manage.py runserver --adminmedia=media/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] #12102: Relative PYTHONPATH in the docs

[Django]

#12102: Relative PYTHONPATH in the docs
+---
  Reporter:  alexkon| Owner: 
Status:  new| Milestone:  1.2
 Component:  Documentation  |   Version:  1.1
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by arnav):

  * has_patch:  0 => 1

Comment:

 Patch 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] #12614: ManyToManyField generates inconsistent table/column names

[Django]

#12614: ManyToManyField generates inconsistent table/column names
---+
  Reporter:  Nick Retallack   | Owner: 
 nobody
Status:  closed| Milestone: 
   
 Component:  Database layer (models, ORM)  |   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
  * resolution:  => invalid

Comment:

 Using "other_table_name_table_name" doesn't work because you can have two
 m2m fields onto the related table. If you used
 "other_table_name_table_name" as the m2m table name, the intermediate
 table name would be ambiguous. You need to use the property name to
 compose the m2m table name to avoid this ambiguity.

 As Ramiro said - if you need control over the m2m table name, use the
 db_table option on the m2m field.

-- 
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] #12614: ManyToManyField generates inconsistent table/column names

[Django]

#12614: ManyToManyField generates inconsistent table/column names
---+
  Reporter:  Nick Retallack   | Owner: 
 nobody
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version: 
 1.1   
Resolution:|  Keywords: 
   
 Stage:  Unreviewed| Has_patch: 
 0 
Needs_docs:  0 |   Needs_tests: 
 0 
Needs_better_patch:  0 |  
---+
Comment (by Nick Retallack ):

 Replying to [comment:2 ramiro]:
 > It is generating those names as it is described in the documentation:
 [http://docs.djangoproject.com/en/1.1/ref/models/fields/#id1 automatic
 intermediate m2m table name] and FK fields column names
 http://docs.djangoproject.com/en/1.1/ref/models/fields/#database-
 representation.

 Actually it's not consistent with the documentation you linked to.  The
 "DATABASE REPRESENTATION" paragraph says "By default, this table name is
 generated using the names of the two tables being joined. "  However, the
 table is actually being named after a table and a property, not two
 tables.

 Also, regardless of what the documentation says, do you think the current
 default behavior is sane?  Think about this from the perspective of
 someone who has to use this database later on, without the django ORM.  It
 seems silly that "property_name", "modelname", and "othermodelname" all
 appear in the generated schema, despite having nothing to do with the
 database structure.

-- 
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] #11303: changed_data wrong work with BooleanField

[Django]

#11303: changed_data wrong work with BooleanField
---+
  Reporter:  oduvan| Owner:  nobody
Status:  new   | Milestone:
 Component:  Forms |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by margieroginski):

 I've just encountered this problem again, but in a slightly different way.
 I have a !BooleanField in my model and it is has value False.  When I
 create the corresponding !BooleanField in my modelForm, the initial value
 sent out in the hidden input is '0'.  In other words, request.POST
 contains

 {{{
 u'initial-requireResultOnClose': [u'0']
 }}}

 If I then check the checkbox, the field comes back with 'on', like this:
 {{{
 u'requireResultOnClose': [u'on']
 }}}

 The _has_changed() method for !CheckBoxInput() returns True when it
 compares u'0' and u'on' due to the fact that bool(u'0') is True, but it
 should really return False.

 I have changed _has_changed() for !CheckBoxInput() to look like this,
 which seems to work form my cases:

 def _has_changed(self, initial, data):
 # Sometimes data or initial could be None or u'' which should be
 the
 # same thing as False.
 if initial in ('False', '0'):
 initial = False
 return bool(initial) != bool(data)

 In fields.py, !BooleanField's clean() method does something similar, so
 I'm hoping this is the right direction.  In general it seems very
 difficult to compare all these values such as False, 'False', u'0', u'1',
 True, 'True' and get it right.  The hidden initial stuff adds an extra
 complication due to the fact that the hidden input is rendered through the
 hidden_widget() widget, which uses different values than those used by the
 !CheckBoxInput.  IE, in the !CheckBoxInput widget when data is posted, the
 value 'on' indicates it is checked and no input at all in the post data
 indicates it is unchecked.  But when using the !CheckBoxInput's
 hidden_widget() widget, you see values u'0' and u'1', and it seems that
 these are really not taken into account in the current code base, probably
 due to the fact that few people are using the show_hidden_initial
 functionality.

-- 
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] #12615: Broken queryset indexing with postgresql_psycopg2 with custom through model

[Django]

#12615: Broken queryset indexing with postgresql_psycopg2 with custom through 
model
---+
 Reporter:  yxven  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1-beta-1
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 If you start a new project and setup a database using postgresl_psycopg2
 (I know sqlite3 works. I dunno about others), and create a model that uses
 a custom through model, queryset indexing will be broken when accessed
 through that relationship.

 I've attached a simplified models.py and tests.py to explain and
 demonstrate 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] #12614: ManyToManyField generates inconsistent table/column names

[Django]

#12614: ManyToManyField generates inconsistent table/column names
---+
  Reporter:  Nick Retallack   | Owner: 
 nobody
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version: 
 1.1   
Resolution:|  Keywords: 
   
 Stage:  Unreviewed| Has_patch: 
 0 
Needs_docs:  0 |   Needs_tests: 
 0 
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 Replying to [ticket:12614 Nick Retallack ]:
 > If you override the table name in your models and then generate a table
 with a ManyToManyField, the results look horribly inconsistent.

 It is generating those names as it is described in the documentation:
 [http://docs.djangoproject.com/en/1.1/ref/models/fields/#id1 automatic
 intermediate m2m table name] and FK fields column names
 http://docs.djangoproject.com/en/1.1/ref/models/fields/#database-
 representation.

 If you want to control the name of the table you can use the `db_table`
 field option as
 
[http://docs.djangoproject.com/en/1.1/ref/models/fields/#django.db.models.ManyToManyField.db_table
 documented].

 For controlling the FK column names you will need to use a `through` as
 you have discovered or crate the table by hand then you will have total
 control over its naming.

-- 
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] #12614: ManyToManyField generates inconsistent table/column names

[Django]

#12614: ManyToManyField generates inconsistent table/column names
---+
  Reporter:  Nick Retallack   | Owner: 
 nobody
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version: 
 1.1   
Resolution:|  Keywords: 
   
 Stage:  Unreviewed| Has_patch: 
 0 
Needs_docs:  0 |   Needs_tests: 
 0 
Needs_better_patch:  0 |  
---+
Changes (by Nick Retallack ):

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

Comment:

 Oops, typo here:
 {{{
 ### ./manage.py sql column # as sqlite3
 }}}
 Should have been
 {{{
 ### ./manage.py sql module_name # as sqlite3
 }}}
 to be consistent with the annotation for the previous code snippet.
 Shouldn't affect 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.

[Django] #12614: ManyToManyField generates inconsistent table/column names

[Django]

#12614: ManyToManyField generates inconsistent table/column names
--+-
 Reporter:  Nick Retallack   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 If you override the table name in your models and then generate a table
 with a ManyToManyField, the results look horribly inconsistent.  Take a
 look:


 {{{
 ### module_name/models.py
 from django.db import models

 # Create your models here.
 class ModelName(models.Model):
 class Meta:
 db_table = "table_name"

 class OtherModelName(models.Model):
 class Meta:
 db_table = "other_table_name"
 property_name = models.ManyToManyField(ModelName)

 }}}


 {{{
 ### ./manage.py sql column # as sqlite3
 BEGIN;
 CREATE TABLE "table_name" (
 "id" integer NOT NULL PRIMARY KEY
 )
 ;
 CREATE TABLE "other_table_name" (
 "id" integer NOT NULL PRIMARY KEY
 )
 ;
 CREATE TABLE "other_table_name_property_name" (
 "id" integer NOT NULL PRIMARY KEY,
 "othermodelname_id" integer NOT NULL REFERENCES "other_table_name"
 ("id"),
 "modelname_id" integer NOT NULL REFERENCES "table_name" ("id"),
 UNIQUE ("othermodelname_id", "modelname_id")
 )
 ;
 COMMIT;
 }}}

 This is especially annoying if you're working with a legacy database that
 already has a consistent naming scheme, or if you care at all what your
 tables and columns are named.  You would have to add a "through" option to
 every ManyToManyField and specify that table manually, since Django
 insists on using class names and property names in the table definition
 when it generates it itself.

 In my opinion, class names and property names should never be used in
 database table/column definitions.  Only the real table names should be
 used.  In specific, the many to many table should have looked like this:


 {{{
 CREATE TABLE "other_table_name_table_name" (
 "id" integer NOT NULL PRIMARY KEY,
 "other_table_name_id" integer NOT NULL REFERENCES "other_table_name"
 ("id"),
 "table_name_id" integer NOT NULL REFERENCES "table_name" ("id"),
 UNIQUE ("other_table_name_id", "table_name_id")
 );
 }}}

-- 
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] #12613: phone2numeric doesn't convert the letters 'Q' or 'Z'.

[Django]

#12613: phone2numeric doesn't convert the letters 'Q' or 'Z'.
---+
   Reporter:  gabrielhurley|Owner:  nobody
 Status:  new  |Milestone:  1.2   
  Component:  Template system  |  Version:  1.1   
   Keywords:  phone2numeric|Stage:  Unreviewed
  Has_patch:  1|   Needs_docs:  0 
Needs_tests:  0|   Needs_better_patch:  0 
---+
 Discussion on the django developers group here:
 http://groups.google.com/group/django-
 developers/browse_frm/thread/49ee1863efa59901

 There doesn't seem to be any good reason for the phone2numeric function
 not to convert the letters Q or Z, so I've created a small patch that
 remedies that.

 Also, for readability's sake the patch puts the dictionary of letter-to-
 number conversions in alphabetical order.

-- 
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] #3371: Filter to get dict's value by key name

[Django]

#3371: Filter to get dict's value by key name
-+--
  Reporter:  Alex Dedul  | Owner:  nobody   
   
Status:  closed  | Milestone:   
   
 Component:  Template system |   Version:  SVN  
   
Resolution:  wontfix |  Keywords:  template filter 
dict key
 Stage:  Design decision needed  | Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Comment (by slacy):

 Instead of adding a special filter for this case, I think it would make
 sense to amend the template variable processing in general to have an
 extra step:

 * Dictionary lookup. Example: foo["bar"]
 * Attribute lookup. Example: foo.bar
 * Method call. Example: foo.bar()
 * List-index lookup. Example: foo[bar]
 * '''Dictionary/List lookup by reference. Example:
 foo[resolve_variable("bar")]'''

-- 
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] #12612: SQLite3 executemany() exception handling is too broad

[Django]

#12612: SQLite3 executemany() exception handling is too broad
---+
  Reporter:  Niels   | Owner:  nobody 
   
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.2-alpha  
   
Resolution:|  Keywords:  
sqlite,sqlite3
 Stage:  Unreviewed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by Niels ):

  * needs_better_patch:  => 0
  * summary:  SQLite3 executemany() method catches too much exceptions =>
  SQLite3 executemany() exception handling is too
  broad
  * 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] #12612: SQLite3 executemany() method catches too much exceptions

[Django]

#12612: SQLite3 executemany() method catches too much exceptions
--+-
 Reporter:  Niels   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2-alpha 
 Keywords:  sqlite,sqlite3|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 In SQLiteCursorWrapper.executemany()
 
(http://code.djangoproject.com/browser/django/trunk/django/db/backends/sqlite3/base.py#L191)
 convert_query (line 199) is called, but if you have an extra (accidental)
 %s in your query the
 replacement of '%s' by ? will raise an exception (TypeError: not enough
 arguments for format string) which is then
 caught and ignored by except(IndexError,TypeError) at line 195.

 None will be returned and whoever is calling executemany will be left
 wondering why nothing happened. This bug basically causes bad input to be
 ignored instead of raising an exception.

-- 
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] r12228 - django/trunk/django/contrib/gis/utils

[noreply]

Author: jbronn
Date: 2010-01-14 11:43:46 -0600 (Thu, 14 Jan 2010)
New Revision: 12228

Modified:
   django/trunk/django/contrib/gis/utils/__init__.py
   django/trunk/django/contrib/gis/utils/srs.py
Log:
Fixed #12591 -- Renamed `add_postgis_srs` to `add_srs_entry` (keeping 
backwards-compatible alias), added `database` keyword for multi-db, removed 
deprecated `SpatialBackend` references; no longer use `get_or_create` and look 
for existing entry based on SRID value. 


Modified: django/trunk/django/contrib/gis/utils/__init__.py
===
--- django/trunk/django/contrib/gis/utils/__init__.py   2010-01-14 17:04:53 UTC 
(rev 12227)
+++ django/trunk/django/contrib/gis/utils/__init__.py   2010-01-14 17:43:46 UTC 
(rev 12228)
@@ -6,7 +6,7 @@
 if HAS_GDAL:
 from django.contrib.gis.utils.ogrinfo import ogrinfo, sample
 from django.contrib.gis.utils.ogrinspect import mapping, ogrinspect
-from django.contrib.gis.utils.srs import add_postgis_srs
+from django.contrib.gis.utils.srs import add_postgis_srs, add_srs_entry
 try:
 # LayerMapping requires DJANGO_SETTINGS_MODULE to be set, 
 # so this needs to be in try/except.

Modified: django/trunk/django/contrib/gis/utils/srs.py
===
--- django/trunk/django/contrib/gis/utils/srs.py2010-01-14 17:04:53 UTC 
(rev 12227)
+++ django/trunk/django/contrib/gis/utils/srs.py2010-01-14 17:43:46 UTC 
(rev 12228)
@@ -1,49 +1,77 @@
-def add_postgis_srs(srs, auth_name='EPSG', auth_srid=None, ref_sys_name=None):
+from django.contrib.gis.gdal import SpatialReference
+from django.db import connections, DEFAULT_DB_ALIAS
+
+def add_srs_entry(srs, auth_name='EPSG', auth_srid=None, ref_sys_name=None,
+  database=DEFAULT_DB_ALIAS):
 """
-This function takes a GDAL SpatialReference system and adds its
-information to the PostGIS `spatial_ref_sys` table -- enabling
-spatial transformations with PostGIS.  This is handy for adding
-spatial reference systems not included by default with PostGIS.
-For example, the following adds the so-called "Google Maps Mercator
-Projection" (available in GDAL 1.5):
+This function takes a GDAL SpatialReference system and adds its information
+to the `spatial_ref_sys` table of the spatial backend.  Doing this enables
+database-level spatial transformations for the backend.  Thus, this utility
+is useful for adding spatial reference systems not included by default with
+the backend -- for example, the so-called "Google Maps Mercator Projection"
+is excluded in PostGIS 1.3 and below, and the following adds it to the
+`spatial_ref_sys` table:
 
->>> add_postgis_srs(SpatialReference(900913))
+>>> from django.contrib.gis.utils import add_srs_entry
+>>> add_srs_entry(900913)
 
 Keyword Arguments:
- auth_name: This keyword may be customized with the value of the
-`auth_name` field.  Defaults to 'EPSG'.
+ auth_name:
+   This keyword may be customized with the value of the `auth_name` field.
+   Defaults to 'EPSG'.
 
- auth_srid: This keyword may be customized with the value of the
-`auth_srid` field.  Defaults to the SRID determined
-by GDAL.
+ auth_srid:
+   This keyword may be customized with the value of the `auth_srid` field.
+   Defaults to the SRID determined by GDAL.
 
- ref_sys_name: For SpatiaLite users only, sets the value of the
-   the `ref_sys_name` field.  Defaults to the name
-   determined by GDAL.
+ ref_sys_name:
+   For SpatiaLite users only, sets the value of the the `ref_sys_name` 
field.
+   Defaults to the name determined by GDAL.
+
+ database:
+  The name of the database connection to use; the default is the value
+  of `django.db.DEFAULT_DB_ALIAS` (at the time of this writing, it's value
+  is 'default').
 """
-from django.contrib.gis.db.backend import SpatialBackend
-from django.contrib.gis.models import SpatialRefSys
-from django.contrib.gis.gdal import SpatialReference
+connection = connections[database]
+if not hasattr(connection.ops, 'spatial_version'):
+raise Exception('The `add_srs_entry` utility only works '
+'with spatial backends.')
+if connection.ops.oracle or connection.ops.mysql:
+raise Exception('This utility does not support the '
+'Oracle or MySQL spatial backends.')
+SpatialRefSys = connection.ops.spatial_ref_sys()
 
-if SpatialBackend.oracle or SpatialBackend.mysql:
-raise Exception('This utility not supported on Oracle or MySQL spatial 
backends.')
-
+# If argument is not a `SpatialReference` instance, use it as parameter
+# to construct a `SpatialReference` instance.
 if not isinstance(srs, SpatialReference):
  

Re: [Django] #9816: ModelForm with only FileField or ImageField can not pass validation

[Django]

#9816: ModelForm with only FileField or ImageField can not pass validation
---+
  Reporter:  ogunes| Owner:  nobody 
Status:  reopened  | Milestone:  1.1
 Component:  Forms |   Version:  1.0
Resolution:|  Keywords:  ModelForm ImageField validation
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by foxwhisper):

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

Comment:

 The reason the form validates in the second example, is because you have
 two fields specified. In the first one, you only have one.

 Django has really messed up weird issues, if u have a list or tuple with
 only 1 entry.. (some people get this problem, others do not. I don't know
 why)

 To fix this, add a comma "," after the first field:

 fields = ('mugshot', )

 That works fine for me

 Regards

 Cal Leeming

-- 
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] #12577: New validation behaviour breaks django.contrib.contenttypes when unique_toghether is used

[Django]

#12577: New validation behaviour breaks django.contrib.contenttypes when
unique_toghether is used
-+--
  Reporter:  raffaele.salm...@gmail.com  | Owner:  nobody
Status:  new | Milestone:
 Component:  Uncategorized   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by raffaele.salm...@gmail.com):

  * has_patch:  0 => 1

Comment:

 ok, tracked what's wrong: new BaseGenericInlineFormSet lacks save_new() to
 set the fk instance.

-- 
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] r12227 - in django/trunk: . django/db/models tests/modeltests/validation

[noreply]

Author: jkocherhans
Date: 2010-01-14 11:04:53 -0600 (Thu, 14 Jan 2010)
New Revision: 12227

Modified:
   django/trunk/AUTHORS
   django/trunk/django/db/models/base.py
   django/trunk/tests/modeltests/validation/test_unique.py
Log:
Fixed #12560. Changed validate_unique to stop checking null primary key values. 
Thanks, Honza Kr?\195?\161l.

Modified: django/trunk/AUTHORS
===
--- django/trunk/AUTHORS2010-01-14 14:55:36 UTC (rev 12226)
+++ django/trunk/AUTHORS2010-01-14 17:04:53 UTC (rev 12227)
@@ -256,7 +256,7 @@
 Gasper Koren
 Martin Kosír 
 Arthur Koziel 
-Honza Kral 
+Honza Král 
 Meir Kriheli 
 Bruce Kroeze 
 krzysiek.paw...@silvermedia.pl

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2010-01-14 14:55:36 UTC (rev 
12226)
+++ django/trunk/django/db/models/base.py   2010-01-14 17:04:53 UTC (rev 
12227)
@@ -715,7 +715,7 @@
 for field_name in unique_check:
 f = self._meta.get_field(field_name)
 lookup_value = getattr(self, f.attname)
-if f.null and lookup_value is None:
+if lookup_value is None:
 # no value, skip the lookup
 continue
 if f.primary_key and not getattr(self, '_adding', False):

Modified: django/trunk/tests/modeltests/validation/test_unique.py
===
--- django/trunk/tests/modeltests/validation/test_unique.py 2010-01-14 
14:55:36 UTC (rev 12226)
+++ django/trunk/tests/modeltests/validation/test_unique.py 2010-01-14 
17:04:53 UTC (rev 12227)
@@ -43,18 +43,26 @@
 settings.DEBUG = self._old_debug
 super(PerformUniqueChecksTest, self).tearDown()
 
-def test_primary_key_unique_check_performed_when_adding(self):
-"""Regression test for #12132"""
-l = len(connection.queries)
+def 
test_primary_key_unique_check_not_performed_when_adding_and_pk_not_specified(self):
+# Regression test for #12560
+query_count = len(connection.queries)
 mtv = ModelToValidate(number=10, name='Some Name')
 setattr(mtv, '_adding', True)
 mtv.full_clean()
-self.assertEqual(l+1, len(connection.queries))
+self.assertEqual(query_count, len(connection.queries))
 
+def 
test_primary_key_unique_check_performed_when_adding_and_pk_specified(self):
+# Regression test for #12560
+query_count = len(connection.queries)
+mtv = ModelToValidate(number=10, name='Some Name', id=123)
+setattr(mtv, '_adding', True)
+mtv.full_clean()
+self.assertEqual(query_count + 1, len(connection.queries))
+
 def test_primary_key_unique_check_not_performed_when_not_adding(self):
-"""Regression test for #12132"""
-l = len(connection.queries)
+# Regression test for #12132
+query_count= len(connection.queries)
 mtv = ModelToValidate(number=10, name='Some Name')
 mtv.full_clean()
-self.assertEqual(l, len(connection.queries))
+self.assertEqual(query_count, len(connection.queries))
 

-- 
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] #12559: Wrong SQL in M2M fields

[Django]

#12559: Wrong SQL in M2M fields
---+
  Reporter:  anonymous | Owner:  nobody   
Status:  closed| Milestone:  1.2  
 Component:  Database layer (models, ORM)  |   Version:  1.2-alpha
Resolution:  duplicate |  Keywords:   
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 I'm fairly certain this is a duplicate of #12386, which I just fixed in
 [12226]. Please reopen if I am mistaken.

-- 
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] #12560: Unique validation should not check for null atuo-assigned PK

[Django]

#12560: Unique validation should not check for null atuo-assigned PK
+---
  Reporter:  kmtracey   | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by wkornewald):

 Any progress? This is just a one-line fix. Maybe it should be limited to
 primary_key fields, I don't know.

-- 
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] r12226 - in django/trunk: django/db/models/fields tests/modeltests/model_package

[noreply]

Author: russellm
Date: 2010-01-14 08:55:36 -0600 (Thu, 14 Jan 2010)
New Revision: 12226

Modified:
   django/trunk/django/db/models/fields/related.py
   django/trunk/tests/modeltests/model_package/tests.py
Log:
Fixed #12386 -- Corrected the column names produced for autogenerated m2m 
tables when the related table is specified as a dot-separated string. Thanks to 
ldevesine for the report and simonb for the extra test case.

Modified: django/trunk/django/db/models/fields/related.py
===
--- django/trunk/django/db/models/fields/related.py 2010-01-14 11:12:24 UTC 
(rev 12225)
+++ django/trunk/django/db/models/fields/related.py 2010-01-14 14:55:36 UTC 
(rev 12226)
@@ -881,8 +881,8 @@
 from django.db import models
 managed = True
 if isinstance(field.rel.to, basestring) and field.rel.to != 
RECURSIVE_RELATIONSHIP_CONSTANT:
-to = field.rel.to
 to_model = field.rel.to
+to = to_model.split('.')[-1]
 def set_managed(field, model, cls):
 field.rel.through._meta.managed = model._meta.managed or 
cls._meta.managed
 add_lazy_relation(klass, field, to_model, set_managed)

Modified: django/trunk/tests/modeltests/model_package/tests.py
===
--- django/trunk/tests/modeltests/model_package/tests.py2010-01-14 
11:12:24 UTC (rev 12225)
+++ django/trunk/tests/modeltests/model_package/tests.py2010-01-14 
14:55:36 UTC (rev 12226)
@@ -50,6 +50,31 @@
 >>> ad.publications.count()
 1
 
+# Regression for #12386 - field names on the autogenerated intermediate class
+# that are specified as dotted strings don't retain any path component for the
+# field or column name
+
+>>> Article.publications.through._meta.fields[1].name
+'article'
+
+>>> Article.publications.through._meta.fields[1].get_attname_column()
+('article_id', 'article_id')
+
+>>> Article.publications.through._meta.fields[2].name
+'publication'
+
+>>> Article.publications.through._meta.fields[2].get_attname_column()
+('publication_id', 'publication_id')
+
+>>> Article._meta.get_field('publications').m2m_db_table()
+'model_package_article_publications'
+
+>>> Article._meta.get_field('publications').m2m_column_name()
+'article_id'
+
+>>> Article._meta.get_field('publications').m2m_reverse_name()
+'publication_id'
+
 """}
 
 

-- 
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] #12610: Fixture loading is interfered by signal handlers

[Django]

#12610: Fixture loading is interfered by signal handlers
-+--
  Reporter:  jtiai   | Owner:  nobody
Status:  new | Milestone:
 Component:  django-admin.py |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Design decision needed
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 There is already a hook to check for this - data saved during a fixture
 load is loaded 'raw', and the 'raw' argument is passed to the pre/post
 save handlers. If you modify your pre/post save handlers to do nothing in
 the case of a raw save, you should be able to load fixtures without the
 problems you describe.

 There might be an argument to be made that raw saves should disable
 signals completely - after all, the purpose of raw save is to prevent any
 clever 'on save' logic from being executed, and excluding signals from
 that process would make some sense. However, this could also be considered
 a backwards incompatibility. Marking DDN until we make that decision. Feel
 free to raise this on django-dev if you want to promote the idea.

-- 
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] #12610: Fixture loading is interfered by signal handlers

[Django]

#12610: Fixture loading is interfered by signal handlers
-+--
 Reporter:  jtiai|   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django-admin.py  | Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 If profiles are setup as documented using unique foreignkeyand post_save
 signal it's impossible to import both as a fixture since creating user
 data creates (empty) profile that conflicts with  fixtures to be loaded.

 Specially it's inconvenient in testing. There should be option to disable
 or run signals deferred while loading fixture data.

-- 
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] #11296: Delete confirmation page in Admin displays circular references.

[Django]

#11296: Delete confirmation page in Admin displays circular references.
---+
  Reporter:  benreynwar| Owner:  carljm
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by carljm):

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

Comment:

 This is fixed in the latest patch on #6191.

-- 
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] #6191: Admin delete view doesn't show all items in some circumstances

[Django]

#6191: Admin delete view doesn't show all items in some circumstances
---+
  Reporter:  nicklane  | Owner:  carljm 
Status:  new   | Milestone:  1.2
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords:  nfa-someday
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by carljm):

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

-- 
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] #8528: Admin list_filter doesn't respect null=True

[Django]

#8528: Admin list_filter doesn't respect null=True
---+
  Reporter:  StevenPotter  | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.0-beta-1
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by danfairs):

 * cc: danfairs (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.

[Django] #12609: FAQ needs updating for advise on which Django version to use

[Django]

#12609: FAQ needs updating for advise on which Django version to use
---+
 Reporter:  shanx  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 The FAQ at http://docs.djangoproject.com/en/dev/faq/install/ states:

 {{{
 Should I use the official version or development version?
 The Django developers improve Django every day and are pretty good about
 not checking in broken code. We use the development code (from the
 Subversion repository) directly on our servers, so we consider it stable.
 With that in mind, we recommend that you use the latest development code,
 because it generally contains more features and fewer bugs than the
 “official” releases.
 }}}

 Now that Django has a release schedule, I would imagine it to be advisable
 for the general public to use Django releases by default and only if they
 want the cutting edge should the follow  trunk (or a branch for that
 matter). See the patch for my proposal on updating the 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.

Re: [Django] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
---+
  Reporter:  Honza_Kral| Owner:  jkocherhans
 
Status:  assigned  | Milestone:  1.2
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  nfa-someday 
list_filter filterspec nfa-changelist ep2008
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Changes (by danfairs):

 * cc: danfairs (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.

[Changeset] r12225 - django/trunk/django/contrib/auth

[noreply]

Author: jezdez
Date: 2010-01-14 05:12:24 -0600 (Thu, 14 Jan 2010)
New Revision: 12225

Modified:
   django/trunk/django/contrib/auth/admin.py
Log:
Fixed #12606 - Removed stray print statement. Thanks, Sean Brant.

Modified: django/trunk/django/contrib/auth/admin.py
===
--- django/trunk/django/contrib/auth/admin.py   2010-01-13 23:54:07 UTC (rev 
12224)
+++ django/trunk/django/contrib/auth/admin.py   2010-01-14 11:12:24 UTC (rev 
12225)
@@ -116,7 +116,6 @@
 
 fieldsets = [(None, {'fields': form.base_fields.keys()})]
 adminForm = admin.helpers.AdminForm(form, fieldsets, {})
-print adminForm, form
 
 return render_to_response(self.change_user_password_template or 
'admin/auth/user/change_password.html', {
 'title': _('Change password: %s') % escape(user.username),

-- 
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] #9200: Add a session based form wizard

[Django]

#9200: Add a session based form wizard
---+
  Reporter:  ddurham   | Owner:  nobody 
 
Status:  new   | Milestone:  1.2
 
 Component:  django.contrib.formtools  |   Version:  SVN
 
Resolution:|  Keywords:  session wizard 
forms
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by jezdez):

  * stage:  Design decision needed => Accepted
  * milestone:  => 1.2

-- 
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] #12608: Inconsistent results from values and values_list when using annotate

[Django]

#12608: Inconsistent results from values and values_list when using annotate
---+
  Reporter:  mattmcc   | Owner:  nobody 
 
Status:  new   | Milestone:  1.2
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:|  Keywords:  
values_list annotate
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by mattmcc):

  * keywords:  => values_list annotate
  * needs_better_patch:  => 0
  * component:  Uncategorized => Database layer (models, ORM)
  * 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] #12608: Inconsistent results from values and values_list when using annotate

[Django]

#12608: Inconsistent results from values and values_list when using annotate
---+
 Reporter:  mattmcc|   Owner:  nobody
   Status:  new|   Milestone:  1.2   
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 To group users by email and get a count, one might do:
 {{{
 >>> User.objects.values('email').annotate(Count('email'))
 [{'email__count': 2, 'email': u'u...@example.com'}]
 }}}
 However, values_list discards the annotated value:
 {{{
 >>> User.objects.values_list('email').annotate(Count('email'))
 [(u'u...@example.com',)]
 }}}

-- 
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] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
-+--
  Reporter:  etianen | Owner:  nobody
Status:  new | Milestone:  1.2   
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by wdoekes):

 (Although I must add that we do not use the admin interface for users, so
 I cannot confirm or deny that it solves issues in the admin interface.)

-- 
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] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
-+--
  Reporter:  etianen | Owner:  nobody
Status:  new | Milestone:  1.2   
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by wdoekes):

 * cc: walter+dja...@wjd.nu (added)

Comment:

 We've successfully employed the workaround as found in
 osso.core.management.__init__.py on django-1.1.

 Regards,
 Walter Doekes
 OSSO B.V.

-- 
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] #12386: Automatic ManyToMany Fields in models defined in packages use invalid column names

[Django]

#12386: Automatic ManyToMany Fields in models defined in packages use invalid
column names
---+
  Reporter:  ldevesine | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by simonb):

 * cc: bno...@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.