Re: [Django] #12036: GIS layermapping utility fails to import linestrings

[Django]

#12036: GIS layermapping utility fails to import linestrings
-+--
  Reporter:  elpaso66| Owner:  nobody
Status:  closed  | Milestone:
 Component:  GIS |   Version:  1.1   
Resolution:  fixed   |  Keywords:  gis import
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

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

Comment:

 Because `gtype` is really an `OGRGeomType` instance, equality testing with
 strings works (e.g., `OGRGeomType('POINT') == 'Point'`).  Regardless, for
 other reasons it was changed to a string comparison in r11742 when 3D
 support was added; I also clarified that exception to differentiate
 between the model field type and what was found on the layer, similar to
 what you put in the summary here.

 While I agree there was a problem with the error message, the
 `LayerMapping` utility has always been able to import `LineString`
 geometries, it's done in the test suite in multiple places.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12231: The project path is incorrectly build, it wipe the namespace

[Django]

#12231: The project path is incorrectly build, it wipe the namespace
-+--
  Reporter:  mleduc  | Owner:  nobody 
Status:  new | Milestone:  1.2
 Component:  Core framework  |   Version:  SVN
Resolution:  |  Keywords:  package
 Stage:  Unreviewed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

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

Old description:

> If by example your django is in an egg like
>
> my.site.project
>
> If you call the django core execution manager with:
>
> mod = __import__('my.site.project')
> django.core.management.execute_manager(mod)
>
> Your project will not be found cause the django core is declaring the
> main DJANGO_SETTINGS_MODULE with:
>
> django.core.management.__init__:
> ...
> project_directory, settings_filename = os.path.split(p)
> if project_directory == os.curdir or not project_directory:
>project_directory = os.getcwd()
> project_name = os.path.basename(project_directory)
> ...
> os.environ['DJANGO_SETTINGS_MODULE = '%s.%s' % (project_name,
> settings_name)
> ...
>
> The project_name variable represent only the first level of the project
> egg. It could not work with a multilevel package and we now have to use
> the variable 'original_settings_path' which is just optional.
>
> The solution maybe to use the special __package__ variable of the
> settings_mod module.
>
> I attach a patch with this ticket whick correct this problem.

New description:

 If by example your django is in an egg like
 {{{
 my.site.project
 }}}
 If you call the django core execution manager with:
 {{{
 mod = __import__('my.site.project')
 django.core.management.execute_manager(mod)
 }}}
 Your project will not be found cause the django core is declaring the main
 DJANGO_SETTINGS_MODULE with:

 django.core.management.__init__:
 {{{
 ...
 project_directory, settings_filename = os.path.split(p)
 if project_directory == os.curdir or not project_directory:
project_directory = os.getcwd()
 project_name = os.path.basename(project_directory)
 ...
 os.environ['DJANGO_SETTINGS_MODULE = '%s.%s' % (project_name,
 settings_name)
 ...
 }}}
 The project_name variable represent only the first level of the project
 egg. It could not work with a multilevel package and we now have to use
 the variable 'original_settings_path' which is just optional.

 The solution maybe to use the special __package__ variable of the
 settings_mod module.

 I attach a patch with this ticket whick correct this problem.

Comment:

 Please use preview.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

[Django] #12231: The project path is incorrectly build, it wipe the namespace

[Django]

#12231: The project path is incorrectly build, it wipe the namespace
+---
 Reporter:  mleduc  |   Owner:  nobody
   Status:  new |   Milestone:  1.2   
Component:  Core framework  | Version:  SVN   
 Keywords:  package |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 If by example your django is in an egg like

 my.site.project

 If you call the django core execution manager with:

 mod = __import__('my.site.project')
 django.core.management.execute_manager(mod)

 Your project will not be found cause the django core is declaring the main
 DJANGO_SETTINGS_MODULE with:

 django.core.management.__init__:
 ...
 project_directory, settings_filename = os.path.split(p)
 if project_directory == os.curdir or not project_directory:
project_directory = os.getcwd()
 project_name = os.path.basename(project_directory)
 ...
 os.environ['DJANGO_SETTINGS_MODULE = '%s.%s' % (project_name,
 settings_name)
 ...

 The project_name variable represent only the first level of the project
 egg. It could not work with a multilevel package and we now have to use
 the variable 'original_settings_path' which is just optional.

 The solution maybe to use the special __package__ variable of the
 settings_mod module.

 I attach a patch with this ticket whick correct this problem.

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

--

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

[Django] #12230: to_locale not working with sr_Latn

[Django]

#12230: to_locale not working with sr_Latn
--+-
 Reporter:  janos |   Owner:  nobody
   Status:  new   |   Milestone:  1.2   
Component:  Internationalization  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 There is a bug in function to_locale in
 django/utils/translation/trans_real.py when trying to get locale for sr-
 latn language.


 {{{
 In [1]: from django.utils.translation import to_locale

 In [2]: to_locale('sr-latn')
 Out[2]: 'sr_LATN'
 }}}


 The output should be 'sr_Latn'. It is an exception that is overlooked when
 new language has been added.
 Because of the wrong caption Django won't recognize 'sr_Latn' folder with
 translations when searching trough 'locale' folders.

 Patch that I have provided solves the problem, but there could be a
 different condition under if.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

[Changeset] r11743 - django/trunk/django/contrib/gis/tests

[noreply]

Author: jbronn
Date: 2009-11-16 20:13:26 -0600 (Mon, 16 Nov 2009)
New Revision: 11743

Modified:
   django/trunk/django/contrib/gis/tests/__init__.py
Log:
As promised, removed the `_DeprecatedTestModule` and its instances.


Modified: django/trunk/django/contrib/gis/tests/__init__.py
===
--- django/trunk/django/contrib/gis/tests/__init__.py   2009-11-16 18:49:00 UTC 
(rev 11742)
+++ django/trunk/django/contrib/gis/tests/__init__.py   2009-11-17 02:13:26 UTC 
(rev 11743)
@@ -169,20 +169,3 @@
 
 # Returning the total failures and errors
 return len(result.failures) + len(result.errors)
-
-# Class for creating a fake module with a run method.  This is for the
-# GEOS and GDAL tests that were moved to their respective modules.
-class _DeprecatedTestModule(object):
-def __init__(self, mod_name):
-self.mod_name = mod_name
-
-def run(self):
-from warnings import warn
-warn('This test module is deprecated because it has moved to ' \
- '`django.contrib.gis.%s.tests` and will disappear in 1.2.' %
- self.mod_name, DeprecationWarning)
-tests = import_module('django.contrib.gis.%s.tests' % self.mod_name)
-tests.run()
-
-test_geos = _DeprecatedTestModule('geos')
-test_gdal = _DeprecatedTestModule('gdal')

--

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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

[Django] #12229: ImageField.save should be documented upfront and obvious

[Django]

#12229: ImageField.save should be documented upfront and obvious
---+
 Reporter:  freyley|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Nowhere on this page

 http://docs.djangoproject.com/en/dev/ref/models/fields/

 Does it say how to save an image to a filefield or imagefield. Only by
 digging in to the code was I able to find this:

 p = Photo(...)
 p.image.save(filename, ContentFile(data))

 which was exactly what I wanted. If there's a preferred way to do it,
 that'd be fine too.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #6262: Cache templates

[Django]

#6262: Cache templates
-+--
  Reporter:  SmileyChris | Owner:  mmalone
Status:  new | Milestone: 
 Component:  Template system |   Version:  SVN
Resolution:  |  Keywords: 
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Comment (by mmalone):

 New patch adds deprecation warnings to `load_template_source` functions
 and mentions this API in the internals/deprecation docs. I've written a
 replacement implementation of `find_template_source` for backwards
 compatibility. Russ suggested an alternative approach for specifying
 loaders, where each loader can be a tuple and t[0] is the loader module
 and t[1:] are args. This is useful because you no longer have to import
 and instantiate the loader in your settings.py, so I went ahead and
 implemented it. Finally, fixed a little bug in the Context.get
 implementation.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #11384: Django Internationalization override translation mechanisim not working as expected

[Django]

#11384: Django Internationalization override translation mechanisim not working 
as
expected
---+
  Reporter:  alfredo   | Owner:  garcia_marc
   
Status:  new   | Milestone: 
   
 Component:  Internationalization  |   Version:  1.0
   
Resolution:|  Keywords:  
internationalization translation overrride not-working
 Stage:  Unreviewed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by emes):

 * cc: mic...@salaban.info (added)

Comment:

 This definitely needs to be changed. Project-level translations should be
 used by default, overriding those distributed with apps.

 The solution is to create empty app with translations only, and to put it
 on the end of INSTALLED_APPS list. This is, however, a bit hacky.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #5192: Flatpages should be able to handle more characters (e.g. ~)

[Django]

#5192: Flatpages should be able to handle more characters (e.g. ~)
-+--
  Reporter:  marco.giu...@gmail.com  | Owner:  ctrochalakis
Status:  assigned| Milestone:  
 Component:  Contrib apps|   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Ready for checkin   | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by SmileyChris):

  * 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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

[Django] #12228: Outdated example in flatpages documentation.

[Django]

#12228: Outdated example in flatpages documentation.
---+
 Reporter:  johnthedebs|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The first flatpages example (http://www.chicagocrime.org/about/) is now a
 redirect to http://chicago.everyblock.com/crime/ which, besides being a
 different site from the link, doesn't seem very flat. The page is:
 http://docs.djangoproject.com/en/dev/ref/contrib/flatpages/#module-
 django.contrib.flatpages

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12081: My project is not detecting the geodjango application

[Django]

#12081: My project is not detecting the geodjango application
-+--
  Reporter:  sahitip | Owner:  nobody
Status:  closed  | Milestone:
 Component:  GIS |   Version:  1.1   
Resolution:  invalid |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

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

Comment:

 Replying to [comment:3 intsangity]:
 > This is broken in release 1.1.1 again. It works fine in release 1.0.4.

 Do ''not'' reopen tickets that have been closed by a core developer absent
 a compelling reason.  Simply asserting that it's "broken in release 1.1.1
 again" is not compelling.  Something is wrong with your configuration, as
 I've independently verified the tutorial code does work with the 1.1.1
 release.

 Before you reopen, please provide detailed steps that ''clearly''
 demonstrates this problem -- I'm still sure you are missing `'world'`
 and/or `'django.contrib.gis'` from your `INSTALLED_APPS`.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12222: rename items in values()

[Django]

#1: rename items in values()
+---
  Reporter:  anonymous  | 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  |  
+---
Old description:

> I wish there were a way to do instead of this:
>
> {{{
> #!python
> MyModel.objects.values('otherfield__anotherjoinedfield__blah__derp__foo__doop')
> {'otherfield__anotherjoinedfield__blah__derp__foo__doop': 4,
> 'otherfield__anotherjoinedfield__blah__derp__foo__doop': 5, [...]
> }}}
> you could do this:
>
> {{{
> #!python
> MyModel.objects.values(val='otherfield__anotherjoinedfield__blah__derp__foo__doop')
> {'val': 4, 'val': 5, [...]
> }}}

New description:

 I wish there were a way to do instead of this:

 {{{
 #!python
 MyModel.objects.values('otherfield__anotherjoinedfield__blah__derp__foo__doop')
 {'otherfield__anotherjoinedfield__blah__derp__foo__doop': 4,
 'otherfield__anotherjoinedfield__blah__derp__foo__doop': 5, [...]
 }}}
 you could do this:

 {{{
 #!python
 
MyModel.objects.values(val='otherfield__anotherjoinedfield__blah__derp__foo__doop')
 {'val': 4, 'val': 5, [...]
 }}}

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12225: sql/*.sql files don't work if they contain %

[Django]

#12225: sql/*.sql files don't work if they contain %
---+
  Reporter:  monikasulik   | 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 anonymous):

 * cc: monikasu...@e.pl (removed)
  * 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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

[Django] #12227: PREPEND_WWW breaks the test client

[Django]

#12227: PREPEND_WWW breaks the test client
+---
 Reporter:  andybak |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Testing framework   | Version:  1.1   
 Keywords:  test client, redirect, prepend_www  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 With PREPEND_WWW set to true the test client will always give a 301
 status_code:


 {{{
 >>> from django.test.client import Client
 >>> c = Client()
 >>> r = c.get('/admin/', follow=True)
 >>> r.status_code
 301
 >>> r.redirect_chain
 [('http://www.testserver/admin/', 301),
 ('http://www.testserver/admin/', 301)]
 }}}

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

[Django] #12226: Test HttpResponse template attribute needlessly hard to use

[Django]

#12226: Test HttpResponse template attribute needlessly hard to use
---+
 Reporter:  carljm |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The {{{ template }}} attribute of the response objects returned by
 Django's test client might be a single template object or might be a list
 of template objects, depending whether template inheritance was used. If
 one tries to write tests that are usable in the presence of user-
 overridden templates, this results in noisy boilerplate in the tests:

 {{{
 response = client.get('/')
 try:
 template_name = response.template.name
 except AttributeError:
 template_name = response.template[0].name
 }}}

 There's no need for all this: the attribute should simply always be a
 list, sometimes of length 1.

 I would suggest that a new attribute {{{ templates }}} could be added
 which is always a list, and the old attribute {{{ template }}} could go
 through the usual deprecation cycle.

 I'll work on a patch if this approach is accepted in principle.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

[Django] #12225: sql/*.sql files don't work if they contain %

[Django]

#12225: sql/*.sql files don't work if they contain %
--+-
 Reporter:  monikasulik   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I'm getting a "tuple index out of range" error if I don't escape %
 characters in my app_name/sql/*.sql files (which, unless I'm mistaken, I
 shouldn't really have to do). I'm using psycopg2 (if this matters). The
 example code I'm attaching also causes a second error, which seems to have
 something to do with whitespace, but I think that one was already reported
 [http://code.djangoproject.com/ticket/2284 here].

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

--

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

Re: [Django] #12010: Add `ewkb` and `hexewkb` properties and document the GEOS IO Classes

[Django]

#12010: Add `ewkb` and `hexewkb` properties and document the GEOS IO Classes
---+
  Reporter:  James | Owner:  jbronn
Status:  closed| Milestone:  1.2   
 Component:  GIS   |   Version:  1.1   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  1 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

  * status:  assigned => closed
  * resolution:  => fixed
  * milestone:  => 1.2

Comment:

 Now that the [http://geodjango.org/docs/geos.html#i-o-objects GEOS I/O
 objects are now documented], I'm closing this ticket.

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

--

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

[Changeset] r11742 - in django/trunk/django/contrib/gis: db/backend/postgis db/models db/models/sql geos tests tests/geo3d utils

[noreply]

Author: jbronn
Date: 2009-11-16 12:49:00 -0600 (Mon, 16 Nov 2009)
New Revision: 11742

Added:
   django/trunk/django/contrib/gis/tests/geo3d/
   django/trunk/django/contrib/gis/tests/geo3d/__init__.py
   django/trunk/django/contrib/gis/tests/geo3d/models.py
   django/trunk/django/contrib/gis/tests/geo3d/tests.py
   django/trunk/django/contrib/gis/tests/geo3d/views.py
Modified:
   django/trunk/django/contrib/gis/db/backend/postgis/__init__.py
   django/trunk/django/contrib/gis/db/backend/postgis/adaptor.py
   django/trunk/django/contrib/gis/db/backend/postgis/query.py
   django/trunk/django/contrib/gis/db/models/aggregates.py
   django/trunk/django/contrib/gis/db/models/manager.py
   django/trunk/django/contrib/gis/db/models/query.py
   django/trunk/django/contrib/gis/db/models/sql/aggregates.py
   django/trunk/django/contrib/gis/db/models/sql/query.py
   django/trunk/django/contrib/gis/geos/geometry.py
   django/trunk/django/contrib/gis/tests/__init__.py
   django/trunk/django/contrib/gis/utils/__init__.py
   django/trunk/django/contrib/gis/utils/layermapping.py
Log:
Fixed #11433 -- 3D geometry fields are now supported with PostGIS; EWKB is now 
used by `PostGISAdaptor`.


Modified: django/trunk/django/contrib/gis/db/backend/postgis/__init__.py
===
--- django/trunk/django/contrib/gis/db/backend/postgis/__init__.py  
2009-11-16 01:59:54 UTC (rev 11741)
+++ django/trunk/django/contrib/gis/db/backend/postgis/__init__.py  
2009-11-16 18:49:00 UTC (rev 11742)
@@ -18,18 +18,21 @@
 distance_spheroid=DISTANCE_SPHEROID,
 envelope=ENVELOPE,
 extent=EXTENT,
+extent3d=EXTENT3D,
 gis_terms=POSTGIS_TERMS,
 geojson=ASGEOJSON,
 gml=ASGML,
 intersection=INTERSECTION,
 kml=ASKML,
 length=LENGTH,
+length3d=LENGTH3D,
 length_spheroid=LENGTH_SPHEROID,
 make_line=MAKE_LINE,
 mem_size=MEM_SIZE,
 num_geom=NUM_GEOM,
 num_points=NUM_POINTS,
 perimeter=PERIMETER,
+perimeter3d=PERIMETER3D,
 point_on_surface=POINT_ON_SURFACE,
 scale=SCALE,
 select=GEOM_SELECT,

Modified: django/trunk/django/contrib/gis/db/backend/postgis/adaptor.py
===
--- django/trunk/django/contrib/gis/db/backend/postgis/adaptor.py   
2009-11-16 01:59:54 UTC (rev 11741)
+++ django/trunk/django/contrib/gis/db/backend/postgis/adaptor.py   
2009-11-16 18:49:00 UTC (rev 11742)
@@ -2,7 +2,7 @@
  This object provides quoting for GEOS geometries into PostgreSQL/PostGIS.
 """
 
-from django.contrib.gis.db.backend.postgis.query import GEOM_FROM_WKB
+from django.contrib.gis.db.backend.postgis.query import GEOM_FROM_EWKB
 from psycopg2 import Binary
 from psycopg2.extensions import ISQLQuote
 
@@ -11,7 +11,7 @@
 "Initializes on the geometry."
 # Getting the WKB (in string form, to allow easy pickling of
 # the adaptor) and the SRID from the geometry.
-self.wkb = str(geom.wkb)
+self.ewkb = str(geom.ewkb)
 self.srid = geom.srid
 
 def __conform__(self, proto):
@@ -30,7 +30,7 @@
 def getquoted(self):
 "Returns a properly quoted string for use in PostgreSQL/PostGIS."
 # Want to use WKB, so wrap with psycopg2 Binary() to quote properly.
-return "%s(E%s, %s)" % (GEOM_FROM_WKB, Binary(self.wkb), self.srid or 
-1)
+return "%s(E%s)" % (GEOM_FROM_EWKB, Binary(self.ewkb))
 
 def prepare_database_save(self, unused):
 return self

Modified: django/trunk/django/contrib/gis/db/backend/postgis/query.py
===
--- django/trunk/django/contrib/gis/db/backend/postgis/query.py 2009-11-16 
01:59:54 UTC (rev 11741)
+++ django/trunk/django/contrib/gis/db/backend/postgis/query.py 2009-11-16 
18:49:00 UTC (rev 11742)
@@ -63,17 +63,21 @@
 DISTANCE_SPHERE = get_func('distance_sphere')
 DISTANCE_SPHEROID = get_func('distance_spheroid')
 ENVELOPE = get_func('Envelope')
-EXTENT = get_func('extent')
+EXTENT = get_func('Extent')
+EXTENT3D = get_func('Extent3D')
 GEOM_FROM_TEXT = get_func('GeomFromText')
+GEOM_FROM_EWKB = get_func('GeomFromEWKB')
 GEOM_FROM_WKB = get_func('GeomFromWKB')
 INTERSECTION = get_func('Intersection')
   

Re: [Django] #12081: My project is not detecting the geodjango application

[Django]

#12081: My project is not detecting the geodjango application
-+--
  Reporter:  sahitip | Owner:  nobody
Status:  reopened| Milestone:
 Component:  GIS |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by intsangity):

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

Comment:

 This is broken in release 1.1.1 again. It works fine in release 1.0.4.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

[Django] #12224: psycopg2 raises "can't adapt" when use gettext extensions on model meta permissions field.

[Django]

#12224: psycopg2 raises "can't adapt" when use gettext extensions on model meta
permissions field.
-+--
 Reporter:  chronos  |  
 Owner:  chronos   
   Status:  new  |   
Milestone:  1.2   
Component:  Database layer (models, ORM) | 
Version:  SVN   
 Keywords:  psycopg2, permissions, i18n, gettext, "can't adapt", syncdb  |  
 Stage:  Unreviewed
Has_patch:  0|  
-+--
 When we create custom permissions for model, works perfectly if we use
 like this:

 {{{
   class Meta:
 permissions = (
   ('can_view_info',"Can view info."),
   ('can_view_reports',"Can view reports."),
   ('can_export_reports',"Can export reports."),
   ('can_search',"Can search."),
 )
 }}}

 But, if we use like that, for multiple language sites:

 {{{
   class Meta:
 permissions = (
   ('can_view_info',_("Can view info.")),
   ('can_view_reports',_("Can view reports.")),
   ('can_export_reports',_("Can export reports.")),
   ('can_search',_("Can search.")),
 )
 }}}

 We get psycopg2 raising following error on syncdb:

 {{{
 ...
 You just installed Django's auth system, which means you don't have any
 superusers defined.
 Would you like to create one now? (yes/no): no
 Traceback (most recent call last):
   File "manage.py", line 11, in 
 execute_manager(settings)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/core/management/__init__.py", line 439, in execute_manager
 utility.execute()
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/core/management/__init__.py", line 380, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/core/management/base.py", line 195, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/core/management/base.py", line 222, in execute
 output = self.handle(*args, **options)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/core/management/base.py", line 351, in handle
 return self.handle_noargs(**options)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/core/management/commands/syncdb.py", line 89, in
 handle_noargs
 emit_post_sync_signal(created_models, verbosity, interactive)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/core/management/sql.py", line 194, in
 emit_post_sync_signal
 interactive=interactive)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/dispatch/dispatcher.py", line 166, in send
 response = receiver(signal=self, sender=sender, **named)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/contrib/auth/management/__init__.py", line 28, in
 create_permissions
 defaults={'name': name, 'content_type': ctype})
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/db/models/manager.py", line 122, in get_or_create
 return self.get_query_set().get_or_create(**kwargs)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/db/models/query.py", line 328, in get_or_create
 obj.save(force_insert=True)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/db/models/base.py", line 419, in save
 self.save_base(force_insert=force_insert, force_update=force_update)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/db/models/base.py", line 504, in save_base
 result = manager._insert(values, return_id=update_pk)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/db/models/manager.py", line 179, in _insert
 return insert_query(self.model, values, **kwargs)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/db/models/query.py", line 1087, in insert_query
 return query.execute_sql(return_id)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/db/models/sql/subqueries.py", line 320, in execute_sql
 cursor = super(InsertQuery, self).execute_sql(None)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/db/models/sql/query.py", line 2373, in execute_sql
 cursor.execute(sql, params)
   File "/home/felipe.prenholato/.python/lib/python2.5/site-
 packages/django/db/backends/util.py", line 19, in execute
 return self.cursor.execute(sql, params)
 psycopg2.ProgrammingError: can't adapt
 }}}

 This error happens with Django 1.1 beta 1 and Django 1.2 pre-alpha
 (current svn). I 

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
---+
  Reporter:  jacob | Owner:  dcramer 
Status:  assigned  | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  
Resolution:|  Keywords:  database
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by wprins):

 * cc: wprins (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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12025: Show generic relation on deleted objects

[Django]

#12025: Show generic relation on deleted objects
---+
  Reporter:  rui.coe...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Uncategorized |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 Replying to [comment:2 Alex]:
 > This patch a) still has the mutable default value, and b) includes
 django.contrib.contenttypes in the ORM, we want to work to reducing that
 dependency, not increasing it.

 a) Which mutable default value are you talking about, is it "objs_seen",
 if yes, you suggest to start this value with what and why ??

 b) Humm, ok, i will see what i can do to avoid that. If you have a
 suggestion i would appreciate.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12025: Show generic relation on deleted objects

[Django]

#12025: Show generic relation on deleted objects
---+
  Reporter:  rui.coe...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Uncategorized |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by Alex):

 This patch a) still has the mutable default value, and b) includes
 django.contrib.contenttypes in the ORM, we want to work to reducing that
 dependency, not increasing 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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #9475: add(), create(), etc. should be supported by intermedite ManyToMany model with extra attributes if extra fields can be calculated

[Django]

#9475: add(), create(), etc. should be supported by intermedite ManyToMany model
with extra attributes if extra fields can be calculated
---+
  Reporter:  o...@gezgin.com   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 Replying to [comment:3 russellm]:
 > Thanks for the patch, However, this isn't something that should require
 a manual 'can_add' flag. We know all the relevant details - which fields
 are unique, which fields have defaults etc. We can therefore compute the
 value that can_add and can_remove provide manually in this patch.
 >
 > As a secondary issue, there is also an API issue around the call to
 add(). If you read the discussion on #6095 - the ticket that originally
 introduced m2m intermediates - there was some discussion about whether
 add() could be modified to allow people to add m2m entries *with*
 intermediate data. If we're going to close this ticket, it would be nice
 to get some resolution on this closely related issue, even if it's just to
 say "no".

 Exposing those flags (a two line change) allows fields on intermediary
 models to be filled in by `save()` and "bulk delete" behavior if the
 foreign keys are not `unique_together`. The ability to explicitly disable
 `add()` or `remove()` would be nice, but you could just say "don't do that
 then".

 Regarding your secondary issue, I'm in favour of allowing `add()` to just
 work for every m2m (Favoured color:
 {{{
 add(obj1, obj2, extra_field1="foo", extra_field2="bar")`
 }}}
 ). But that does not translate cleanly to `create()` and assignment. So
 the distinction between simple intermediary models and more complex ones
 probably won't go away.

 If some kind of `add(..., extra=...)` support is in scope for this ticket,
 I'll happily add 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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #11123: Irish localflavor

[Django]

#11123: Irish localflavor
-+--
  Reporter:  mt  | Owner:  nobody
Status:  new | Milestone:  1.2   
 Component:  django.contrib.localflavor  |   Version:  1.0   
Resolution:  |  Keywords:  Ireland ie
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by mt):

 Hi Russell,
 No such official abbreviation or enumeration exists for Irish County
 names.
 Thanks
 Michael

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12222: rename items in values()

[Django]

#1: rename items in values()
+---
  Reporter:  anonymous  | 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  |  
+---
Old description:

> I wish there were a way to do instead of this:
>
> >>>
> MyModel.objects.values('otherfield__anotherjoinedfield__blah__derp__foo__doop')
> {'otherfield__anotherjoinedfield__blah__derp__foo__doop': 4,
> 'otherfield__anotherjoinedfield__blah__derp__foo__doop': 5, [...]
>
> you could do this:
>
> >>>
> MyModel.objects.values(val='otherfield__anotherjoinedfield__blah__derp__foo__doop')
> {'val': 4, 'val': 5, [...]

New description:

 I wish there were a way to do instead of this:

 {{{
 #!python
 MyModel.objects.values('otherfield__anotherjoinedfield__blah__derp__foo__doop')
 {'otherfield__anotherjoinedfield__blah__derp__foo__doop': 4,
 'otherfield__anotherjoinedfield__blah__derp__foo__doop': 5, [...]
 }}}
 you could do this:

 {{{
 #!python
 
MyModel.objects.values(val='otherfield__anotherjoinedfield__blah__derp__foo__doop')
 {'val': 4, 'val': 5, [...]
 }}}

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #11984: Problem with date_hierarchy in Django 1.1 - Truncated incorrect datetime value: '0000-01-01 00:00:00'

[Django]

#11984: Problem with date_hierarchy in Django 1.1 - Truncated incorrect datetime
value: '-01-01 00:00:00'
-+--
  Reporter:  sergey.g.ales...@gmail.com  | Owner:  sorin
Status:  assigned| Milestone:   
 Component:  django.contrib.admin|   Version:  1.1  
Resolution:  |  Keywords:   
 Stage:  Unreviewed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by nbolton):

 +1

 I think it would be good for the patch to be committed.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12222: rename items in values()

[Django]

#1: rename items in values()
+---
  Reporter:  anonymous  | 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  |  
+---
Comment (by anonymous):

 Sorry I didn't realize it would change the formatting. I'd fix it if I
 could but I can't figure out how to edit it.

 "!__in" has nothing to do with what the ticket was about. You know how you
 can rename an annotation by doing .annotate(name=Sum('field'))? Well that
 functionality should exist for values() as well.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #11984: Problem with date_hierarchy in Django 1.1 - Truncated incorrect datetime value: '0000-01-01 00:00:00'

[Django]

#11984: Problem with date_hierarchy in Django 1.1 - Truncated incorrect datetime
value: '-01-01 00:00:00'
-+--
  Reporter:  sergey.g.ales...@gmail.com  | Owner:  sorin
Status:  assigned| Milestone:   
 Component:  django.contrib.admin|   Version:  1.1  
Resolution:  |  Keywords:   
 Stage:  Unreviewed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by sorin):

 First, rememeber that Django is not always used to connect to new
 databases so changing the values from the database is not always an
 option. I'm sure other people have legacy databases that are using the
 -00-00 format instead of NULL for dates. This is something accepted by
 MySQL and should be accepted by Django also.

 Also I don't think that this patch does have a negative impact on any
 other back-ends - in fact all it does is that it does detect possible
 errors in order to prevent application crash.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12223: EmailField does not actually validate

[Django]

#12223: EmailField does not actually validate
---+
  Reporter:  JohnDoe   | 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 |  
---+
Comment (by ubernostrum):

 The implementation is not wrong, and the documentation is not wrong. Model
 fields ''never'' perform any validation of this sort, and at the moment
 are quite incapable of doing so. Forms can and do perform such validation,
 and when a form is generated from a model which includes an `EmailField`,
 the appropriate validation will be performed. Whenever and wherever a
 model field has specialized constraints like this, the validation is
 always handled by forms, and every such model field generates an
 appropriate form field which performs that validation.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12223: EmailField does not actually validate

[Django]

#12223: EmailField does not actually validate
---+
  Reporter:  JohnDoe   | 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 |  
---+
Comment (by JohnDoe):

 That's not what the documentation states, it says:

 A CharField '''that checks that the value is a valid e-mail address.'''

 which does NOT happen.

 So, either the documentation is wrong or the implementation of it must be.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12223: EmailField does not actually validate

[Django]

#12223: EmailField does not actually validate
---+
  Reporter:  JohnDoe   | 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 ubernostrum):

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

Comment:

 Models do not currently do any validation; that's what forms are for, and
 the default form field generated by `EmailField` does indeed implement a
 validation check.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

[Django] #12223: EmailField does not actually validate

[Django]

#12223: EmailField does not actually validate
--+-
 Reporter:  JohnDoe   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The modelfield EmailField does not actually validate the email, as stated
 in the documentation (see.
 [http://docs.djangoproject.com/en/dev/ref/models/fields/#emailfield]).

 === My test ===

 {{{
 class TestModel(models.Model):
 email = models.EmailField()
 }}}


 {{{
 >>> t = TestModel(email='asd,,,')
 >>> t.save()
 }}}

 No error is raised, even though that is not a valid email.

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #12222: rename items in values()

[Django]

#1: rename items in values()
+---
  Reporter:  anonymous  | 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
  * resolution:  => invalid
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 1. Please use preview.
  2. I think you're looking for
 [http://docs.djangoproject.com/en/dev/ref/models/querysets/#in !__in.]

-- 
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.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.