Re: [Django] #11890: Defer/only + annotate is broken

[Django]

#11890: Defer/only + annotate is broken
-+-
   Reporter: |  Owner:  ruosteinen
  jaklaassen@…   | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by ramiro):

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


Comment:

 I think we can safely close this as fixed in [16522]. Thanks ruosteinen
 and mrmachine.

-- 
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] #11890: Defer/only + annotate is broken

[Django]

#11890: Defer/only + annotate is broken
-+-
   Reporter: |  Owner:  ruosteinen
  jaklaassen@…   | Status:  assigned
   Type:  Bug|  Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by mrmachine):

 I've tried, but can't reproduce a problem with the select/extra tests in
 r16510. Reading the test case, I'm not sure it was valid in the first
 place. It creates 10 `Candy` objects with `qty` of 42, then tests that the
 Sum is 378 - that never would have been correct.

 The issues in the original report have been fixed in [16522]. Although the
 symptoms changed (raising an IndexError instead of returning an empty
 queryset), the fix was the same. I believe the symptoms probably changed
 due to underlying changes in Django since this ticket was reported.

-- 
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] #16003: Admin incompatible with USE_ETAGS = True

[Django]

#16003: Admin incompatible with USE_ETAGS = True
+-
   Reporter:  lamby |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  SVN   |   Severity:  Release blocker
 Resolution:|   Keywords:  regression
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by mrmachine):

 * cc: real.human@… (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.

[Changeset] r16522 - in django/trunk: django/db/models django/db/models/sql tests/regressiontests/defer_regress

[noreply]

Author: ramiro
Date: 2011-07-06 18:12:45 -0700 (Wed, 06 Jul 2011)
New Revision: 16522

Modified:
   django/trunk/django/db/models/query.py
   django/trunk/django/db/models/sql/compiler.py
   django/trunk/tests/regressiontests/defer_regress/tests.py
Log:
Fixed #16409 -- Fixed an error condition when using QuerySet only()/defer() on 
the result of an annotate() call. Thanks jaklaassen AT gmail DOT com and Tai 
Lee for the reports and Tai for the patch.

Modified: django/trunk/django/db/models/query.py
===
--- django/trunk/django/db/models/query.py  2011-07-06 23:44:54 UTC (rev 
16521)
+++ django/trunk/django/db/models/query.py  2011-07-07 01:12:45 UTC (rev 
16522)
@@ -231,9 +231,6 @@
 fields = self.model._meta.fields
 pk_idx = self.model._meta.pk_index()
 
-index_start = len(extra_select)
-aggregate_start = index_start + len(self.model._meta.fields)
-
 load_fields = []
 # If only/defer clauses have been specified,
 # build the list of fields that are to be loaded.
@@ -253,6 +250,9 @@
 # Therefore, we need to load all fields from this model
 load_fields.append(field.name)
 
+index_start = len(extra_select)
+aggregate_start = index_start + len(load_fields or 
self.model._meta.fields)
+
 skip = None
 if load_fields and not fill_cache:
 # Some fields have been deferred, so we have to initialise

Modified: django/trunk/django/db/models/sql/compiler.py
===
--- django/trunk/django/db/models/sql/compiler.py   2011-07-06 23:44:54 UTC 
(rev 16521)
+++ django/trunk/django/db/models/sql/compiler.py   2011-07-07 01:12:45 UTC 
(rev 16522)
@@ -169,7 +169,7 @@
 if isinstance(col, (list, tuple)):
 alias, column = col
 table = self.query.alias_map[alias][TABLE_NAME]
-if table in only_load and col not in only_load[table]:
+if table in only_load and column not in only_load[table]:
 continue
 r = '%s.%s' % (qn(alias), qn(column))
 if with_aliases:

Modified: django/trunk/tests/regressiontests/defer_regress/tests.py
===
--- django/trunk/tests/regressiontests/defer_regress/tests.py   2011-07-06 
23:44:54 UTC (rev 16521)
+++ django/trunk/tests/regressiontests/defer_regress/tests.py   2011-07-07 
01:12:45 UTC (rev 16522)
@@ -4,6 +4,7 @@
 from django.contrib.contenttypes.models import ContentType
 from django.contrib.sessions.backends.db import SessionStore
 from django.db import connection
+from django.db.models import Count
 from django.db.models.loading import cache
 from django.test import TestCase
 
@@ -148,6 +149,10 @@
 ]
 )
 
+# Regression for #16409 - make sure defer() and only() work with 
annotate()
+
self.assertIsInstance(list(Item.objects.annotate(Count('relateditem')).defer('name')),
 list)
+
self.assertIsInstance(list(Item.objects.annotate(Count('relateditem')).only('name')),
 list)
+
 def test_only_and_defer_usage_on_proxy_models(self):
 # Regression for #15790 - only() broken for proxy models
 proxy = Proxy.objects.create(name="proxy", value=42)

-- 
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] #16409: `defer()` and `only()` don't play nice with `annotate()`

[Django]

#16409: `defer()` and `only()` don't play nice with `annotate()`
-+-
   Reporter:  mrmachine  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone:  1.4|  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage: |   Keywords:  annotate defer only
  Unreviewed |  count
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by ramiro):

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


Comment:

 In [16522]:
 {{{
 #!CommitTicketReference repository="" revision="16522"
 Fixed #16409 -- Fixed an error condition when using QuerySet
 only()/defer() on the result of an annotate() call. Thanks jaklaassen AT
 gmail DOT com and Tai Lee for the reports and Tai for 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] #14094: Cannot define CharField with unlimited length

[Django]

#14094: Cannot define CharField with unlimited length
---+--
   Reporter:  millerdev|  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Core (Other)
Version:  1.2  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--
Changes (by joe@…):

 * status:  closed => reopened
 * severity:   => Normal
 * cc: joe@… (added)
 * resolution:  invalid =>
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => New feature


Comment:

 PostgreSQL allows char fields (which are distinct from Text fields) which
 are "character varying" with no preset length.

 It only makes sense that these should map to a Django CharField, with
 max_length=None, rather than be forced to use a Django TextField, only
 because of this limitation of Django.

 In common PostgreSQL usage, these are small text fields of 20 or 50
 characters or less, NOT large text fields.

 Fixing this issue would also make the introspection of existing postgres
 databases *much* smoother.

-- 
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] r16521 - in django/trunk/docs: ref/models topics

[noreply]

Author: lukeplant
Date: 2011-07-06 16:44:54 -0700 (Wed, 06 Jul 2011)
New Revision: 16521

Modified:
   django/trunk/docs/ref/models/fields.txt
   django/trunk/docs/topics/security.txt
Log:
Improved warning about file uploads in docs, and added link from security 
overview page

Modified: django/trunk/docs/ref/models/fields.txt
===
--- django/trunk/docs/ref/models/fields.txt 2011-07-06 23:25:30 UTC (rev 
16520)
+++ django/trunk/docs/ref/models/fields.txt 2011-07-06 23:44:54 UTC (rev 
16521)
@@ -577,6 +577,8 @@
 this calls the :meth:`~django.core.files.storage.Storage.url` method of the
 underlying :class:`~django.core.files.storage.Storage` class.
 
+.. _file-upload-security:
+
 Note that whenever you deal with uploaded files, you should pay close attention
 to where you're uploading them and what type of files they are, to avoid
 security holes. *Validate all uploaded files* so that you're sure the files are
@@ -585,6 +587,10 @@
 root, then somebody could upload a CGI or PHP script and execute that script by
 visiting its URL on your site. Don't allow that.
 
+Also note that even an uploaded HTML file, since it can be executed by the
+browser (though not by the server), can pose security threats that are
+equivalent to XSS or CSRF attacks.
+
 By default, :class:`FileField` instances are
 created as ``varchar(100)`` columns in your database. As with other fields, you
 can change the maximum length using the :attr:`~CharField.max_length` argument.

Modified: django/trunk/docs/topics/security.txt
===
--- django/trunk/docs/topics/security.txt   2011-07-06 23:25:30 UTC (rev 
16520)
+++ django/trunk/docs/topics/security.txt   2011-07-06 23:44:54 UTC (rev 
16521)
@@ -152,7 +152,9 @@
 security protection of the web server, operating system and other components.
 
 * Make sure that your Python code is outside of the web server's root. This
-  will ensure that your Python code is not accidentally served as plain text.
+  will ensure that your Python code is not accidentally served as plain text
+  (or accidentally executed).
+* Take care with any :ref:`user uploaded files `.
 * Django does not throttle requests to authenticate users. To protect against
   brute-force attacks against the authentication system, you may consider
   deploying a Django plugin or web server module to throttle these requests.

-- 
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] #11890: Defer/only + annotate is broken

[Django]

#11890: Defer/only + annotate is broken
-+-
   Reporter: |  Owner:  ruosteinen
  jaklaassen@…   | Status:  assigned
   Type:  Bug|  Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by ramiro):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 See also #16409.

-- 
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] r16520 - in django/trunk/django/db/backends: . oracle postgresql_psycopg2 sqlite3

[noreply]

Author: ramiro
Date: 2011-07-06 16:25:30 -0700 (Wed, 06 Jul 2011)
New Revision: 16520

Modified:
   django/trunk/django/db/backends/creation.py
   django/trunk/django/db/backends/oracle/creation.py
   django/trunk/django/db/backends/postgresql_psycopg2/creation.py
   django/trunk/django/db/backends/sqlite3/creation.py
Log:
Fixed #16250 -- Made test database creation support code in the PostgreSQL DB 
backend compatible with psycopg2 2.4.2.

Implemented this by adding an internal hook for work that should be performed
before that point.

Also, regarding the `DatabaseCreation.set_autocommit()` method:
 * Stop using it for such tasks
 * Stop providing an implementation that tries to cover all the possible
   idioms a third party database backend DB-API 2 driver could need to activate
   autocommit. It is now left for third party backends to implement.

This can be backwards incompatible in the case of user applications that:
 * Had started using this method
 * Use a third a party database backend

Modified: django/trunk/django/db/backends/creation.py
===
--- django/trunk/django/db/backends/creation.py 2011-07-06 10:28:18 UTC (rev 
16519)
+++ django/trunk/django/db/backends/creation.py 2011-07-06 23:25:30 UTC (rev 
16520)
@@ -247,7 +247,7 @@
 verbosity=max(verbosity - 1, 0),
 interactive=False,
 database=self.connection.alias)
-
+
 # One effect of calling syncdb followed by flush is that the id of the
 # default site may or may not be 1, depending on how the sequence was
 # reset.  If the sites app is loaded, then we coerce it.
@@ -294,7 +294,7 @@
 # if the database supports it because PostgreSQL doesn't allow
 # CREATE/DROP DATABASE statements within transactions.
 cursor = self.connection.cursor()
-self.set_autocommit()
+self._prepare_for_test_db_ddl()
 try:
 cursor.execute("CREATE DATABASE %s %s" % (qn(test_database_name), 
suffix))
 except Exception, e:
@@ -339,21 +339,28 @@
 # to do so, because it's not allowed to delete a database while being
 # connected to it.
 cursor = self.connection.cursor()
-self.set_autocommit()
+self._prepare_for_test_db_ddl()
 time.sleep(1) # To avoid "database is being accessed by other users" 
errors.
 cursor.execute("DROP DATABASE %s" % 
self.connection.ops.quote_name(test_database_name))
 self.connection.close()
 
 def set_autocommit(self):
-"Make sure a connection is in autocommit mode."
-if hasattr(self.connection.connection, "autocommit"):
-if callable(self.connection.connection.autocommit):
-self.connection.connection.autocommit(True)
-else:
-self.connection.connection.autocommit = True
-elif hasattr(self.connection.connection, "set_isolation_level"):
-self.connection.connection.set_isolation_level(0)
+"""
+Make sure a connection is in autocommit mode. - Deprecated, not used
+anymore by Django code. Kept for compatibility with user code that
+might use it.
+"""
+pass
 
+def _prepare_for_test_db_ddl(self):
+"""
+Internal implementation - Hook for tasks that should be performed 
before
+the ``CREATE DATABASE``/``DROP DATABASE`` clauses used by testing code
+to create/ destroy test databases. Needed e.g. in PostgreSQL to 
rollback
+and close any active transaction.
+"""
+pass
+
 def sql_table_creation_suffix(self):
 "SQL to append to the end of the test table creation statements"
 return ''

Modified: django/trunk/django/db/backends/oracle/creation.py
===
--- django/trunk/django/db/backends/oracle/creation.py  2011-07-06 10:28:18 UTC 
(rev 16519)
+++ django/trunk/django/db/backends/oracle/creation.py  2011-07-06 23:25:30 UTC 
(rev 16520)
@@ -270,3 +270,6 @@
 settings_dict['NAME'],
 self._test_database_user(),
 )
+
+def set_autocommit(self):
+self.connection.connection.autocommit = True

Modified: django/trunk/django/db/backends/postgresql_psycopg2/creation.py
===
--- django/trunk/django/db/backends/postgresql_psycopg2/creation.py 
2011-07-06 10:28:18 UTC (rev 16519)
+++ django/trunk/django/db/backends/postgresql_psycopg2/creation.py 
2011-07-06 23:25:30 UTC (rev 16520)
@@ -76,3 +76,11 @@
 else:
 output = []
 return output
+
+def set_autocommit(self):
+self._prepare_for_test_db_ddl()
+
+def _prepare_for_test_db_ddl(self):
+"""Rollback and close the active transaction."""
+self.connection.connection.rollback()
+

Re: [Django] #16250: Error with new pyscopg2 2.4.2 release and tests

[Django]

#16250: Error with new pyscopg2 2.4.2 release and tests
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Testing framework
Version:  1.3|   Severity:  Release blocker
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by ramiro):

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


Comment:

 In [16520]:
 {{{
 #!CommitTicketReference repository="" revision="16520"
 Fixed #16250 -- Made test database creation support code in the PostgreSQL
 DB backend compatible with psycopg2 2.4.2.

 Implemented this by adding an internal hook for work that should be
 performed
 before that point.

 Also, regarding the `DatabaseCreation.set_autocommit()` method:
  * Stop using it for such tasks
  * Stop providing an implementation that tries to cover all the possible
idioms a third party database backend DB-API 2 driver could need to
 activate
autocommit. It is now left for third party backends to implement.

 This can be backwards incompatible in the case of user applications that:
  * Had started using this method
  * Use a third a party database backend
 }}}

-- 
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] #16427: truncate table method in ORM

[Django]

#16427: truncate table method in ORM
-+-
   Reporter: |  Owner:  nobody
  adamnelson | Status:  closed
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by lukeplant):

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


Comment:

 wontfixing, for the reasons aaugustin gave. If delete() is too slow use
 manual SQL truncate. https://docs.djangoproject.com/en/dev/topics/db/sql
 /#executing-custom-sql-directly . For specialised needs, this is good
 enough, and it's not hard to get the db table name for a model.

-- 
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] #8892: ForeignKey relation not saved as expected

[Django]

#8892: ForeignKey relation not saved as expected
-+-
   Reporter:  julien |  Owner:  blacklwhite
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.0|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by blacklwhite):

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


-- 
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] #8892: ForeignKey relation not saved as expected

[Django]

#8892: ForeignKey relation not saved as expected
-+-
   Reporter:  julien |  Owner:  blacklwhite
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.0|  (models, ORM)
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by blacklwhite):

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


-- 
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] #8892: ForeignKey relation not saved as expected

[Django]

#8892: ForeignKey relation not saved as expected
-+-
   Reporter:  julien |  Owner:  blacklwhite
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.0|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by blacklwhite):

 * has_patch:  0 => 1
 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Accepted => Ready for checkin


Comment:

 I fixed the bug as follows. If you save a model with a foreign key to a
 model which is not saved until this point, django will show an error:

 {{{
 >>> a = ModelA(name="a")
 >>> b = ModelB(name="b")
 >>> a.b = b
 >>> a.save()
 Traceback (most recent call last):
   File "", line 1, in 
   File "django\db\models\base.py", line 492, in save
 self.save_base(using=using, force_insert=force_insert,
 force_update=force_update)
   File "django\db\models\base.py", line 521, in save_base
 self.refresh_foreign_keys()
   File "django\db\models\base.py", line 475, in refresh_foreign_keys
 ". Have you already saved the " + str(fk_ref) + " object?")
 ValueError: Cannot find a primary key for b as a foreign key in an
 instance
  of ModelA. Have you already saved the b object?
 }}}

 If you save a related model '''after''' setting the related one to the
 first object, it works as expected.

 {{{
 >>> a = ModelA(name="a")
 >>> b = ModelB(name="b")
 >>> a.b = b
 >>> b.save()
 >>> a.save()
 }}}

 

 Problems I've considered (sometimes I use id as synonym for the foreign
 key of an object):
 * Compatible to users accessing to the foreign key field as follows:
 {{{
 >>> a = ModelA(name="a")
 >>> b = ModelB(name="b")
 >>> b.save()
 >>> a.b = b
 >>> a.b_id
 }}}
 So it is neccessary to set the id to a_id during the __set__ method of a.b
 = b. However the assertion that the id of b is the same as a.b_id must be
 before writing a to the database.

 * Not loading the related object from the database.
 {{{
 >>> a = ModelA.objects.get(name="a")
 >>> a.name = "b"
 >>> a.save()
 }}}
 The instance of Object b will not be loaded from the database to reduce
 db-queries.

 * This patch does only try to set the primary key of the related object,
 if no primary key is set and a related object exists. In this way it will
 never do an additional database query. Of course it produces an overhead
 for every call of the save() method, but by comparison to the following
 database-query it is negligible.

-- 
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] #16427: truncate table method in ORM

[Django]

#16427: truncate table method in ORM
-+-
   Reporter: |  Owner:  nobody
  adamnelson | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by adamnelson):

 The solution to the sqlite issue is simply to do "DELETE table_name" for
 that backend when calling the truncate() method.

 
[http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0500.htm
 Sybase] claims that TRUNCATE is SQL-92 compliant as part of the Transact-
 SQL extension.

 The problem with the delete() method is that it's exceedingly slow.  On
 tables with more than 1M records, DELETE can take up to 10 minutes to run
 compared to seconds to truncate - with the same outcome.

-- 
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] #16427: truncate table method in ORM

[Django]

#16427: truncate table method in ORM
-+-
   Reporter: |  Owner:  nobody
  adamnelson | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 As far as I can tell, `TRUNCATE` is not part of SQL-92, and it isn't
 implemented by sqlite, so it isn't a good candidate for ORM support.

 What's wrong with `MyModel.objects.delete()`? At least sqlite will
 optimize this by performing a truncate. I don't know very well the
 internal of other database engines, but they may optimize it too.

 Finally, you can use raw SQL.

 I'm leaning towards "wontfix", but let's wait for a core developer's
 opinion,

-- 
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] #16426: sqlite: Cannot delete more than 999 things if there is a relation pointing to them

[Django]

#16426: sqlite: Cannot delete more than 999 things if there is a relation 
pointing
to them
-+-
   Reporter:  kmtracey   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16427: truncate table method in ORM

[Django]

#16427: truncate table method in ORM
-+--
 Reporter:  adamnelson   |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Database layer (models, ORM)
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+--
 In the interest of having a more complete ORM, there should be a truncate
 table command available.  This could be used in specialized cases where
 the user needs to delete very large tables (i.e. migrations on volatile
 tables, tables with data that gets purged regularly, etc...)

-- 
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] #16426: sqlite: Cannot delete more than 999 things if there is a relation pointing to them

[Django]

#16426: sqlite: Cannot delete more than 999 things if there is a relation 
pointing
to them
-+-
 Reporter:  kmtracey |Owner:  nobody
 Type:  Bug  |   Status:  new
Milestone:   |Component:  Database
  Version:  1.3  |  layer (models, ORM)
 Keywords:   | Severity:  Normal
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
 Given these models:

 {{{
 #!python
 class Thing(models.Model):
 name = models.CharField(max_length=32)

 def __unicode__(self):
 return self.name


 class RelatedThing(models.Model):
 thing = models.ForeignKey(Thing)

 def __unicode__(self):
 return u'object related to %s.' % self.thing
 }}}

 using sqlite as the DB, attempting to delete more than 999 Things in one
 go fails:

 {{{
 --> python manage.py shell
 /home/kmtracey/django/hg-django/django/conf/__init__.py:75:
 DeprecationWarning: The ADMIN_MEDIA_PREFIX setting has been removed; use
 STATIC_URL instead.
   "use STATIC_URL instead.", DeprecationWarning)
 Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
 [GCC 4.4.3] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> from ttt.models import Thing
 >>> Thing.objects.count()
 0
 >>> for i in range(1000):
 ... Thing.objects.create(name='Thing %d' % i)
 ...
 
 
 
 [...output snipped...]
 
 
 
 
 >>> Thing.objects.all().delete()
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/kmtracey/django/hg-django/django/db/models/query.py", line
 444, in delete
 collector.collect(del_query)
   File "/home/kmtracey/django/hg-django/django/db/models/deletion.py",
 line 167, in collect
 if not sub_objs:
   File "/home/kmtracey/django/hg-django/django/db/models/query.py", line
 113, in __nonzero__
 iter(self).next()
   File "/home/kmtracey/django/hg-django/django/db/models/query.py", line
 107, in _result_iter
 self._fill_cache()
   File "/home/kmtracey/django/hg-django/django/db/models/query.py", line
 784, in _fill_cache
 self._result_cache.append(self._iter.next())
   File "/home/kmtracey/django/hg-django/django/db/models/query.py", line
 273, in iterator
 for row in compiler.results_iter():
   File "/home/kmtracey/django/hg-django/django/db/models/sql/compiler.py",
 line 699, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/home/kmtracey/django/hg-django/django/db/models/sql/compiler.py",
 line 754, in execute_sql
 cursor.execute(sql, params)
   File "/home/kmtracey/django/hg-django/django/db/backends/util.py", line
 34, in execute
 return self.cursor.execute(sql, params)
   File "/home/kmtracey/django/hg-
 django/django/db/backends/sqlite3/base.py", line 226, in execute
 return Database.Cursor.execute(self, query, params)
 DatabaseError: too many SQL variables
 >>> Thing.objects.count()
 1000
 >>> Thing.objects.filter(pk__gte=1000).delete()
 >>> Thing.objects.count()
 999
 >>> Thing.objects.all().delete()
 >>> Thing.objects.count()
 0
 }}}

 The problem is occurring when trying to collect the !RelatedThings that
 might need to be deleted along with the Things being deleted. The SQL it
 is trying to execute is of the form:

 {{{
 #!sql
 SELECT [list_of_columns] FROM [related_table] WHERE
 [related_table]."thing_id" IN ([list of 1000 pks of Things being deleted])
 }}}

 I'm guessing this is due to item #9 in http://www.sqlite.org/limits.html

 I tried the same thing on 1.2.X branch level and did not see the failure,
 it is new with 1.3 (I did also try 1.3 from around 1.3 beta in addition to
 the above which is with current trunk...it failed with the pre-release 1.3
 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] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
+---
   Reporter:  minarets  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  1.2   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by CollinAnderson):

 * cc: cmawebsite@… (added)
 * status:  closed => reopened
 * ui_ux:   => 0
 * resolution:  worksforme =>


Comment:

 I'm having this problem when saving an object that has the
 filter_horizontal widget in Safari/533.21.1 and Chrome 11.0.696.68.

 User permissions are a good example. Go to the change page of a user that
 has permissions selected. Don't modify anything, press save, then press
 back. The permissions will be set to the first n permissions in the list,
 where n is the number of permissions that they originally had.

-- 
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] #16395: urlize works with malformed URLs

[Django]

#16395: urlize works with malformed URLs
-+-
   Reporter: |  Owner:  nobody
  BernhardEssl   | Status:  new
   Type: |  Component:  Template system
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by BernhardEssl):

 Thanks aaugustin for the input. I updated the patch. hihi @trac

-- 
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] #16396: Validation Problem Reading Files When Using Custom Storage Module

[Django]

#16396: Validation Problem Reading Files When Using Custom Storage Module
-+-
   Reporter: |  Owner:  nobody
  dadealeus@…| Status:  closed
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  validation storage
 Resolution:  invalid|  custom
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Given the following sentence, I'd say the bug is in your custom storage
 module:
 > Using the native django storage, the exact same code functions without
 any issues.

 

 It's up to the storage model to reset the file, not the form. For
 instance, `django.core.files.base.File` does it in `open` and `__iter__`
 (via `chunks`).

 The docs say it's possible to override any of the storage methods
 explained in File storage API, but don't say how. They assume you will
 read the source  and understand the requirements. If you don't use the
 `File` class or a subclass, you should make sure that your code has a
 similar behavior.

 Given that we hardly have the most basic documentation here, I don't think
 it makes sense to describe this specific pitfall.

-- 
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] #16425: mailing using ssmtplib

[Django]

#16425: mailing using ssmtplib
-+
   Reporter:  charantej.s@…  |  Owner:  nobody
   Type:  New feature| Status:  closed
  Milestone:  1.4|  Component:  Core (Mail)
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:  Mailer feature
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
Changes (by aaugustin):

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


Comment:

 This isn't a bug in Django. Please ask usage questions on django-users or
 #django channel.

-- 
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] #16425: mailing using ssmtplib

[Django]

#16425: mailing using ssmtplib
+-
 Reporter:  charantej.s@…   |  Owner:  nobody
 Type:  New feature | Status:  new
Milestone:  1.4 |  Component:  Core (Mail)
  Version:  1.3 |   Severity:  Normal
 Keywords:  Mailer feature  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+-
 I need to send mail using ssmtplib. I mean secure mailing, Here we dont
 use smtp servers ,Even in production we are planning to use ssmtblib, So
 can anyone suggest how we can customise django to do that.

-- 
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] r16519 - in django/trunk: django/contrib/staticfiles/management/commands tests/regressiontests/staticfiles_tests tests/regressiontests/staticfiles_tests/project tests/regressiontests/stat

[noreply]

Author: jezdez
Date: 2011-07-06 03:28:18 -0700 (Wed, 06 Jul 2011)
New Revision: 16519

Added:
   django/trunk/tests/regressiontests/staticfiles_tests/project/prefixed/
   
django/trunk/tests/regressiontests/staticfiles_tests/project/prefixed/test.txt
Modified:
   django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
Log:
Fixed #16424 -- Fixed regression in collect static management command 
introduced in r16509 that prevented prefixed collection.

Modified: 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
===
--- 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2011-07-06 00:21:32 UTC (rev 16518)
+++ 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2011-07-06 10:28:18 UTC (rev 16519)
@@ -107,8 +107,10 @@
 for path, storage in finder.list(self.ignore_patterns):
 # Prefix the relative path if the source storage contains it
 if getattr(storage, 'prefix', None):
-path = os.path.join(storage.prefix, path)
-handler(path, path, storage)
+prefixed_path = os.path.join(storage.prefix, path)
+else:
+prefixed_path = path
+handler(path, prefixed_path, storage)
 
 actual_count = len(self.copied_files) + len(self.symlinked_files)
 unmodified_count = len(self.unmodified_files)

Added: 
django/trunk/tests/regressiontests/staticfiles_tests/project/prefixed/test.txt
===
--- 
django/trunk/tests/regressiontests/staticfiles_tests/project/prefixed/test.txt  
(rev 0)
+++ 
django/trunk/tests/regressiontests/staticfiles_tests/project/prefixed/test.txt  
2011-07-06 10:28:18 UTC (rev 16519)
@@ -0,0 +1 @@
+Prefix!
\ No newline at end of file

Modified: django/trunk/tests/regressiontests/staticfiles_tests/tests.py
===
--- django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2011-07-06 00:21:32 UTC (rev 16518)
+++ django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2011-07-06 10:28:18 UTC (rev 16519)
@@ -54,7 +54,10 @@
 STATIC_URL = '/static/',
 MEDIA_ROOT =  os.path.join(TEST_ROOT, 'project', 'site_media', 'media'),
 STATIC_ROOT = os.path.join(TEST_ROOT, 'project', 'site_media', 'static'),
-STATICFILES_DIRS = (os.path.join(TEST_ROOT, 'project', 'documents'),),
+STATICFILES_DIRS = (
+os.path.join(TEST_ROOT, 'project', 'documents'),
+('prefix', os.path.join(TEST_ROOT, 'project', 'prefixed')),
+),
 STATICFILES_FINDERS = (
 'django.contrib.staticfiles.finders.FileSystemFinder',
 'django.contrib.staticfiles.finders.AppDirectoriesFinder',
@@ -105,6 +108,7 @@
 Can find a file in a STATICFILES_DIRS directory.
 """
 self.assertFileContains('test.txt', 'Can we find')
+self.assertFileContains(os.path.join('prefix', 'test.txt'), 'Prefix')
 
 def test_staticfiles_dirs_subdir(self):
 """

-- 
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] #16424: collectstatic command not work

[Django]

#16424: collectstatic command not work
+-
   Reporter:  Kidwind   |  Owner:  jezdez
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  contrib.staticfiles
Version:  SVN   |   Severity:  Normal
 Resolution:  fixed |   Keywords:  collectstatic
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by jezdez):

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


Comment:

 In [16519]:
 {{{
 #!CommitTicketReference repository="" revision="16519"
 Fixed #16424 -- Fixed regression in collect static management command
 introduced in r16509 that prevented prefixed collection.
 }}}

-- 
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] #16424: collectstatic command not work

[Django]

#16424: collectstatic command not work
+-
   Reporter:  Kidwind   |  Owner:  jezdez
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.staticfiles
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  collectstatic
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by jezdez):

 * owner:  nobody => jezdez
 * 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.

Re: [Django] #16424: collectstatic command not work

[Django]

#16424: collectstatic command not work
+-
   Reporter:  Kidwind   |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.staticfiles
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  collectstatic
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by jezdez):

 * status:  closed => reopened
 * resolution:  needsinfo =>
 * stage:  Unreviewed => Accepted


Comment:

 Dang, yeah, that's a bug that breaks prefixed static files.

-- 
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] #15316: Filter with isnull=False failing when isnull checked on subclass of FK model

[Django]

#15316: Filter with isnull=False failing when isnull checked on subclass of FK
model
-+-
   Reporter:  zimnyx |  Owner:  ethlinn
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by ethlinn):

 * owner:  nobody => ethlinn


Comment:

 I added the patch with tests for four cases mentioned above. I also
 changed models for the tests. Validation, apart from checking the count,
 is now done with asserting if a tested QuerySet is the same as a QuerySet
 that is filtered with pks of correct objects.

 I hope, it is exactly what I was expected to do. I also added myself to
 AUTHORS (Yay!) as russellm suggested :).

-- 
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] #16424: collectstatic command not work

[Django]

#16424: collectstatic command not work
-+-
   Reporter:  Kidwind|  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.staticfiles
Version:  SVN|   Severity:  Normal
 Resolution:  needsinfo  |   Keywords:  collectstatic
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 I'm attaching the diff between the current version of collectstatic and
 the version you sent.

 Since you didn't say what problem you're trying to fix, I can't do
 anything with your report.

-- 
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] #16424: collectstatic command not work

[Django]

#16424: collectstatic command not work
---+-
 Reporter:  Kidwind|  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  contrib.staticfiles
  Version:  SVN|   Severity:  Normal
 Keywords:  collectstatic  |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  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] #897: Bi-Directional ManyToMany in Admin

[Django]

#897: Bi-Directional ManyToMany in Admin
---+---
   Reporter:  anonymous|  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:   |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by anonymous):

 Check this out

 {{{
 class Test1(models.Model):
 tests2 = models.ManyToManyField('Test2', blank=True)

 class Test2(models.Model):
 tests1 = models.ManyToManyField(Test1, through=Test1.tests2.through,
 blank=True)
 }}}

 I guess this is the most native way

-- 
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] #16400: runserver exits without any warnings

[Django]

#16400: runserver exits without any warnings
--+--
   Reporter:  gour|  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Core (Other)
Version:  1.3 |   Severity:  Normal
 Resolution:  invalid |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
Changes (by aaugustin):

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


Comment:

 Some code must have changed between Django 1.2 and 1.3 and it triggers the
 bug, that's all...

 Since it's a problem with the version of Python provided by FreeBSD, I'll
 close the ticket.

 Thanks for your efforts to diagnose this issue!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16422: Warnings when building the docs in epub format

[Django]

#16422: Warnings when building the docs in epub format
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 I couldn't find a way to remove these warnings.

 Also http://sphinx.readthedocs.org/en/latest/faq.html#epub-info says:
 >The epub builder is currently in an experimental stage. It has only been
 tested with the Sphinx documentation itself.

 Until it's really supported by Sphinx, 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.

Re: [Django] #16422: Warnings when building the docs in epub format

[Django]

#16422: Warnings when building the docs in epub format
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
-+-
   Reporter:  haras  |  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * has_patch:  0 => 1
 * type:  Bug => Cleanup/optimization
 * severity:  Release blocker => Normal
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 `django.contrib.auth` uses the `get_current_site` method of
 `django.contrib.sites`, which is safe to use, whether the sites framework
 is or isn't enabled.

 However, when the sites framework isn't enabled, this method must receive
 the `request` in argument. In `test_custom_email_subject`, there is no
 request available, and the test crashes. Attached patch fixes this (and
 avoids relying on the default name of the default site).

-- 
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] #16400: runserver exits without any warnings

[Django]

#16400: runserver exits without any warnings
--+--
   Reporter:  gour|  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  Core (Other)
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--

Comment (by gour):

 Replying to [comment:4 aaugustin]:
 > Since we have a segfault, either Django is doing bad things with
 `ctypes`, or it's a bug in Python.
 >
 > It might be http://bugs.python.org/issue9812 but I really don't have any
 proof of this.

 It seems it is problem with Python...iow, I've rebuilt Python with 'Use a
 larger thread stack' (HUGE_STACK_SIZE) which defines:

 {{{
 CFLAGS += -DTHREAD_STACK_SIZE=0x10
 }}}

 and now it works.

 I'll inform port maintainers, since the 'default' size of 0x2 seems to
 be quite small.

 Now I just wonder why it works with django-1.2.5?

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

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