Re: [Django] #11827: GeoQuerySet extent() method fails if contains only one object with point geometry

[Django]

#11827: GeoQuerySet extent() method fails if contains only one object with point
geometry
-+--
  Reporter:  mal | Owner:  nobody
Status:  new | Milestone:
 Component:  GIS |   Version:  1.1   
Resolution:  |  Keywords:  oracle
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jtiai):

  * keywords:  => oracle

Comment:

 Well this is "feature" of Oracle Spatial SDO_AGGR_MBR function. It's
 describes few "exceptions" as follows (excerpt from Oracle Spatial
 documentation):

  * This function does not return an MBR geometry if a proper MBR cannot be
 constructed. Specifically:
   * If the input geometries are all null, the function returns a null
 geometry.
   * If all data in the input geometries is on a single point, the function
 returns the point.
   * If all data in the input geometries consists of points on a straight
 line, the function returns a two-point line.

 AFAIK at least PostGIS uses st_extent for extent() method which always
 returns real bounding box.

-- 
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-updates@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] #11829: django-admin model validation mistake

[Django]

#11829: django-admin model validation mistake
--+-
  Reporter:  bluejeansummer   | Owner:  nobody 
Status:  closed   | Milestone: 
 Component:  django-admin.py  |   Version:  1.0
Resolution:  invalid  |  Keywords:  model db_column
 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:

 Field names ending with underscores are invalid regardless of `db_column`,
 because the Python-level query API separates field names/joins/lookup
 types with underscores; as the error message tells you, ending a field
 name in an underscore would lead to ambiguity in parsing the Python-level
 field lookups.

-- 
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-updates@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] #10061: incorrect logout link in admin

[Django]

#10061: incorrect logout link in admin
---+
  Reporter:  lashni| Owner:  mtredinnick
Status:  closed| Milestone:  1.1
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:  fixed |  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  1  
Needs_better_patch:  1 |  
---+
Comment (by mjs7231):

 Did this fix make it into the django-1.1 release?
 It's hard for me to tell by the dates.

-- 
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-updates@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] #11829: django-admin model validation mistake

[Django]

#11829: django-admin model validation mistake
-+--
 Reporter:  bluejeansummer   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django-admin.py  | Version:  1.0   
 Keywords:  model db_column  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 In one of my models I have a field that would be logically be called
 `class`, but because it is a reserved word, I renamed the field to
 `class_` (notice the trailing underscore). I also set the `db_column`
 kwarg to `class`. I then run `./manage.py sql tracker`, and get this
 error:
 {{{
 Error: One or more models did not validate:
 tracker.assignment: "class_": Field names cannot end with underscores,
 because this would lead to ambiguous queryset filters.
 }}}

 However, when I set the model name to `klass`, the output shows it
 recognizes the `db_column` setting. It seems that the validator should
 check for that setting before emitting an error. Is there a work around I
 should use for now? I'd rather not spell "class" with a "k".

 System Info:
  * Ubuntu 9.04
  * Django 1.0.2

 -- Nick

-- 
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-updates@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] #2417: Support for binary type fields (aka: bytea in postgres and VARBINARY in mysql)

[Django]

#2417: Support for binary type fields (aka: bytea in postgres and VARBINARY in
mysql)
---+
  Reporter:  scan...@nominum.com   | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #11828: Testing w/ contenttypes with syncdb causes an error django_content_types table does not exist

[Django]

#11828: Testing w/ contenttypes with syncdb causes an error django_content_types
table does not exist
-+--
 Reporter:  craig.kime...@gmail.com  |   Owner:  nobody 
   Status:  new  |   Milestone: 
Component:  Testing framework| Version:  soc2009/multidb
 Keywords:   |   Stage:  Unreviewed 
Has_patch:  0|  
-+--
 A quick way to see the error (which is obviously wrong)

 1. Add contenttypes to your installed apps
 1. Create a model on  second db (we'll call it 'other_db')
 1. In django/test/simple.py run_tests() make the alias iteration order
 (you can hardcode this) to be `for alias in ordered:`  with `for alias in
 ['other_db', 'default']

 That will show that the db creation order is important.

 The other harder way to do this, is to find something that lets you
 iterate over a dictionaries items where whatever your other alias hashes
 "before" the 'default' one does.

-- 
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-updates@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] #7270: selected_related() can not follow reverse relations of OneToOne.

[Django]

#7270: selected_related() can not follow reverse relations of OneToOne.
---+
  Reporter:  towjz...@hotmail.com  | Owner:  
mtredinnick
Status:  new   | Milestone:  1.2

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

Resolution:|  Keywords:  
select_related onetoone reverse
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

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

  * needs_tests:  1 => 0

Comment:

 Ok, I've update the patch for the r11479, and have included a basic test
 (it's my first time for this, so please advise if it needs to be better).

-- 
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-updates@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] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+--
  Reporter:  svetlyak40wt| Owner:  nobody   
   
Status:  new | Milestone:   
   
 Component:  Core framework  |   Version:  1.0  
   
Resolution:  |  Keywords:  model inheritance, 
signals, dispatch
 Stage:  Accepted| Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Changes (by benbest86):

 * cc: benbest86 (added)

Comment:

 I have come across the need for this as well - especially when overriding
 defaults of other projects by inheritance instead of forking.

 One (relatively) easy way to deal with this is to listen on the relevant
 child class signals and send the base class signal from there. This way
 you can still attach all of your common signals to the base class and not
 worry about adding a new one to each child for every new listening
 function.

 Ex:

 {{{
 class Child(Parent):
 pass
 def call_parent_post_save(sender, instance, created, **kwargs):
 post_save.send(sender=Parent,
 instance=Parent.objects.get(id=instance.id), created=created, **kwargs)
 post_save.connect(call_parent_post_save, sender=Child)
 }}}

 Not sure if there is a better way to get the proper instance though -
 haven't found a great way to do this directly from the existing instance
 instead of using a query. Any thoughts would be appreciated.

-- 
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-updates@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] #11198: Forms URLfield regex takes infinite to validate a long field

[Django]

#11198: Forms URLfield regex takes infinite to validate a long field
-+--
  Reporter:  marcob  | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by wam):

 I've updated the patch to also support URLs that terminate in a dot (e.g.
 http://example.com./) with a few more testcases for this additional
 functionality.  Those URLs are annoying, but domain names are allowed to
 end in a dot, thus URLs are allowed to include the trailing dot 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-updates@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] #11827: GeoQuerySet extent() method fails if contains only one object with point geometry

[Django]

#11827: GeoQuerySet extent() method fails if contains only one object with point
geometry
-+--
  Reporter:  mal | Owner:  nobody
Status:  new | Milestone:
 Component:  GIS |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 The reason seems to be that when calling "qs.extent" system executes sql
 like this:
 {{{
 SELECT SDO_UTIL.TO_WKTGEOMETRY(SDO_AGGR_MBR("POINT"."GEOMETRY")) AS geoagg
 FROM "POINT" WHERE "POINT"."ID" = 123456
 }}}

 so, it's a search by primary key, results in 1 object, and in Oracle
 (don't know about Postgis) SDO_AGGR_MBR on a collection that contains only
 one point will result in *point* object, not polygon...

-- 
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-updates@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] #11827: GeoQuerySet extent() method fails if contains only one object with point geometry

[Django]

#11827: GeoQuerySet extent() method fails if contains only one object with point
geometry
-+--
  Reporter:  mal | Owner:  nobody
Status:  new | 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 mal):

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

Comment:

 That happens with Oracle Spatial database

-- 
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-updates@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] #11827: GeoQuerySet extent() method fails if contains only one object with point geometry

[Django]

#11827: GeoQuerySet extent() method fails if contains only one object with point
geometry
-+--
 Reporter:  mal  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  GIS  | Version:  1.1   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 I have a point object, with valid, non null geometry.
 {{{
 qs=Point.objects.filter(id=123456)
 }}}
 qs is not empty and contains one object with non null point geometry.

 Then, when calling
 {{{
 qs.extent()
 }}}

 i get the following error (as in the end of the stack trace):
 {{{
  36 # the 4-tuple from the coordinates in the polygon.

  37 poly = SpatialBackend.Geometry(clob.read())
 ---> 38 shell = poly.shell
  39 ll, ur = shell[0], shell[2]
  40 xmin, ymin = ll

 AttributeError: 'Point' object has no attribute 'shell'
 }}}

-- 
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-updates@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] #11826: django.forms.fields.URLField rejects valid URLs with no abs_path component

[Django]

#11826: django.forms.fields.URLField rejects valid URLs with no abs_path 
component
---+
 Reporter:  wam|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 As annoying as it is, RFC 2616 section 3.2.2
 (http://www.rfc2616.com/#3.2.2) allows the abs_path component (the
 pathname following the optional port number) to be optional in an HTTP URL
 (it implicitly becomes '/', and is required to treated as '/' for sake of
 comparisons as well as for request processing). However, the definition of
 django.forms.fields.url_re requires the character following the optional
 port number to be a /. The regex also allows the URL to just end after the
 port with no abs_path, but it currently rejects URLs like:

 {{{
 http://example.com?some_param=some_value
 }}}

 Additionally, the clean() method tacks on a trailing slash to URLs that
 don't have a pathname.

 Attached to this ticket will be a patch to django/forms/fields.py which
 properly handles URLs like the one listed above by normalizing it to the
 version that is suitable for URI comparison (see
 http://www.rfc2616.com/#3.2.3). The patch will also provide an additional
 testcase to tests/regressiontests/forms/fields.py which includes the URL
 above along with it's expected normalization.

-- 
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-updates@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] #11822: Slugify check for existing slugs in table

[Django]

#11822: Slugify check for existing slugs in table
--+-
  Reporter:  amites   | Owner:   
Status:  closed   | Milestone:   
 Component:  ORM aggregation  |   Version:  1.1  
Resolution:  invalid  |  Keywords:  slug, slufigy
 Stage:  Unreviewed   | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Comment (by joshuajonah):

 I agree this is outside the scope of a tag. If you require this type of
 functionality, there are many third party scripts that will allow you to
 do this in a non-invasive way. For example
 http://www.djangosnippets.org/snippets/369/ is a pretty nice one. Use that
 instead amites.

-- 
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-updates@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] #7231: New "join" parameter for the "extra" QuerySet method

[Django]

#7231: New "join" parameter for the "extra" QuerySet method
-+--
  Reporter:  Davide "Design" Muzzarelli  | Owner:  nobody   
  
Status:  new | Milestone:   
  
 Component:  Core framework  |   Version:  SVN  
  
Resolution:  |  Keywords:  queryset 
extra join
 Stage:  Design decision needed  | Has_patch:  1
  
Needs_docs:  1   |   Needs_tests:  1
  
Needs_better_patch:  0   |  
-+--
Comment (by bendavis78):

 Anyone willing to write a test for this?  Would be nice to have this in
 for 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-updates@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] #11825: Polish national flavour bugs

[Django]

#11825: Polish national flavour bugs
+---
  Reporter:  Maksymus007| Owner:  Maksymus007
Status:  assigned   | Milestone: 
 Component:  Uncategorized  |   Version:  1.1
Resolution: |  Keywords: 
 Stage:  Unreviewed | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  1  
Needs_better_patch:  0  |  
+---
Comment (by Maksymus007):

 Fixed bug: printing improper field value for fields with required=False
 and having no content; Now prints "field is reuqired" for empty fields
 having required=True

-- 
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-updates@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] #11825: Polish national flavour bugs

[Django]

#11825: Polish national flavour bugs
+---
  Reporter:  Maksymus007| Owner:  Maksymus007
Status:  assigned   | Milestone: 
 Component:  Uncategorized  |   Version:  1.1
Resolution: |  Keywords: 
 Stage:  Unreviewed | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  1  
Needs_better_patch:  0  |  
+---
Changes (by Maksymus007):

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

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #11825: Polish national flavour bugs

[Django]

#11825: Polish national flavour bugs
+---
  Reporter:  Maksymus007| Owner:  Maksymus007
Status:  assigned   | Milestone: 
 Component:  Uncategorized  |   Version:  1.1
Resolution: |  Keywords: 
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by Maksymus007):

  * status:  new => assigned
  * 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-updates@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] #11825: Polish national flavour bugs

[Django]

#11825: Polish national flavour bugs
---+
 Reporter:  Maksymus007|   Owner:  Maksymus007
   Status:  new|   Milestone: 
Component:  Uncategorized  | Version:  1.1
 Keywords: |   Stage:  Unreviewed 
Has_patch:  0  |  
---+
 Polish National Flavour validators go out of string range and does not
 check types

-- 
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-updates@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] #11824: {% with %} tag to support tuples

[Django]

#11824: {% with %} tag to support tuples
-+--
 Reporter:  semenov  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Template system  | Version:  1.1   
 Keywords:  with, tuple  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Currently, that's possible to iterate over a collection of tuples with:
 {{{
 {% for x, y in points %}
 There is a point at {{ x }},{{ y }}
 {% endfor %}
 }}}

 However, given a single tuple, there's no way to extract its items to
 (temporary) context variables. For example:
 {{{
 {% with object.get_last_point as point %}
 There is a point at {{ point.0 }},{{ point.1 }} -- ugly and
 unmaintainable
 {% endwith %}
 }}}


 I would like to propose the extension of {% with %} tag to support the
 following syntax:
 {{{
 {% with object.get_last_point as x, y %}
 There is a point at {{ x }},{{ y }}
 {% endwith %}
 }}}

-- 
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-updates@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] #11822: Slugify check for existing slugs in table

[Django]

#11822: Slugify check for existing slugs in table
--+-
  Reporter:  amites   | Owner:   
Status:  closed   | Milestone:   
 Component:  ORM aggregation  |   Version:  1.1  
Resolution:  invalid  |  Keywords:  slug, slufigy
 Stage:  Unreviewed   | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Changes (by lukeplant):

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

Comment:

 This would only work correctly if it could also save the data to the
 table.  This is certainly beyond what a template filter ought to be doing
 -- that kind of logic belongs in your view functions or database - this is
 the reason SlugField exists.  Therefore closing as INVALID.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #1946: [patch] to allow overriding of default sequence name

[Django]

#1946: [patch] to allow overriding of default sequence name
---+
  Reporter:  ab...@cabal.org.uk| Owner:  shmengie
Status:  assigned  | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  1   
Needs_better_patch:  1 |  
---+
Changes (by ernst):

 * cc: er...@stickybit.se (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-updates@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] #11823: Flush command should allow to choose send/not send syncdb signal and call/not call loaddata command

[Django]

#11823: Flush command should allow to choose send/not send syncdb signal and
call/not call loaddata command
+---
  Reporter:  kapa77 | Owner:  nobody   
Status:  closed | Milestone:   
 Component:  Uncategorized  |   Version:  1.1  
Resolution:  duplicate  |  Keywords:  flush command
 Stage:  Unreviewed | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 At the core, this is really a duplicate of #7052. Changing the behaviour
 of flush isn't the solution. We need to fix the real problem - handling
 serialization and deserialization of data that is created dynamically
 during synchronization.

-- 
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-updates@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] #11823: Flush command should allow to choose send/not send syncdb signal and call/not call loaddata command

[Django]

#11823: Flush command should allow to choose send/not send syncdb signal and
call/not call loaddata command
---+
 Reporter:  kapa77 |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords:  flush command  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 The flush command is sending syncdb signal at the end of it's run. It can
 be problematic with contenttype app installed. I have this situation:
 I have old version of app with contentype app installed, I wrote new
 version of part of my project and now i want to dumpdata from old db and
 loaddata on new db.
 There is script that ports data from old to new db. The problem id that i
 have generic relations and they have relation to content types, and when i
 run flush content type app is creating conten types in db but in different
 order than i have in my old db, and with this my generic relation are
 broken.

-- 
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-updates@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] #8010: adding support for multiple test files for applications

[Django]

#8010: adding support for multiple test files for applications
+---
  Reporter:  esizikov   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by esizikov):

 After applying the patch I have got a considerable simplification of an
 application test cases (see the diff below).

 As you can see I kept suite() method for one test group,
 test_phone_numbers.py - this demonstrates that the default behaviour keeps
 working. But, after applying the patch I can call the "disabled" use case
 easily (while getting a lot of test failures -the reason of disabling the
 test case):

 {{{
 $ python manage.py test refs.PhoneNumberNormalizationTests
 }}}

 Following is the diff which demonstrates test suite simplification changes
 geared by the patch:

 {{{
 #!diff
 diff --git a/bis/refs/tests/__init__.py b/bis/refs/tests/__init__.py
 --- a/bis/refs/tests/__init__.py
 +++ b/bis/refs/tests/__init__.py
 @@ -1,21 +0,0 @@
 -# -*- coding: utf-8 -*-
 -from unittest import main, TestSuite, defaultTestLoader
 -
 -import test_email_validation, test_highlight,
 test_phone_number_normalization, test_views
 -
 -
 -test_suites = [test_email_validation.suite(),
 -   test_highlight.suite(),
 -   test_phone_number_normalization.suite(),
 -   test_views.suite(),
 -   ]
 -
 -
 -def suite():
 -s = TestSuite()
 -s.addTests(test_suites)
 -return s
 -
 -
 -if __name__ == '__main__':
 -main(defaultTest='suite')
 diff --git a/bis/refs/tests/test_email_validation.py
 b/bis/refs/tests/test_email_validation.py
 --- a/bis/refs/tests/test_email_validation.py
 +++ b/bis/refs/tests/test_email_validation.py
 @@ -1,11 +1,11 @@
  # -*- coding: utf-8 -*-
  import re
 -from unittest import main, makeSuite, TestSuite, TestCase
 +from unittest import TestCase

  EMAIL_VALIDATION =
 re.compile(r"^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@"
 "([a-z0-9_]([-a-z0-9_]?[a-z0-9])*(\.[-a-z0-9_]{1,64})*\."
 
"(aero|arpa|biz|com|coop|edu|gov|info|int|mil|museum|name|net|org|pro|travel|mobi|"
 "[a-z][a-z])|"
 "([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$",
 re.I | re.U)
  from django.forms.fields import email_re as EMAIL_VALIDATION
 @@ -219,19 +219,8 @@ lo...@secondleveldomainnamesareinvalidif

  def _test_email_invalid_19(self):
  email =
 r'lo...@secondleveldomainnamesareinvalidiftheyarelongerthan64charactersss.org'
  self.failIf(self.re.match(email), email + r' invalid')

  def _test_email_invalid_20(self):
  email =
 
r'lo...@thirdlevel.secondleveldomainnamesareinvalidiftheyarelongerthan64charactersss.org'
  self.failIf(self.re.match(email), email + r' invalid')
 -
 -
 -def suite():
 -s = TestSuite()
 -s.addTest(makeSuite(EmailValidatorValidTests))
 -s.addTest(makeSuite(EmailValidatorInvalidTests))
 -return s
 -
 -
 -if __name__ == '__main__':
 -main(defaultTest='suite')
 diff --git a/bis/refs/tests/test_highlight.py
 b/bis/refs/tests/test_highlight.py
 --- a/bis/refs/tests/test_highlight.py
 +++ b/bis/refs/tests/test_highlight.py
 @@ -1,11 +1,11 @@
  # -*- coding: utf-8 -*-
  import re
 -from unittest import main, makeSuite, TestSuite, TestCase
 +from unittest import TestCase

  from bis.refs.utils import highlight


  class SearchHighlightTests(TestCase):
  """ Search results highlighting.

  http://trac.223-223.ru/bis/ticket/75
 @@ -35,18 +35,8 @@ http://trac.223-223.ru/bis/ticket/75

  def test_highlight_4(self):
  res = self._highlight(u'лиса123', u'лис')
  self.assertEqual(res, u'лиса123')

  def test_highlight_5(self):
  res = self._highlight(u'Насос Ручеек - продажа', u'насос')
  self.assertEqual(res, u'Насос Ручеек - продажа')
 -
 -
 -def suite():
 -s = TestSuite()
 -s.addTest(makeSuite(SearchHighlightTests))
 -return s
 -
 -
 -if __name__ == '__main__':
 -main(defaultTest='suite')
 }}}

-- 
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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, 

Re: [Django] #11809: Unable to test a non-db dependent django app without db configuration

[Django]

#11809: Unable to test a non-db dependent django app without db configuration
+---
  Reporter:  Prabhu Subramanian   |   
  Owner:  nobody
Status:  new| 
Milestone:
 Component:  Testing framework  |   
Version:  1.1   
Resolution: |  
Keywords:
 Stage:  Unreviewed | 
Has_patch:  0 
Needs_docs:  0  |   
Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Prabhu Subramanian ):

 And IMHO from a framework perspective, this should be a valid requirement.
 There might be only few people using django for non-db apps right now. It
 is only a matter of some guy writing a blog post explaining how cool
 django is for non-db apps and the article getting picked up by slashdot
 and reddit. Then you will see several thousand doing 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-updates@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] #11809: Unable to test a non-db dependent django app without db configuration

[Django]

#11809: Unable to test a non-db dependent django app without db configuration
+---
  Reporter:  Prabhu Subramanian   |   
  Owner:  nobody
Status:  new| 
Milestone:
 Component:  Testing framework  |   
Version:  1.1   
Resolution: |  
Keywords:
 Stage:  Unreviewed | 
Has_patch:  0 
Needs_docs:  0  |   
Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Prabhu Subramanian ):

 if no DATABASE_ENGINE is given, why cant the test runner skip
 creating/deleting test database? No special value is required. This would
 satisfy the genuine cases where the app really doesn't require databases.

 For the bad case, where a developer has left out DATABASE_ENGINE
 parameter, but is doing something with models that require db access, then
 the database accessing code is responsible for throwing these Exceptions.

 I haven't cared to look at the code. Perhaps a patch can help?

-- 
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-updates@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
-~--~~~~--~~--~--~---