Re: [Django] #4736: manually named primary key columns not properly quoted

[Django]

#4736: manually named primary key columns not properly quoted
---+
  Reporter:  akaihola  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 All field objects are handed through to the backend and treated
 consistently now (post queryset-refactor merge), so this doesn't appear to
 be an issue any longer.

-- 
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] #5931: __repr__ for db Fields

[Django]

#5931: __repr__ for db Fields
---+
  Reporter:  Thomas Güttler   | Owner:  
nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Changes (by mtredinnick):

  * needs_better_patch:  0 => 1
  * stage:  Design decision needed => Accepted

Comment:

 Seems reasonable. However, the test doesn't show that it works as
 expected. It shows that when you use a field in a completely non-standard
 fashion (outside of a model), it reports None. That's maybe 0.001% of the
 normal use-cases. Testing the other 99%+ would be ideal. :-)

-- 
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] #9862: Non-standard SQL generated in column definition for nullable columns in create table DDL

[Django]

#9862: Non-standard SQL generated in column definition for nullable columns in
create table DDL
+---
  Reporter:  Ambrish| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

  * stage:  Unreviewed => Accepted

Comment:

 No database on earth implements the same subset of SQL, so references to
 the standard, with all its optional bits and non-standard extensions in
 implementation, isn't too helpful either way. However, if a database
 doesn't support something, we should make sure it's not required. Practice
 always trumps theory.

 In this case, the solution is probably just to not include the `NULL`.
 `NOT NULL` is permitted, so we include that for `null=False` fields and
 use the fact that columns should be nullable by default.

 Ambrish: it's only `NULL` that is causing a problem on db2, right? `NOT
 NULL` is fine?

 We still need to check that this works sufficiently on all the other
 backends (including getting some confirmation from Ramiro Morales about MS
 SQL). If there's an inconsistency in requirements, it will need an
 addition of another `BaseDatabaseFeature` function.

-- 
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] #9845: Aggregate regression tests fail against SQLite 3.5.9

[Django]

#9845: Aggregate regression tests fail against SQLite 3.5.9
--+-
  Reporter:  Alex | Owner: 
Status:  closed   | Milestone: 
 Component:  ORM aggregation  |   Version:  1.0
Resolution:  fixed|  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:  => fixed
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Fixed in github branch, commit f1eacc9518f621f4c85abc9e46e0e5692cdeb852.
 Thanks to Alex Gaynor and Ramiro Morales for their help in tracking down
 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-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
-~--~~~~--~~--~--~---

[Changeset] r9652 - in django/branches/releases/1.0.X: django/db/backends/mysql docs/ref docs/ref/models

[noreply]

Author: mtredinnick
Date: 2008-12-16 00:49:43 -0600 (Tue, 16 Dec 2008)
New Revision: 9652

Modified:
   django/branches/releases/1.0.X/django/db/backends/mysql/validation.py
   django/branches/releases/1.0.X/docs/ref/databases.txt
   django/branches/releases/1.0.X/docs/ref/models/fields.txt
Log:
[1.0.X] Fixed #9431 -- Added extra validation for VARCHAR-based fields on MySQL.
max_length > 255 and unique=True is not permitted. Based on a patch from
adamnelson.

Backport of r9470 from trunk.


Modified: django/branches/releases/1.0.X/django/db/backends/mysql/validation.py
===
--- django/branches/releases/1.0.X/django/db/backends/mysql/validation.py   
2008-12-16 06:48:15 UTC (rev 9651)
+++ django/branches/releases/1.0.X/django/db/backends/mysql/validation.py   
2008-12-16 06:49:43 UTC (rev 9652)
@@ -2,12 +2,27 @@
 
 class DatabaseValidation(BaseDatabaseValidation):
 def validate_field(self, errors, opts, f):
-"Prior to MySQL 5.0.3, character fields could not exceed 255 
characters"
+"""
+There are some field length restrictions for MySQL:
+
+- Prior to version 5.0.3, character fields could not exceed 255
+  characters in length.
+- No character (varchar) fields can have a length exceeding 255
+  characters if they have a unique index on them.
+"""
 from django.db import models
 from django.db import connection
 db_version = connection.get_server_version()
-if db_version < (5, 0, 3) and isinstance(f, (models.CharField, 
models.CommaSeparatedIntegerField, models.SlugField)) and f.max_length > 255:
-errors.add(opts,
-'"%s": %s cannot have a "max_length" greater than 255 when you 
are using a version of MySQL prior to 5.0.3 (you are using %s).' % 
-(f.name, f.__class__.__name__, '.'.join([str(n) for n in 
db_version[:3]])))
-
\ No newline at end of file
+varchar_fields = (models.CharField, models.CommaSeparatedIntegerField,
+models.SlugField)
+if isinstance(f, varchar_fields) and f.max_length > 255:
+if db_version < (5, 0, 3):
+msg = '"%(name)s": %(cls)s cannot have a "max_length" greater 
than 255 when you are using a version of MySQL prior to 5.0.3 (you are using 
%(version)s).'
+if f.unique == True:
+msg = '"%(name)s": %(cls)s cannot have a "max_length" greater 
than 255 when using "unique=True".'
+else:
+msg = None
+
+if msg:
+errors.add(opts, msg % {'name': f.name, 'cls': 
f.__class__.__name__, 'version': '.'.join([str(n) for n in db_version[:3]])})
+

Modified: django/branches/releases/1.0.X/docs/ref/databases.txt
===
--- django/branches/releases/1.0.X/docs/ref/databases.txt   2008-12-16 
06:48:15 UTC (rev 9651)
+++ django/branches/releases/1.0.X/docs/ref/databases.txt   2008-12-16 
06:49:43 UTC (rev 9652)
@@ -234,9 +234,12 @@
 
 .. _AlterModelOnSyncDB: http://code.djangoproject.com/wiki/AlterModelOnSyncDB
 
-Boolean fields in Django
--
+Notes on specific fields
+
 
+Boolean fields
+~~
+
 Since MySQL doesn't have a direct ``BOOLEAN`` column type, Django uses a
 ``TINYINT`` column with values of ``1`` and ``0`` to store values for the
 :class:`~django.db.models.BooleanField` model field. Refer to the documentation
@@ -244,6 +247,19 @@
 matter unless you're printing out the field values and are expecting to see
 ``True`` and ``False.``.
 
+Character fields
+
+
+Any fields that are stored with ``VARCHAR`` column types have their
+``max_length`` restricted to 255 characters if you are using ``unique=True``
+for the field. This affects :class:`~django.db.models.CharField`,
+:class:`~django.db.models.SlugField` and
+:class:`~django.db.models.CommaSeparatedIntegerField`.
+
+Furthermore, if you are using a version of MySQL prior to 5.0.3, all of those
+column types have a maximum length restriction of 255 characters, regardless
+of whether ``unique=True`` is specified or not.
+
 .. _sqlite-notes:
 
 SQLite notes 

Modified: django/branches/releases/1.0.X/docs/ref/models/fields.txt
===
--- django/branches/releases/1.0.X/docs/ref/models/fields.txt   2008-12-16 
06:48:15 UTC (rev 9651)
+++ django/branches/releases/1.0.X/docs/ref/models/fields.txt   2008-12-16 
06:49:43 UTC (rev 9652)
@@ -327,6 +327,13 @@
 The maximum length (in characters) of the field. The max_length is enforced
 at the database level and in Django's validation.
 
+.. note::
+
+If you are writing an application that must be portable to multiple
+database backends, you should be aware that there are restrictions on
+``max_length`` for some backends. Refer to the 

[Changeset] r9651 - django/branches/releases/1.0.X/tests/modeltests/lookup

[noreply]

Author: mtredinnick
Date: 2008-12-16 00:48:15 -0600 (Tue, 16 Dec 2008)
New Revision: 9651

Modified:
   django/branches/releases/1.0.X/tests/modeltests/lookup/models.py
Log:
[1.0.X] Removed one test that is only intended for PostgreSQL from the
visibility of other databases. This basically hides an annoying warning when
running the tests under MySQL.

Backport of r9469 from trunk.


Modified: django/branches/releases/1.0.X/tests/modeltests/lookup/models.py
===
--- django/branches/releases/1.0.X/tests/modeltests/lookup/models.py
2008-12-16 06:43:18 UTC (rev 9650)
+++ django/branches/releases/1.0.X/tests/modeltests/lookup/models.py
2008-12-16 06:48:15 UTC (rev 9651)
@@ -16,7 +16,7 @@
 def __unicode__(self):
 return self.headline
 
-__test__ = {'API_TESTS':r"""
+__test__ = {'API_TESTS': r"""
 # Create a couple of Articles.
 >>> from datetime import datetime
 >>> a1 = Article(headline='Article 1', pub_date=datetime(2005, 7, 26))
@@ -33,13 +33,18 @@
 >>> a6.save()
 >>> a7 = Article(headline='Article 7', pub_date=datetime(2005, 7, 27))
 >>> a7.save()
+"""}
 
+if settings.DATABASE_ENGINE in ('postgresql', 'postgresql_pysycopg2'):
+__test__['API_TESTS'] += r"""
 # text matching tests for PostgreSQL 8.3
 >>> Article.objects.filter(id__iexact='1')
 []
 >>> Article.objects.filter(pub_date__startswith='2005')
 [, , , , , , ]
+"""
 
+__test__['API_TESTS'] += r"""
 # Each QuerySet gets iterator(), which is a generator that "lazily" returns
 # results using database-level iteration.
 >>> for a in Article.objects.iterator():
@@ -383,7 +388,7 @@
 [, , , , ]
 >>> Article.objects.filter(headline__iregex=r'b.*ar')
 [, , , , ]
-"""}
+"""
 
 
 if settings.DATABASE_ENGINE != 'mysql':


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

[Changeset] r9650 - in django/trunk: django/db/backends/mysql docs/ref docs/ref/models

[noreply]

Author: mtredinnick
Date: 2008-12-16 00:43:18 -0600 (Tue, 16 Dec 2008)
New Revision: 9650

Modified:
   django/trunk/django/db/backends/mysql/validation.py
   django/trunk/docs/ref/databases.txt
   django/trunk/docs/ref/models/fields.txt
Log:
Fixed #9431 -- Added extra validation for VARCHAR-based fields on MySQL.
max_length > 255 and unique=True is not permitted. Based on a patch from
adamnelson.


Modified: django/trunk/django/db/backends/mysql/validation.py
===
--- django/trunk/django/db/backends/mysql/validation.py 2008-12-16 06:42:19 UTC 
(rev 9649)
+++ django/trunk/django/db/backends/mysql/validation.py 2008-12-16 06:43:18 UTC 
(rev 9650)
@@ -2,12 +2,27 @@
 
 class DatabaseValidation(BaseDatabaseValidation):
 def validate_field(self, errors, opts, f):
-"Prior to MySQL 5.0.3, character fields could not exceed 255 
characters"
+"""
+There are some field length restrictions for MySQL:
+
+- Prior to version 5.0.3, character fields could not exceed 255
+  characters in length.
+- No character (varchar) fields can have a length exceeding 255
+  characters if they have a unique index on them.
+"""
 from django.db import models
 from django.db import connection
 db_version = connection.get_server_version()
-if db_version < (5, 0, 3) and isinstance(f, (models.CharField, 
models.CommaSeparatedIntegerField, models.SlugField)) and f.max_length > 255:
-errors.add(opts,
-'"%s": %s cannot have a "max_length" greater than 255 when you 
are using a version of MySQL prior to 5.0.3 (you are using %s).' % 
-(f.name, f.__class__.__name__, '.'.join([str(n) for n in 
db_version[:3]])))
-
\ No newline at end of file
+varchar_fields = (models.CharField, models.CommaSeparatedIntegerField,
+models.SlugField)
+if isinstance(f, varchar_fields) and f.max_length > 255:
+if db_version < (5, 0, 3):
+msg = '"%(name)s": %(cls)s cannot have a "max_length" greater 
than 255 when you are using a version of MySQL prior to 5.0.3 (you are using 
%(version)s).'
+if f.unique == True:
+msg = '"%(name)s": %(cls)s cannot have a "max_length" greater 
than 255 when using "unique=True".'
+else:
+msg = None
+
+if msg:
+errors.add(opts, msg % {'name': f.name, 'cls': 
f.__class__.__name__, 'version': '.'.join([str(n) for n in db_version[:3]])})
+

Modified: django/trunk/docs/ref/databases.txt
===
--- django/trunk/docs/ref/databases.txt 2008-12-16 06:42:19 UTC (rev 9649)
+++ django/trunk/docs/ref/databases.txt 2008-12-16 06:43:18 UTC (rev 9650)
@@ -234,9 +234,12 @@
 
 .. _AlterModelOnSyncDB: http://code.djangoproject.com/wiki/AlterModelOnSyncDB
 
-Boolean fields in Django
--
+Notes on specific fields
+
 
+Boolean fields
+~~
+
 Since MySQL doesn't have a direct ``BOOLEAN`` column type, Django uses a
 ``TINYINT`` column with values of ``1`` and ``0`` to store values for the
 :class:`~django.db.models.BooleanField` model field. Refer to the documentation
@@ -244,6 +247,19 @@
 matter unless you're printing out the field values and are expecting to see
 ``True`` and ``False.``.
 
+Character fields
+
+
+Any fields that are stored with ``VARCHAR`` column types have their
+``max_length`` restricted to 255 characters if you are using ``unique=True``
+for the field. This affects :class:`~django.db.models.CharField`,
+:class:`~django.db.models.SlugField` and
+:class:`~django.db.models.CommaSeparatedIntegerField`.
+
+Furthermore, if you are using a version of MySQL prior to 5.0.3, all of those
+column types have a maximum length restriction of 255 characters, regardless
+of whether ``unique=True`` is specified or not.
+
 .. _sqlite-notes:
 
 SQLite notes 

Modified: django/trunk/docs/ref/models/fields.txt
===
--- django/trunk/docs/ref/models/fields.txt 2008-12-16 06:42:19 UTC (rev 
9649)
+++ django/trunk/docs/ref/models/fields.txt 2008-12-16 06:43:18 UTC (rev 
9650)
@@ -327,6 +327,13 @@
 The maximum length (in characters) of the field. The max_length is enforced
 at the database level and in Django's validation.
 
+.. note::
+
+If you are writing an application that must be portable to multiple
+database backends, you should be aware that there are restrictions on
+``max_length`` for some backends. Refer to the :ref:`database backend
+notes ` for details.
+
 .. admonition:: MySQL users
 
 If you are using this field with MySQLdb 1.2.2 and the ``utf8_bin``
@@ -341,7 +348,8 @@
 .. class:: CommaSeparatedIntegerField(max_length=None, [**options])
 
 A field of integers separated by 

[Changeset] r9649 - django/trunk/tests/modeltests/lookup

[noreply]

Author: mtredinnick
Date: 2008-12-16 00:42:19 -0600 (Tue, 16 Dec 2008)
New Revision: 9649

Modified:
   django/trunk/tests/modeltests/lookup/models.py
Log:
Removed one test that is only intended for PostgreSQL from the visibility of
other databases. This basically hides an annoying warning when running the
tests under MySQL.


Modified: django/trunk/tests/modeltests/lookup/models.py
===
--- django/trunk/tests/modeltests/lookup/models.py  2008-12-16 04:54:29 UTC 
(rev 9648)
+++ django/trunk/tests/modeltests/lookup/models.py  2008-12-16 06:42:19 UTC 
(rev 9649)
@@ -16,7 +16,7 @@
 def __unicode__(self):
 return self.headline
 
-__test__ = {'API_TESTS':r"""
+__test__ = {'API_TESTS': r"""
 # Create a couple of Articles.
 >>> from datetime import datetime
 >>> a1 = Article(headline='Article 1', pub_date=datetime(2005, 7, 26))
@@ -33,13 +33,18 @@
 >>> a6.save()
 >>> a7 = Article(headline='Article 7', pub_date=datetime(2005, 7, 27))
 >>> a7.save()
+"""}
 
+if settings.DATABASE_ENGINE in ('postgresql', 'postgresql_pysycopg2'):
+__test__['API_TESTS'] += r"""
 # text matching tests for PostgreSQL 8.3
 >>> Article.objects.filter(id__iexact='1')
 []
 >>> Article.objects.filter(pub_date__startswith='2005')
 [, , , , , , ]
+"""
 
+__test__['API_TESTS'] += r"""
 # Each QuerySet gets iterator(), which is a generator that "lazily" returns
 # results using database-level iteration.
 >>> for a in Article.objects.iterator():
@@ -383,7 +388,7 @@
 [, , , , ]
 >>> Article.objects.filter(headline__iregex=r'b.*ar')
 [, , , , ]
-"""}
+"""
 
 
 if settings.DATABASE_ENGINE != 'mysql':


--~--~-~--~~~---~--~~
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] #9862: Non-standard SQL generated in column definition for nullable columns in create table DDL

[Django]

#9862: Non-standard SQL generated in column definition for nullable columns in
create table DDL
-+--
   Reporter:  Ambrish|Owner:  nobody
 Status:  new|Milestone:
  Component:  Uncategorized  |  Version:  1.0   
   Keywords: |Stage:  Unreviewed
  Has_patch:  0  |   Needs_docs:  0 
Needs_tests:  0  |   Needs_better_patch:  0 
-+--
 Hi,

 While doing backend testing for new DB2 adapter (I am developing it), I
 found that in CREATE TABLE DDL generation, it contains some non-standard
 SQL syntax.

 Here is one example of model.

 {{{
 class User(models.Model):
 first_name = models.CharField(max_length=20, null=False)
 last_name = models.CharField(max_length=20, null=True)

 class Meta:
 db_table = "temp_user"
 }}}

 For the column '''last_name''', the SQL that gets generated is
 '''LAST_NAME VARCHAR(20) NULL'''. The trailing '''NULL''' is not a
 standard SQL. This can be validated by the SQL validator tool -
 http://developer.mimer.com/validator/parser200x/index.tml Needless to say,
 this will fail in DB2 and so too in Oracle.


 I find only one method in the docs which deals with the table DDL
 generation '''BaseDatabaseCreation.sql_create_model'''.

 Regards,[[BR]]
 Ambrish Bhargava

-- 
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] #5171: postgresql_psycopg2 backend registers psycopg2's UNICODE extension, which can cause interference if Django is not the only component using psycopg2

[Django]

#5171: postgresql_psycopg2 backend registers psycopg2's UNICODE extension, which
can cause interference if Django is not the only component using psycopg2
---+
  Reporter:  Chris Wagner   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  wontfix   |  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 The SQLAlchemy ticket referenced in comment:7 has a workaround for
 SQLAlchemy and some strong agreement that this is a psycopg2 bug. Closing
 as wontfix for the reasons given in previous comments.

 (Jacob, reopen if you have any really good ideas on a workaround, but I
 don't see this as our problem at the moment; good citizenship works both
 and SQLAlchemy have a workaround for the problem on their side.)

-- 
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] #9525: It should be possible to disable the creation of database key constraints in ForeignKey Field

[Django]

#9525: It should be possible to disable the creation of database key  
constraints
in ForeignKey Field
---+
  Reporter:  mohlendo  | Owner:  nobody  
Status:  closed| Milestone:  post-1.0
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  wontfix   |  Keywords:  
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 I think that if you want to do this, you should create a special field to
 do so. A `ForeignKey` is traditionally understood as modelling a many-to-
 one relation, not many-to-many, and that's certainly the case in Django.
 Extending the meaning beyond that would confuse things a bit.

 It's an interesting idea, but not really how a database models things, so
 you will need to do some manual validation in your custom field to ensure
 data integrity.

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

[Changeset] r9648 - in django/branches/releases/1.0.X: django/db/models/fields tests/regressiontests/file_storage

[noreply]

Author: mtredinnick
Date: 2008-12-15 22:54:29 -0600 (Mon, 15 Dec 2008)
New Revision: 9648

Added:
   django/branches/releases/1.0.X/tests/regressiontests/file_storage/test1.png
Modified:
   django/branches/releases/1.0.X/django/db/models/fields/files.py
   django/branches/releases/1.0.X/tests/regressiontests/file_storage/models.py
Log:
[1.0.X] Fixed #9786 -- Fixed inequality checking for 
django.db.models.fields.file.FieldFile class.

Backport of r9647 from trunk.


Modified: django/branches/releases/1.0.X/django/db/models/fields/files.py
===
--- django/branches/releases/1.0.X/django/db/models/fields/files.py 
2008-12-16 04:52:55 UTC (rev 9647)
+++ django/branches/releases/1.0.X/django/db/models/fields/files.py 
2008-12-16 04:54:29 UTC (rev 9648)
@@ -29,6 +29,9 @@
 return self.name == other.name
 return self.name == other
 
+def __ne__(self, other):
+return not self.__eq__(other)
+
 # The standard File contains most of the necessary properties, but
 # FieldFiles can be instantiated without a name, so that needs to
 # be checked for here.

Modified: 
django/branches/releases/1.0.X/tests/regressiontests/file_storage/models.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/file_storage/models.py 
2008-12-16 04:52:55 UTC (rev 9647)
+++ django/branches/releases/1.0.X/tests/regressiontests/file_storage/models.py 
2008-12-16 04:54:29 UTC (rev 9648)
@@ -22,12 +22,12 @@
 if Image:
 class Person(models.Model):
 name = models.CharField(max_length=50)
-mugshot = models.ImageField(storage=temp_storage, upload_to='tests', 
-height_field='mug_height', 
+mugshot = models.ImageField(storage=temp_storage, upload_to='tests',
+height_field='mug_height',
 width_field='mug_width')
 mug_height = models.PositiveSmallIntegerField()
 mug_width = models.PositiveSmallIntegerField()
-
+
 __test__ = {'API_TESTS': """
 
 >>> image_data = open(os.path.join(os.path.dirname(__file__), "test.png"), 
 >>> 'rb').read()
@@ -42,6 +42,18 @@
 >>> p.mug_width
 16
 
+# Bug #9786: Ensure '==' and '!=' work correctly.
+>>> image_data = open(os.path.join(os.path.dirname(__file__), "test1.png"), 
'rb').read()
+>>> p1 = Person(name="Bob")
+>>> p1.mugshot.save("mug", ContentFile(image_data))
+>>> p2 = Person.objects.get(name="Joe")
+>>> p.mugshot == p2.mugshot
+True
+>>> p.mugshot != p2.mugshot
+False
+>>> p.mugshot != p1.mugshot
+True
+
 # Bug #8175: correctly delete files that have been removed off the file system.
 >>> import os
 >>> p2 = Person(name="Fred")
@@ -69,4 +81,4 @@
 
 >>> shutil.rmtree(temp_storage_dir)
 """}
-
\ No newline at end of file
+

Added: 
django/branches/releases/1.0.X/tests/regressiontests/file_storage/test1.png
===
--- django/branches/releases/1.0.X/tests/regressiontests/file_storage/test1.png 
(rev 0)
+++ django/branches/releases/1.0.X/tests/regressiontests/file_storage/test1.png 
2008-12-16 04:54:29 UTC (rev 9648)
@@ -0,0 +1,6 @@
+�PNG
+
+
+IHDR��h6
sRGB���
�IDAT(�clH(�tc 
l9��X�Ȅ&΄U�?��3=,�<���k��m��V
+���g���?ß? ��ǿ���g``���
+�8�8�5���o���kn~��-�~Z��Ǝ�aɞ5�7.`af 
����_�s����~���6'm9!�#<�/���aٞ���b```��z(���AIRT 
4��200�z=�`f�;)�ѯu�-�w_�{M���ן�
?~?33�...@of&��{��{��맜��bR�^=a``���bea�~V~V��/3˿���f�000���8FFFfs�#S�K0BW⃤��'vˋ������D$�d��j`fb֔S�G�+�M�R�$IEND�B`�
\ No newline at end of file


--~--~-~--~~~---~--~~
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] #9786: Files (and subclasses) override __eq__ but not __ne__

[Django]

#9786: Files (and subclasses) override __eq__ but not __ne__
-+--
  Reporter:  xtian   | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Database layer (models, ORM)|   Version:  SVN   
Resolution:  fixed   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

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

Comment:

 Fixed in r9647.

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

[Changeset] r9647 - in django/trunk: django/db/models/fields tests/regressiontests/file_storage

[noreply]

Author: mtredinnick
Date: 2008-12-15 22:52:55 -0600 (Mon, 15 Dec 2008)
New Revision: 9647

Added:
   django/trunk/tests/regressiontests/file_storage/test1.png
Modified:
   django/trunk/django/db/models/fields/files.py
   django/trunk/tests/regressiontests/file_storage/models.py
Log:
Fixed #9786 -- Fixed inequality checking for 
django.db.models.fields.file.FieldFile class.


Modified: django/trunk/django/db/models/fields/files.py
===
--- django/trunk/django/db/models/fields/files.py   2008-12-14 19:31:26 UTC 
(rev 9646)
+++ django/trunk/django/db/models/fields/files.py   2008-12-16 04:52:55 UTC 
(rev 9647)
@@ -29,6 +29,9 @@
 return self.name == other.name
 return self.name == other
 
+def __ne__(self, other):
+return not self.__eq__(other)
+
 # The standard File contains most of the necessary properties, but
 # FieldFiles can be instantiated without a name, so that needs to
 # be checked for here.

Modified: django/trunk/tests/regressiontests/file_storage/models.py
===
--- django/trunk/tests/regressiontests/file_storage/models.py   2008-12-14 
19:31:26 UTC (rev 9646)
+++ django/trunk/tests/regressiontests/file_storage/models.py   2008-12-16 
04:52:55 UTC (rev 9647)
@@ -22,12 +22,12 @@
 if Image:
 class Person(models.Model):
 name = models.CharField(max_length=50)
-mugshot = models.ImageField(storage=temp_storage, upload_to='tests', 
-height_field='mug_height', 
+mugshot = models.ImageField(storage=temp_storage, upload_to='tests',
+height_field='mug_height',
 width_field='mug_width')
 mug_height = models.PositiveSmallIntegerField()
 mug_width = models.PositiveSmallIntegerField()
-
+
 __test__ = {'API_TESTS': """
 
 >>> image_data = open(os.path.join(os.path.dirname(__file__), "test.png"), 
 >>> 'rb').read()
@@ -42,6 +42,18 @@
 >>> p.mug_width
 16
 
+# Bug #9786: Ensure '==' and '!=' work correctly.
+>>> image_data = open(os.path.join(os.path.dirname(__file__), "test1.png"), 
'rb').read()
+>>> p1 = Person(name="Bob")
+>>> p1.mugshot.save("mug", ContentFile(image_data))
+>>> p2 = Person.objects.get(name="Joe")
+>>> p.mugshot == p2.mugshot
+True
+>>> p.mugshot != p2.mugshot
+False
+>>> p.mugshot != p1.mugshot
+True
+
 # Bug #8175: correctly delete files that have been removed off the file system.
 >>> import os
 >>> p2 = Person(name="Fred")
@@ -69,4 +81,4 @@
 
 >>> shutil.rmtree(temp_storage_dir)
 """}
-
\ No newline at end of file
+

Added: django/trunk/tests/regressiontests/file_storage/test1.png
===
--- django/trunk/tests/regressiontests/file_storage/test1.png   
(rev 0)
+++ django/trunk/tests/regressiontests/file_storage/test1.png   2008-12-16 
04:52:55 UTC (rev 9647)
@@ -0,0 +1,6 @@
+�PNG
+
+
+IHDR��h6
sRGB���
�IDAT(�clH(�tc 
l9��X�Ȅ&΄U�?��3=,�<���k��m��V
+���g���?ß? ��ǿ���g``���
+�8�8�5���o���kn~��-�~Z��Ǝ�aɞ5�7.`af 
����_�s����~���6'm9!�#<�/���aٞ���b```��z(���AIRT 
4��200�z=�`f�;)�ѯu�-�w_�{M���ן�
?~?33�...@of&��{��{��맜��bR�^=a``���bea�~V~V��/3˿���f�000���8FFFfs�#S�K0BW⃤��'vˋ������D$�d��j`fb֔S�G�+�M�R�$IEND�B`�
\ No newline at end of file


--~--~-~--~~~---~--~~
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] #9578: order_by() removing select_related() joined tables when with extra() query sets

[Django]

#9578: order_by() removing select_related() joined tables when with extra() 
query
sets
---+
  Reporter:  marinho   | Owner:  mtredinnick
Status:  closed| Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  1.0
Resolution:  invalid   |  Keywords: 
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 No new information provided, so I'm closing this. Please reopen if the
 information requested in the previous comment can be provided, but, at the
 moment, this appears to be a bug in usage, not in 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-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] #9861: Requests make feature: Using a subset of fields on the Model

[Django]

#9861: Requests make feature:  Using a subset of fields on the Model
---+
  Reporter:  freeren   | Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:  wontfix   |  Keywords:  Using a 
subset of fields on the Model
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 This isn't a common enough requirement to justify all the extra code it
 would require. The solution is to just create a separate model that
 contains the fields you need and set the `Meta.db_table` attribute to
 point to the other model's database table. You'll also need the support
 from #3163 (unless you avoid running syncdb for that app), but that should
 be in before Django 1.1 is released.

-- 
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] #3163: [patch] Optionally disable DB table creation from model

[Django]

#3163: [patch] Optionally disable DB table creation from model
---+
  Reporter:  wolfram.kries...@gmail.com| Owner:  
mtredinnick  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  raw SQL 
view readonly
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * owner:  nobody => mtredinnick
  * status:  reopened => new

-- 
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] #9861: Requests make feature: Using a subset of fields on the Model

[Django]

#9861: Requests make feature:  Using a subset of fields on the Model
---+
 Reporter:  freeren|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Database layer (models, ORM)   | Version:  SVN   
 Keywords:  Using a subset of fields on the Model  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The classes inheritance are useful when you want to put some common
 information into a number of other models.


 {{{
 class FlatPage(models.Model):
 url = models.CharField(_('URL'), max_length=100, db_index=True)
 title = models.CharField(_('title'), max_length=200)
 content = models.TextField(_('content'), blank=True)
 enable_comments = models.BooleanField(_('enable comments'))
 template_name = models.CharField(_('template name'), max_length=70,
 blank=True,
 help_text=_("Example: 'flatpages/contact_page.html'.
 If this isn't provided, the system will use 'flatpages/default.html'."))
 registration_required = models.BooleanField(_('registration
 required'), help_text=_("If this is checked, only logged-in users will be
 able to view the page."))
 sites = models.ManyToManyField(Site)


 class SubFlatPage(models.Model):
 url = models.CharField(_('URL'), max_length=100, db_index=True)
 title = models.CharField(_('title'), max_length=200)
 content = models.TextField(_('content'), blank=True)
 sites = models.ManyToManyField(Site)
 other = models.CharField(_('other'), max_length=200)
 }}}


 Using a subset of fields on the model (abstract=True OR abstract=False )
 like :
 [http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-a
 -subset-of-fields-on-the-form]


 # Use the fields attribute of the Model's inner Meta class. This
 attribute, if given, should be a list of field names to include in the
 SubModel.


 # Use the exclude attribute of the Model's inner Meta class. This
 attribute, if given, should be a list of field names to exclude from the
 SubModel.


 # Can append a little other fields.

-- 
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] #9806: GeometryField crashes contrib.gis.admin

[Django]

#9806: GeometryField crashes contrib.gis.admin
-+--
  Reporter:  ingenieroariel  | Owner:  jbronn   
Status:  new | Milestone:   
 Component:  GIS |   Version:  1.0  
Resolution:  |  Keywords:  admin, gis, GeometryField
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by ingenieroariel):

 Here is a workaround that makes the admin load up but does not render the
 feature.
 In the following file
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/gis/admin/options.py#L84
 gs/admin/options.py]

 Before:
 {{{
 params = {
   ...
  'geom_type' : OGRGeomType(db_field._geom),
   ...
 }
 }}}
 After
 {{{
 #OGRGeomType crashes for 'GEOMETRY' type.
 #It'd be better if we found a way to get the geom type of the
 instance, but there
 #does not seem to be an easy way to accomplish that.
 try:
geom_type=OGRGeomType(db_field._geom)
 except:
geom_type=OGRGeomType('Unknown')
 params = {
   ...
  'geom_type' : geom_type,
   ...
 }
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #4979: Admin does not allow removal of an image from an ImageField after it has been set, even if null=True and blank=True

[Django]

#4979: Admin does not allow removal of an image from an ImageField after it has
been set, even if null=True and blank=True
---+
  Reporter:  robvdl| Owner:  nobody
Status:  reopened  | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:  ImageField
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Daniel Pope ):

  * needs_better_patch:  1 => 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
-~--~~~~--~~--~--~---

Re: [Django] #4979: Admin does not allow removal of an image from an ImageField after it has been set, even if null=True and blank=True

[Django]

#4979: Admin does not allow removal of an image from an ImageField after it has
been set, even if null=True and blank=True
---+
  Reporter:  robvdl| Owner:  nobody
Status:  reopened  | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:  ImageField
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Changes (by Daniel Pope ):

  * needs_better_patch:  0 => 1
  * has_patch:  0 => 1

Comment:

 I've added an initial patch - needs a bit of cleaning up as I've made a
 bit of a mess wrt PEP8 so I will reupload in a moment.

 In this patch I've taken the approach of False indicating a file
 explicitly unset, None indicating no new value. I don't particularly like
 that approach, but {{{FileField}}} is special-cased at the model, form and
 form field level so it defaults to preserving the current value. A cleaner
 approach might be to remove the special case that makes it default to
 preserving a value, and have {{{FileField}}} explicitly return the same
 file. But that would mean more upheaval, less compatibility.

-- 
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] #9860: Tutorial part 3: decoupling the urlconfs

[Django]

#9860: Tutorial part 3: decoupling the urlconfs
+---
  Reporter:  Qays Poonawala   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 Closing as a dupe of #9767(http://code.djangoproject.com/ticket/9767) feel
 free to follow this down the rabbit hole.

-- 
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:  nobody
Status:  new   | 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 mmoedt):

 * cc: mmo...@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-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] #9860: Tutorial part 3: decoupling the urlconfs

[Django]

#9860: Tutorial part 3: decoupling the urlconfs
+---
  Reporter:  Qays Poonawala   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Qays Poonawala ):

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

Comment:

 URL: http://docs.djangoproject.com/en/dev/intro/tutorial03/#decoupling-
 the-urlconfs

-- 
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] #9860: Tutorial part 3: decoupling the urlconfs

[Django]

#9860: Tutorial part 3: decoupling the urlconfs
---+
 Reporter:  Qays Poonawala   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The second green code box contains the line

 urlpatterns = patterns('mysite.polls.views',

 I think this should have the "mysite." part removed, as that would funny
 decouple the URL Confs.

-- 
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] #9859: UnicodeDecodeError in admin views for python 2.3.

[Django]

#9859: UnicodeDecodeError in admin views for python 2.3.
+---
 Reporter:  nfg |   Owner:  nobody
   Status:  new |   Milestone:
Component:  django.contrib.admin| Version:  SVN   
 Keywords:  unicode unicodedecodeerror  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 Because I work in a company that uses python 2.3 on the production server
 and because I use characters outside the ascii range, I have run onto a
 number of UnicodeDecodeErrors. Python 2.3 unfortunately has a bug, it
 calls __str__ methods on objects included in unicode template strings even
 if the object has a __unicode__ method.

 Now I have run onto another one. It was a quick fix to solve this, but it
 was more difficult to make a regression test for it. This bug is only
 triggered if a model is registered as a inline, but not registered
 directly with the admin.

 To help fight UnicodeDecodeErrors I have made a new TestCase class in the
 admin_views regression test with the sole purpose of detecting missing
 force_unicode calls in the admin views.

-- 
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] #689: Honor Web server provided authentication

[Django]

#689: Honor Web server provided authentication
+---
  Reporter:  i...@holsman.net| Owner:  telenieko
Status:  assigned   | Milestone:   
 Component:  Core framework |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Ready for checkin  | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

 * cc: m...@mylesbraithwaite.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-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] #8585: InterfaceError with MySQLdb set_character_set

[Django]

#8585: InterfaceError with MySQLdb set_character_set
---+
  Reporter:  khsing| Owner:  nobody
Status:  closed| Milestone:  1.0   
 Component:  django.contrib.admin  |   Version:  1.0-beta-1
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by subsume):

 Its a general python problem with mysql 5.0

 http://bugs.mysql.com/bug.php?id=21543

-- 
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] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
-+--
  Reporter:  jarrow  | Owner:  nobody   

Status:  new | Milestone:  post-1.0 

 Component:  django.contrib.admin|   Version:  newforms-admin   

Resolution:  |  Keywords:  nfa-someday 
yandex-sprint
 Stage:  Design decision needed  | Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

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

 * cc: niels.bu...@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-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] #9855: SetFromUserInput is not available to SpatialReference

[Django]

#9855: SetFromUserInput is not available to SpatialReference
-+--
  Reporter:  hobu| Owner:  jbronn  
Status:  assigned| Milestone:  post-1.0
 Component:  GIS |   Version:  1.0 
Resolution:  |  Keywords:  gdal srs
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Old description:

> Input that is not recognized by SpatialReference's __init__ should be
> attempted to be passed to SetFromUserInput to see if GDAL can recognize
> it.  GDAL can recognize much more input than the __init__ currently
> checks for, like URNs, URLs, and miscellaneous types of SRS's.

New description:

 Input that is not recognized by `SpatialReference`'s `__init__` should be
 attempted to be passed to `OSRSetFromUserInput` to see if GDAL can
 recognize it.  GDAL can recognize much more input than the `__init__`
 currently checks for, like URNs, URLs, and miscellaneous types of SRS's.

-- 
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] #9855: SetFromUserInput is not available to SpatialReference

[Django]

#9855: SetFromUserInput is not available to SpatialReference
-+--
  Reporter:  hobu| Owner:  jbronn  
Status:  assigned| Milestone:  post-1.0
 Component:  GIS |   Version:  1.0 
Resolution:  |  Keywords:  gdal srs
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

  * status:  new => assigned

Comment:

 When the GDAL lib is refactored for 1.1, this will be incorporated to
 simplify `SpatialReference` initialization.  ''See''
 [http://geodjango.org/hg/gis-1.1/rev/edd876f3bc87 this changeset] for what
 the implementation will look like.

-- 
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] #9858: pg test database not created with postgis template, tests fail

[Django]

#9858: pg test database not created with postgis template, tests fail
+---
  Reporter:  Aryeh Leib Taurog   | Owner:  
jbronn 
Status:  new| Milestone:
 
 Component:  GIS|   Version:  
1.0
Resolution: |  Keywords:  
test template_postgis create_spatial_db
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by jbronn):

  * owner:  nobody => jbronn
  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I ran into the problem as well this weekend when I tested the updated
 !GeoDjango installer (with 1.0.2) on Windows -- so it's a confirmed new
 issue (thanks for creating a ticket).  I came up with a similar patch that
 just assumed the existence of a PostGIS template -- but I like the idea of
 the `POSTGIS_TEMPLATE` setting more, and it could reduce some of that
 crufty spatial db creation code from the PostGIS spatial backend.

 I'm still wondering, however, why it ceased to work as it used to in my
 previous Windows VM.

-- 
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] #8138: Switch django tests to use transactions

[Django]

#8138: Switch django tests to use transactions
+---
  Reporter:  mremolt| Owner:  nobody  
Status:  new| Milestone:  post-1.0
 Component:  Testing framework  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 I actually think it should be relatively easy for developers to know that
 what they are testing requires working transaction methods. You need, for
 example, to be testing that in a sequence of n updates where some will
 succeed but ultimately a failure will be encountered causing the whole set
 to be rolled back, to be testing to make sure that some of the initial DB
 updates that were made were actually rolled back by the subsequent
 failure.  This sort of test will not be able to work with the do-nothing
 transaction routines, it would have to use !TransactionTestCase to run
 successfully, and I think the failure when run under a simple !TestCase
 would be pretty obvious.

 As for commit, I think it would be relatively hard to write a test that
 will notice an expected commit has not been done, since you'd have to
 somehow do a query from outside the context of the test case transaction
 to be able to tell that what would ordinarily have been committed by the
 code under test hasn't actually been committed yet.

 I also think it's pretty nice to be able to get the speedup offered by the
 rollback test approach even for code under test that calls transaction
 routines, when in fact the tests don't need those routines to be
 functional in order to correctly test what they are intending to test.
 The admin views fall into this category.  The edit view, for example, is
 wrapped in commit_on_success, which if running on a transaction-supporting
 database provides a nice all-or-nothing guarantee for, say, multiple
 updates to inine-edited objects.  But we don't have any tests for that
 guarantee (they would necessarily fail on MySQL/MyISAM).  So as far as the
 admin_views tests are concerned any commits/rollbacks done by the code
 under test aren't critical to the proper functioning of the test.  It
 would seem a shame to require these tests to take the performance hit of
 having to use the flush/load test approach simply because admin provides
 the all-or-nothing behavior when run on a transaction-supporting DB.

 So it seems the more I think about it the more I like the monkey-patching
 approach, personally.  (I am perhaps being unduly influenced by being able
 to run the full Django test suite on one of my machines now in under 10
 minutes where before near an hour was the minimum...and under and hour
 even on my very slow old test machines where before a day or overnight run
 was required.)

 I'll be around over the holidays but won't have much time free since I'll
 have family visiting.  If you (or anyone) could figure out the PostgreSQL
 time issue that would be a good thing to fully understand before moving
 forward with this.  Also if there's a more elegant way to test for "the DB
 rollback works" and what the consequences of it not working are w.r.t.
 !DoctTests.  Is what's in the patch I attached last night equivalent to
 the old approach when run on a non-transaction-supporting DB given that
 the fixture loading for unit tests will flush/reload, making it no big
 deal that the rollback after a !DocTest run does nothing?  The old
 approach didn't appear to bracket !DocTests with any sort of DB
 flush/reload so maybe thing are OK there, but I didn't pay a whole lot of
 attention to the !DocTest bits as I was looking at this since most of the
 errors I was hitting had to do with unit tests.

-- 
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] #7124: Form field javascript event handler

[Django]

#7124: Form field javascript event handler
-+--
  Reporter:  MihaiD  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  wontfix |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 ok, i'm convinced now :)  - i was carried away by my experience with
 generic CSS-selector-based behaviors, so i missed that obvious simpler and
 indeed optimizable case. sorry for the noise...

-- 
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] #1142: Support for multiple database connections

[Django]

#1142: Support for multiple database connections
---+
  Reporter:  Simon Willison| Owner:  
darylspitzer 
Status:  assigned  | Milestone:  post-1.0   
  
 Component:  Database layer (models, ORM)  |   Version: 
  
Resolution:|  Keywords:  multiple 
database feature
 Stage:  Someday/Maybe | Has_patch:  1  
  
Needs_docs:  1 |   Needs_tests:  0  
  
Needs_better_patch:  1 |  
---+
Changes (by anonymous):

 * cc: jb0t (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] #7124: Form field javascript event handler

[Django]

#7124: Form field javascript event handler
-+--
  Reporter:  MihaiD  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  wontfix |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by lukeplant):

 My example should have been {{{$("#id_email")}}} of course, which I'm sure
 jQuery will optimise into a simple {{{document.getElementById()}}} without
 doing any DOM traversal.  Or you can do this yourself, without the jQuery
 dependence. Either way, I'm sure it can't take 5 sec no matter the size of
 the document.  If you want designers to be able to do this by just editing
 templates, your options are:

  * Use the above method of adding event handlers using
 {{{document.getElementById()}}} (or some wrapper, like jQuery).
  * Don't use Django to render the entire form -- render it field by field
 in the template, overriding with custom HTML as necessary.
  * Some complex template tag that allows you to add "onchange" handlers to
 a form field from within the template.  This would likely be very messy,
 and not actually designer friendly.

 This discussion is straying from the feature request first given in the
 bug, of course -- adding event handler attributes in Python code is
 already supported by {{{attrs}}}, and won't help your use case.  If you
 have a more concrete suggestion about how to better support adding event
 handlers in the template, it would be best to open another 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-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] #7124: Form field javascript event handler

[Django]

#7124: Form field javascript event handler
-+--
  Reporter:  MihaiD  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  wontfix |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 i absolutely agree with you that dynamically attaching event handlers
 *should* be the way to go in most cases - BUT: on some lightweight client
 devices e.g. mobile phones, traversing the DOM with jquery et al can be
 prohibitively expensive for more complex documents (e.g. 5 sec ui freeze
 on iphone for a html doc with a 300 elements). while in these cases the
 workaround as pointed out by you can be applied, defining the event
 handler is clearly a task of the frontend designer (at least in our
 workflow) so it should be possible to do it in the template.

 i can absolutely understand that there are more important things to do,
 but just wanted to provide a real-life usecase for this request for the
 record.

-- 
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] #7124: Form field javascript event handler

[Django]

#7124: Form field javascript event handler
-+--
  Reporter:  MihaiD  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  wontfix |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by lukeplant):

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

Comment:

 The "workaround" mentioned is the way that most modern javascript toolkits
 work (and similar to how Django's admin widgets work).  The "unobtrusive
 javascript" they support is superior to inline event handlers in many
 ways, but especially when you come to needing more than one event handler.
 Encouraging this way of programming seems like a step backwards,
 especially as it means you will have multiple places to look for finding
 javascript.  Using most toolkits, you would be able to hook up the event
 handlers by adding a bit of javascript code into your template with very
 little code, e.g. jQuery:

 {{{
 #!javascript
 jQuery(function(event) {
   // this function will run when the document is ready
   $("id_email").change(function () {
  // this will run when input with id = "id_email" is changed.
  // do something here
   });
 });
 }}}

 Since you can already add the "onchange" etc attributes if you really want
 to (using "attrs" as mentioned above), I'm closing as WONTFIX.

-- 
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] #9858: pg test database not created with postgis template, tests fail

[Django]

#9858: pg test database not created with postgis template, tests fail
-+--
 Reporter:  Aryeh Leib Taurog |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  GIS  | Version:  1.0   
 Keywords:  test template_postgis create_spatial_db  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 After setting up geodjango with PostgreSQL 8.3, PostGIS 1.3.3, and the
 win32 geodjango installer, an attempt to run the gis tests fails.

 I am using the django 1.0.2 release (and geodjango code included
 therewith) under Python 2.5 on Win XP Pro

 The source of the error seems to be that the addgeometrycolumn procedure
 does not exist in the test database.

 from settings.py:
 {{{
 #!python
 TEST_RUNNER = 'django.contrib.gis.tests.run_gis_tests'
 POSTGIS_SQL_PATH= 'D:/generic/PostgreSQL/8.3/share/contrib'
 }}}

 from test output:
 {{{
 Installing custom SQL for geoapp.Country model
 Failed to install custom SQL for geoapp.Country model: function
 addgeometrycolumn(unknown, unknown, integer, unknown, integer) does not
 exist
 LINE 1: SELECT AddGeometryColumn('geoapp_country', 'mpoly', 4326, 'M...
^
 HINT:  No function matches the given name and argument types. You might
 need to add explicit type casts.

 }}}

 complete log file attached.

 The geodjango docs state that a spacial database is created using the
 template template_postgis.  In tracing the error noted above, I discovered
 that the test database is created with no template.  This seems to account
 for the missing procedure.

 I patched
 
source:django/tags/releases/1.0.2/django/contrib/gis/db/backend/postgis/creation.py
 with a modified '''_create_with_cursor''', called by
 '''create_spatial_db''', using a new setting to specify the template name.
 It seems to me that '''get_cmd_options''' should similarly be modified.

 The tests are successful with my patch applied (log file attached)

 I'm perplexed to find no mention of this anywhere.  Is there something I'm
 missing?  Does the gis test work for everyone else without using the
 template?

-- 
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] #7124: Form field javascript event handler

[Django]

#7124: Form field javascript event handler
-+--
  Reporter:  MihaiD  | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by lederm...@ims.tuwien.ac.at):

 my 2 cents here: the javascript event handler can be part of the
 presentation layer (e.g. eyecandy) OR the application (e.g. validation)
 here, so it should be possible to add the event handler in the template OR
 in the view code.

-- 
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] #9855: SetFromUserInput is not available to SpatialReference

[Django]

#9855: SetFromUserInput is not available to SpatialReference
-+--
  Reporter:  hobu| Owner:  jbronn  
Status:  new | Milestone:  post-1.0
 Component:  GIS |   Version:  1.0 
Resolution:  |  Keywords:  gdal srs
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

  * keywords:  => gdal srs
  * owner:  nobody => jbronn
  * milestone:  => post-1.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
-~--~~~~--~~--~--~---

Re: [Django] #9676: Explicit default managers

[Django]

#9676: Explicit default managers
---+
  Reporter:  mrts  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  1 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by mrts):

 Perhaps it is better to just make `objects` the (overrideable) default
 manager as suggested in http://groups.google.com/group/django-
 developers/browse_thread/thread/480fe23f12e55cf7 . I.e. the concept needs
 a little thought, care and love.

-- 
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] #5610: Useful for dumpdata to be able to use a specific model

[Django]

#5610: Useful for dumpdata to be able to use a specific model
--+-
  Reporter:  DavidReynolds| Owner:  DavidReynolds  
Status:  new  | Milestone: 
 Component:  django-admin.py  |   Version:  SVN
Resolution:   |  Keywords:  sprintdec01 feature
 Stage:  Accepted | Has_patch:  1  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by DavidReynolds):

 Updated to work against r9646

-- 
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] #8055: Transaction error when doing loaddata

[Django]

#8055: Transaction error when doing loaddata
+---
  Reporter:  Erik Allik   | Owner:  nobody  
Status:  reopened   | Milestone:  post-1.0
 Component:  Serialization  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by tom_payne):

 Oh, sorry, no version number. This is the case for 1.0.2 final

-- 
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] #6588: Admin interface doesn't allow to use dots in usernames

[Django]

#6588: Admin interface doesn't allow to use dots in usernames
-+--
  Reporter:  anonymous   | Owner:  nobody
Status:  new | Milestone:
 Component:  django.contrib.admin|   Version:  newforms-admin
Resolution:  |  Keywords:  nfa-someday   
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by bronger):

  * needs_better_patch:  1 => 0

Comment:

 I appended the "$" to the regexp, and fixed to minor errors in the
 docstrings of the patch.

-- 
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] #6588: Admin interface doesn't allow to use dots in usernames

[Django]

#6588: Admin interface doesn't allow to use dots in usernames
-+--
  Reporter:  anonymous   | Owner:  nobody
Status:  new | Milestone:
 Component:  django.contrib.admin|   Version:  newforms-admin
Resolution:  |  Keywords:  nfa-someday   
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Changes (by bronger):

  * needs_better_patch:  0 => 1

Comment:

 The new regex in the patch needs a trailing $.

-- 
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] #8055: Transaction error when doing loaddata

[Django]

#8055: Transaction error when doing loaddata
+---
  Reporter:  Erik Allik   | Owner:  nobody  
Status:  reopened   | Milestone:  post-1.0
 Component:  Serialization  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by tom_payne):

 Well, I've had this problem again and have traced the error...

 I was trying to insert null values into my booleanfield (which I shouldn't
 be doing - that's what NullBooleanField is for - see #5563), but I think
 it's more a question of raising any error like this.

 Essentially, the bug is that you don't get a nice error message telling
 you what's wrong, rather you get an irrelevant Transaction error because
 the proper error message raises an exception.

 The problem comes when this error is raised in loaddata.py
 (django/core/management/commands/loaddata.py). The except clause (line 124
 onwards) tries to print an error message using traceback.format_exc, but
 this needs to be traceback.format_exception(sys.exc_type, sys.exc_value,
 sys.exc_traceback). The _exc shortcut, IIRC, is only available to
 print_exc.

 I hope that's clear.

 Tom

-- 
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] #8138: Switch django tests to use transactions

[Django]

#8138: Switch django tests to use transactions
+---
  Reporter:  mremolt| Owner:  nobody  
Status:  new| Milestone:  post-1.0
 Component:  Testing framework  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by mremolt):

 Replying to [comment:18 kmtracey]:
 > I've looked at this a little more and figured out a few things.
 >
 > Disconnecting `close_connection` from from `request_finished` solves
 this problem, so that tests that use the test Client do not automatically
 need to use the old way, and may take advantage of the rollback approach.
 In the patch I'll attach the signal is disconnected/reconnected around the
 sending of the signal...this is probably overkill.  I think it would be OK
 to just disconnect `close_connection` from that signal once and be done
 with it but I haven't had time to go back and experiment with that since I
 tried the first way.

 Great, I always wondered why the test client behaved that way and
 suspected threading/process problems.

 > Second, having the fixture teardown code attempt to detect whether a
 commit had been performed by the test code (despite the test case being a
 type that supposedly didn't use transactions) and fallback to flush/reload
 didn't seem to be working too well.  I tried tracking down a few of the
 failures caused by these and eventually decided to try a different
 approach, which is: if it's a test case that says it doesn't need
 transactions to work, monkey patch the transaction commit/rollback and
 enter/leave transaction management routines so that even if they are
 called by the code being tested, they do nothing, for the duration of the
 test.
 >
 >
 > I don't know how the monkey patch idea will be received, but this
 approach seems to work better.  Doing it this way, none of the existing
 Django tescases need to use the old flush/reload approach.  That is, the
 tests that do actually call commit or rollback (like admin_views, which
 call admin views that are wrapped in commit_on_success) don't actually
 need those calls to do anything in order for the test to properly test
 what it is trying to test.  Things work fine when those routines don't do
 anything, and the test fixture teardown is able to reliably un-do what the
 test has done, leaving things clean for the next test.

 What about adding signals to transaction processing? It could simplify the
 code here and might be useful at other places. Whenever a transaction is
 commited, a signal post_commit is emitted. This signal is catched by the
 test case and if it is a case that shouldn't need transactions, it simply
 throws an TransactionNotAllowedHere exception "That's evil! Please use the
 TestCase that can handle transactions.". That way no monkeypatching is
 necessary and it tells the developer what she/he is doing wrong.

 Instead of trying to guess if a transaction happened (was a bad idea) or
 deactivating transactions transparently (if a test relies on the commit,
 the developer will have some nice head scratching), it simply enforces the
 developer to use the right TestCase. What do you think?

 By the way, during the holidays (when that damned website is online) I can
 start contributing to that patch again, if my help is wanted.

-- 
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] #9857: URLfield with verify_exists hangs if given an unresponsive URL

[Django]

#9857: URLfield with verify_exists hangs if given an unresponsive URL
-+--
  Reporter:  aptiko  | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by aptiko):

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

Comment:

 The patch that I submitted (works against both 1.0 and svn) adds a
 hardwired 10-second timeout. If there is no response after the timeout,
 the URL is considered broken. Although this is not ideal (it's
 indeterminable rather than broken), a loud failure is much better than a
 hang, and the user will understand immediately why Django thinks that the
 URL is broken because they'll test it in their web browser and see that it
 is unresponsive. This is much better than a hang or an Internal Server
 Error.

-- 
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] #9857: URLfield with verify_exists hangs if given an unresponsive URL

[Django]

#9857: URLfield with verify_exists hangs if given an unresponsive URL
+---
 Reporter:  aptiko  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Forms   | Version:  1.0   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 Steps to reproduce:
   1. Create a model that contains a URLfield with verify_exists=True (the
 default), and make it adminable.
   2. In the Admin, create a new object and specify a URL whose server does
 not respond (it should leave your web browser in the "Connecting to
 [server name] ..." state).

 Result: Django hangs. In my development environment, the Django
 development server hangs. In my production environment, I get a 500
 Internal Server Error, apparently after SCGI times out while waiting for a
 response from Django.

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