[Django] #18083: Multi-table inheritance subclasses proxy deletion is broken

[Django]

#18083: Multi-table inheritance subclasses proxy deletion is broken
-+-
 Reporter:  charettes|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.4
  (models, ORM)  |   Keywords:  model proxy multi-table
 Severity:  Normal   |  inheritance
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Given the following models

 {{{#!python
 #test_app/models.py
 from django.db import models

 class A(models.Model):
 pass

 class B(A):
 pass

 class C(B):
 class Meta:
 proxy = True
 }}}

 Running the following tests fails

 {{{#!python
 #test_app/tests.py
 from django.test import TestCase

 from .models import *


 class SimpleTest(TestCase):

 def test_model_subclass_proxy_deletion(self):
 c = C.objects.create()
 self.assertEqual(1, C.objects.count())
 self.assertEqual(1, B.objects.count())
 self.assertEqual(1, A.objects.count())

 c.delete()
 self.assertEqual(0, C.objects.count())
 self.assertEqual(0, B.objects.count())
 self.assertEqual(0, A.objects.count())

 def test_model_subclass_deletion(self):
 b = B.objects.create()
 self.assertEqual(1, C.objects.count())
 self.assertEqual(1, B.objects.count())
 self.assertEqual(1, A.objects.count())

 b.delete()
 self.assertEqual(0, C.objects.count())
 self.assertEqual(0, B.objects.count())
 self.assertEqual(0, A.objects.count())
 }}}

 {{{
 simon@simon-laptop:~/Bureau/test_deletion$ ./manage.py test test_app
 Creating test database for alias 'default'...
 .F
 ==
 FAIL: test_model_subclass_proxy_deletion (test_app.tests.SimpleTest)
 --
 Traceback (most recent call last):
   File "/home/simon/Bureau/test_deletion/test_app/tests.py", line 27, in
 test_model_subclass_proxy_deletion
 self.assertEqual(0, A.objects.count())
 AssertionError: 0 != 1

 --
 Ran 2 tests in 0.014s

 FAILED (failures=1)
 Destroying test database for alias 'default'...
 }}}

 Deleting a multi-table inherited model proxy do not delete all related
 parent instances while doing it on the concrete model works perfectly.

-- 
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] #11079: Multi-table inheritance subclasses cannot be proxied

[Django]

#11079: Multi-table inheritance subclasses cannot be proxied
-+-
 Reporter:  gsong|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.0
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  model proxy multi-   |  Needs documentation:  0
  table inheritance  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by charettes):

 * version:  1.3 => 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] #11079: Multi-table inheritance subclasses cannot be proxied

[Django]

#11079: Multi-table inheritance subclasses cannot be proxied
-+-
 Reporter:  gsong|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  model proxy multi-   |  Needs documentation:  0
  table inheritance  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by charettes):

 * status:  new => closed
 * version:  SVN => 1.3
 * resolution:   => fixed


Comment:

 Cannot reproduce on django 1.4

 {{{
 >>> import django
 >>> django.VERSION
 (1, 4, 0, 'final', 0)
 >>> from ticket_11079.models import Restaurant, PizzaJoint
 >>> Restaurant.objects.create(name='Greasy Pizza', genre='pizza')
 
 >>> Restaurant.objects.all()
 []
 >>> PizzaJoint.objects.all()
 []
 }}}

 django 1.3.1
 {{{
 >>> import django
 >>> django.VERSION
 (1, 3, 1, 'final', 0)
 >>> from ticket_11079.models import Restaurant, PizzaJoint
 >>> Restaurant.objects.create(name='Greasy Pizza', genre='pizza')
 
 >>> Restaurant.objects.all()
 []
 >>> PizzaJoint.objects.all()
 []
 }}}

 And django 1.2.7
 {{{
 >>> import django
 >>> django.VERSION
 (1, 2, 7, 'final', 0)
 >>> from ticket_11079.models import Restaurant, PizzaJoint
 >>> Restaurant.objects.create(name='Greasy Pizza', genre='pizza')
 
 >>> Restaurant.objects.all()
 []
 >>> PizzaJoint.objects.all()
 []
 }}}

 At the time this ticket was created (05/12/09)
 [https://www.djangoproject.com/weblog/2009/may/ django 1.1 was about not
 event released]. I cannot find which commit fixed this issue but since it
 has been fixed in trunk for about 3 years I'm marking this ticket as
 ''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.

[Changeset] r17877 - django/trunk/docs

[noreply]

Author: claudep
Date: 2012-04-07 15:35:57 -0700 (Sat, 07 Apr 2012)
New Revision: 17877

Modified:
   django/trunk/docs/Makefile
   django/trunk/docs/make.bat
Log:
Added gettext target to sphinx makefiles.

This have been copied from sphinx-quickstart result in latest sphinx versions.


Modified: django/trunk/docs/Makefile
===
--- django/trunk/docs/Makefile  2012-04-07 15:16:11 UTC (rev 17876)
+++ django/trunk/docs/Makefile  2012-04-07 22:35:57 UTC (rev 17877)
@@ -11,8 +11,10 @@
 PAPEROPT_a4 = -D latex_paper_size=a4
 PAPEROPT_letter = -D latex_paper_size=letter
 ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
 
-.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp 
epub latex latexpdf text man changes linkcheck doctest
+.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp 
epub latex latexpdf text man changes linkcheck doctest gettext
 
 help:
@echo "Please use \`make ' where  is one of"
@@ -29,6 +31,7 @@
@echo "  latexpdf   to make LaTeX files and run them through pdflatex"
@echo "  text   to make text files"
@echo "  manto make manual pages"
+   @echo "  gettextto make PO message catalogs"
@echo "  changesto make an overview of all changed/added/deprecated 
items"
@echo "  linkcheck  to check all external links for integrity"
@echo "  doctestto run all doctests embedded in the documentation 
(if enabled)"
@@ -113,6 +116,11 @@
@echo
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
 
+gettext:
+   $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
+   @echo
+   @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+
 changes:
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@echo

Modified: django/trunk/docs/make.bat
===
--- django/trunk/docs/make.bat  2012-04-07 15:16:11 UTC (rev 17876)
+++ django/trunk/docs/make.bat  2012-04-07 22:35:57 UTC (rev 17877)
@@ -9,6 +9,7 @@
 set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% .
 if NOT "%PAPER%" == "" (
set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
+   set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS%
 )
 
 if "%1" == "" goto help
@@ -28,6 +29,7 @@
echo.  latex  to make LaTeX files, you can set PAPER=a4 or 
PAPER=letter
echo.  text   to make text files
echo.  manto make manual pages
+   echo.  gettextto make PO message catalogs
echo.  changesto make an overview over all changed/added/deprecated 
items
echo.  linkcheck  to check all external links for integrity
echo.  doctestto run all doctests embedded in the documentation if 
enabled
@@ -141,6 +143,14 @@
goto end
 )
 
+if "%%1" == "gettext" (
+   %SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale
+   if errorlevel 1 exit /b 1
+   echo.
+   echo.Build finished. The message catalogs are in %BUILDDIR%/locale.
+   goto end
+)
+
 if "%1" == "changes" (
%SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes
if errorlevel 1 exit /b 1

-- 
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] #18082: get_indexes produces wrong resuls under oracle

[Django]

#18082: get_indexes produces wrong resuls under oracle
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:  oracle
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Currently oracle/introspection.py get_indexes uses this SQL:
 {{{
 SELECT LOWER(all_tab_cols.column_name) AS column_name,
CASE user_constraints.constraint_type
WHEN 'P' THEN 1 ELSE 0
END AS is_primary_key,
CASE user_indexes.uniqueness
WHEN 'UNIQUE' THEN 1 ELSE 0
END AS is_unique
 FROM   all_tab_cols, user_cons_columns, user_constraints,
 user_ind_columns, user_indexes
 WHERE  all_tab_cols.column_name = user_cons_columns.column_name (+)
   AND  all_tab_cols.table_name = user_cons_columns.table_name (+)
   AND  user_cons_columns.constraint_name =
 user_constraints.constraint_name (+)
   AND  user_constraints.constraint_type (+) = 'P'
   AND  user_ind_columns.column_name (+) = all_tab_cols.column_name
   AND  user_ind_columns.table_name (+) = all_tab_cols.table_name
   AND  user_indexes.uniqueness (+) = 'UNIQUE'
   AND  user_indexes.index_name (+) = user_ind_columns.index_name
   AND  all_tab_cols.table_name = UPPER(%s)
 }}}

 This SQL has two failings: first, it LEFT JOINs instead of INNER JOINs the
 user_ind_columns, so every column will show as indexed. In addition the
 results are ordering dependant, for example if we check AUTH_USER by that
 SQL, the result is:
 {{{
 id  1   1
 id  0   1
 username0   1
 is_staff0   0
 is_staff0   0
 last_name   0   0
 is_superuser0   0
 is_superuser0   0
 last_login  0   0
 date_joined 0   0
 first_name  0   0
 email   0   0
 is_active   0   0
 is_active   0   0
 password0   0
 }}}
 So, if ID is a primary key is purely luck-based.

 In addition the SQL is really slow, it takes around 0.9 seconds for single
 table on my laptop. As the test suite has nearly 1000 tables, inspectdb
 tests will take half an hour just executing this SQL.

 I think one could get the same results by using the three following
 queries:
 {{{
 select * from user_ind_columns where table_name = 'AUTH_GROUP';
 select * from user_constraints where constraint_type = 'P' and table_name
 = 'AUTH_GROUP';
 select * from user_indexes where uniqueness = 'UNIQUE' and table_name =
 'AUTH_GROUP';
 }}}
 and then doing the joins in Python. It seems this approach would also be
 at least an order of magnitude faster.

-- 
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] #18081: Proxy model foreign keys not created properly by syncdb

[Django]

#18081: Proxy model foreign keys not created properly by syncdb
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Add this test to modeltests/proxy_models/tests.py:
 {{{
 class TransactionalProxyModelTests(TransactionTestCase):
 def test_proxy_fk(self):
 """
 Test that the DB contains proper foreign keys for proxy model
 references.
 """
 @transaction.commit_on_success
 def create_failing_pk():
 t = TrackerUser.objects.create(status='bar')
 Improvement.objects.create(summary='foof', version='foof',
reporter_id=1, associated_bug_id=1,
assignee=t)
 self.assertRaises(IntegrityError, create_failing_pk)

 }}}
 On MySQL this does not fail when using InnoDB. It should fail, as both
 reporter and associated bug with ID=1 are missing.

 The reason for this is that in django/db/backends/creation.py,
 sql_for_pending_references() is a check:
 {{{ if not model._meta.managed or model._meta.proxy: skip creation }}}
 Now, that is incorrect: the model in question is the model we are
 _referring_, not the model from where the PK is from. So, under MySQL
 foreign keys to proxy models do not get enforced in the DB.

 In addition the same bug is there for other databases, too. However, this
 one does not show under PostgreSQL as the foreign key is created inline.
 However, were the order of the models different in models.py also
 PostgreSQL would fail to create the foreign key.

 The fix is luckily very simple: just remove the "or proxy" part. The
 managed part is correct: the referenced model can be a view for example,
 in which case referencing it would be a failure.

-- 
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] #17851: Db Field instances cannot be compared to other objects

[Django]

#17851: Db Field instances cannot be compared to other objects
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  field compare|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 I'm no committer but I updated the match according to your note :)

-- 
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] #18079: Offline HTML docs report django 1.4 docs as 1.5

[Django]

#18079: Offline HTML docs report django 1.4 docs as 1.5
---+--
 Reporter:  gustavo@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  duplicate
 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 ramiro):

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


Comment:

 Duplicate of #18067.

-- 
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] #18080: @transaction.commit_manually plus context processors doesn't work well

[Django]

#18080: @transaction.commit_manually plus context processors doesn't work well
---+--
 Reporter:  jstpierre@…|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  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
---+--

Comment (by akaariai):

 My take is that the shown usage of commit_manually is a bug in the user
 code - it does not take into account that the render_to_response might do
 queries. The render_to_response is clearly part of the function, and thus
 the commit_manually applies to it, too.

 Disabling transactions as a side-effect of rendering under commit_manually
 decorator is a big no-no in my 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] #18035: Remove AdminMediaHandler

[Django]

#18035: Remove AdminMediaHandler
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  contrib.admin|   Resolution:
 Severity:  Release blocker  | 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 ramiro):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #18080: @transaction.commit_manually plus context processors doesn't work well

[Django]

#18080: @transaction.commit_manually plus context processors doesn't work well
---+--
 Reporter:  jstpierre@…|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  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
---+--

Comment (by Jasper St. Pierre ):

 It could be considered a documentation issue, but the problem is really
 apparent when mixing and matching external applications - one application
 that uses commit_manually may not use an internal function.

 A solution may be to "disable" transactions when in a call to render, and
 restore it after the call (instead of an is_automatic boolean, make it a
 stack, make transaction.commit_manually push onto the stack, push onto the
 stack while rendering templates and evaluating context processors).

-- 
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] #18080: @transaction.commit_manually plus context processors doesn't work well

[Django]

#18080: @transaction.commit_manually plus context processors doesn't work well
---+--
 Reporter:  jstpierre@…|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  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 akaariai):

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


Comment:

 To me it seems the commit_manually decorator works exactly as advertised.
 The solution is to maybe define another function to do the actual
 prosessing:
 {{{
 def create_new_foo(request):
 @transaction.commit_manually
 def inner():
 # do stuff
 inner()
 return render_to_response...
 }}}

 I am closing this as invalid. If you want to reopen this please provide
 more details of what should be fixed. Is documentation erroneous or
 lacking for example?

-- 
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] #18080: @transaction.commit_manually plus context processors doesn't work well

[Django]

#18080: @transaction.commit_manually plus context processors doesn't work well
---+
 Reporter:  jstpierre@…|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Imagine a view that looks like this:

 {{{
 @transaction.commit_manually
 def create_new_foo(request):
 name = request.GET['name']
 obj = MyFoo(name=name)
 # We need to add the object to a ManyToMany
 # so we need a PK.
 obj.save()
 add_to_many_to_many(obj)
 if obj.is_valid():
 valid = True
 transaction.commit()
 else:
 valid = False
 transaction.rollback()

 return render_to_response("objs/obj_created.html", {'valid':
 valid,
 'obj': obj})
 }}}

 Now imagine a context processor in another application entirely that looks
 like this:

 {{{
 def num_my_bars(request):
 return MyBar.objects.count()
 }}}

 Since num_my_bars hits the database during the render, the transaction
 will be dirtied and leaving the commit_manually view will fail. A dirty
 solution may be to do:

 {{{
 response = render_to_response(...)
 transaction.set_clean()
 return response
 }}}

 in the view, but this is dirty and awkward.

-- 
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] #18079: Offline HTML docs report django 1.4 docs as 1.5

[Django]

#18079: Offline HTML docs report django 1.4 docs as 1.5
---+
 Reporter:  gustavo@…  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Not really a big deal, but Django's 1.4 offline HTML docs report the docs
 as being for Django 1.4. This is a snippet from index.html:

 Django documentation  Django v1.5 documentation
 
 
 
   var DOCUMENTATION_OPTIONS = {
 URL_ROOT:'',
 VERSION: '1.5',
 COLLAPSE_INDEX: false,
 FILE_SUFFIX: '.html',
 HAS_SOURCE:  true
   };
 
 
 
 
 

 I have a script that turns your docs into Apple's docsets to use with Dash
 in osx and I get the version from the files and just noticed 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.

Re: [Django] #18067: Offline docs show up as 1.5

[Django]

#18067: Offline docs show up as 1.5
-+-
 Reporter:  support@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Djangoproject.com|  Version:  1.4
  Web site   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  offline docs |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by ramiro):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * component:  Documentation => Djangoproject.com Web site
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Locally built HTML versions of 1.4 final tag and 1.4.X branch both show
 correctly 1.4 and I can confirm the referenced offcial download .zip shows
 1.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.

Re: [Django] #13528: db_table truncation is applied based on the properties of the default database

[Django]

#13528: db_table truncation is applied based on the properties of the default
database
-+-
 Reporter:  russellm |Owner:
 Type:  Bug  |  andrewgodwin
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  1.2-beta
 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 akaariai):

 Ive been thinking that model._meta should contain backend specific
 sections. This should contain at least quoted db_table name and column
 names. In addition to solving this problem such an arrangement should
 speed up SQL generation. Quoting the table and column names can consume a
 significant amount of time.

 So, instead of doing model._meta.db_table you would do something like
 model._meta[conn].db_table. However, this requires somewhat extensive
 changes in the sql/query.py and sql/compiler.py, so I guess this has to
 wait...

-- 
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] #17957: If engine for default DB alias has interprets_empty_strings_as_nulls (i.e. Oracle) it affects DDL SQL for model fields null=False in other DBs

[Django]

#17957: If engine for default DB alias has interprets_empty_strings_as_nulls 
(i.e.
Oracle) it affects DDL SQL for model fields null=False in other DBs
-+-
 Reporter:  bhuztez  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (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|
-+-

Comment (by ramiro):

 See also #13528, #13711 that are about other parts of model
 characteristics that use data from the `'default'` DATABASES alias.

-- 
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] #17957: If engine for default DB alias has interprets_empty_strings_as_nulls (i.e. Oracle) it affects DDL SQL for model fields null=False in other DBs (was: ORM do not respect null=False

[Django]

#17957: If engine for default DB alias has interprets_empty_strings_as_nulls 
(i.e.
Oracle) it affects DDL SQL for model fields null=False in other DBs
-+-
 Reporter:  bhuztez  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (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 ramiro):

 * stage:  Unreviewed => Accepted


Comment:

 Ah I get it now. Thanks for the patience.

-- 
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] #16455: Postgis 2.0 Compatibility

[Django]

#16455: Postgis 2.0 Compatibility
-+
 Reporter:  ckarrie  |Owner:  jbronn
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  postgis 2.0  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)


Comment:

 I don't think it is fixed.

 As for tests I don't know if there is anything to test. Maybe one could
 test if the index creation does not contain the GEOM_OPS definition?
 Otherwise, the test is "does it run on 2.0".

 I will need to install PostGIS anyways for the db schema support feature,
 so I could take care of this. However, the fix will not go into 1.4.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13901: File.chunks fails to read the entire file for some file-like objects

[Django]

#13901: File.chunks fails to read the entire file for some file-like objects
--+
 Reporter:  ikelly|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  File uploads/storage  |  Version:  SVN
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

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


Comment:

 The implementation of the `chunks()` method has changed in r17871, to not
 depend on size anymore. Hence rendering this ticket obsolete.

-- 
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] #16455: Postgis 2.0 Compatibility

[Django]

#16455: Postgis 2.0 Compatibility
-+
 Reporter:  ckarrie  |Owner:  jbronn
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  postgis 2.0  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by anonymous):

 So is it fixed in 1.4? I still get this error with PostgreSQL 9.1 +
 PostGIS 2.0.0 + Django 1.4

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #9632: File.chunks contains potentially expensive size operation

[Django]

#9632: File.chunks contains potentially expensive size operation
-+-
 Reporter:  psagers  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.0
Component:  File |   Resolution:  duplicate
  uploads/storage| Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:  file |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

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


Comment:

 When fixing #15644, the chunks implementation has been changed to not
 depend on size any more (r17871). It remains to be seen if comment:5
 (over-read socket connection) might be true, triggering new bug reports.
 Real use-cases welcome...

-- 
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] r17876 - in django/trunk: django/template tests/regressiontests/defaultfilters

[noreply]

Author: claudep
Date: 2012-04-07 08:16:11 -0700 (Sat, 07 Apr 2012)
New Revision: 17876

Modified:
   django/trunk/django/template/defaultfilters.py
   django/trunk/tests/regressiontests/defaultfilters/tests.py
Log:
Fixed #15683 -- Prevented escaped string to be needlessly marked safe twice in 
force_escape filter. Thanks tyrion for the initial patch.


Modified: django/trunk/django/template/defaultfilters.py
===
--- django/trunk/django/template/defaultfilters.py  2012-04-06 21:24:33 UTC 
(rev 17875)
+++ django/trunk/django/template/defaultfilters.py  2012-04-07 15:16:11 UTC 
(rev 17876)
@@ -419,7 +419,7 @@
 characters (as opposed to "escape", which marks the content for later
 possible escaping).
 """
-return mark_safe(escape(value))
+return escape(value)
 
 @register.filter("linebreaks", is_safe=True, needs_autoescape=True)
 @stringfilter

Modified: django/trunk/tests/regressiontests/defaultfilters/tests.py
===
--- django/trunk/tests/regressiontests/defaultfilters/tests.py  2012-04-06 
21:24:33 UTC (rev 17875)
+++ django/trunk/tests/regressiontests/defaultfilters/tests.py  2012-04-07 
15:16:11 UTC (rev 17876)
@@ -6,6 +6,7 @@
 from django.template.defaultfilters import *
 from django.test import TestCase
 from django.utils import unittest, translation
+from django.utils.safestring import SafeData
 
 
 class DefaultFiltersTests(TestCase):
@@ -328,9 +329,10 @@
   u'a string to be mangled')
 
 def test_force_escape(self):
+escaped = force_escape(u' here')
 self.assertEqual(
-force_escape(u' here'),
-u'some html  special characters  here')
+escaped, u'some html  special characters  here')
+self.assertTrue(isinstance(escaped, SafeData))
 self.assertEqual(
 force_escape(u' here ĐÅ€£'),
 u'some html  special characters  here'\

-- 
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] #15683: the force_escpe filter should not call mark_safe

[Django]

#15683: the force_escpe filter should not call mark_safe
-+-
 Reporter:  tyrion   |Owner:
 Type:   |  marcosmoyano
  Cleanup/optimization   |   Status:  closed
Component:  Template system  |  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  force_escape | Triage Stage:  Accepted
  mark_safe  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

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


Comment:

 In [17876]:
 {{{
 #!CommitTicketReference repository="" revision="17876"
 Fixed #15683 -- Prevented escaped string to be needlessly marked safe
 twice in force_escape filter. Thanks tyrion for the initial 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] #6892: Warn about raw "%" in redirect_to strings.

[Django]

#6892: Warn about raw "%" in redirect_to strings.
--+
 Reporter:  daonb    |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Generic views |  Version:  SVN
 Severity:  Normal|   Resolution:  wontfix
 Keywords:  unicode, url  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

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


Comment:

 The documentation for the new class-based view !RedirectView is now
 clear:[[BR]]
 ''Because keyword interpolation is always done (even if no arguments are
 passed in), any "%" characters in the URL must be written as "%%" so that
 Python will convert them to a single percent sign on output.''[[BR]]
 https://docs.djangoproject.com/en/dev/ref/class-based-
 views/#django.views.generic.base.RedirectView

 As for the use-case of the OP, I think that a .replace('%', '%%') should
 be appended to the urlencode() call.

-- 
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] #2594: Template system should handle whitespace better

[Django]

#2594: Template system should handle whitespace better
-+-
 Reporter:  Gary Wilson  |Owner:  jshedd
  |   Status:  new
 Type:  Bug  |  Version:  SVN
Component:  Template system  |   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 Twidi):

 * cc: Twidi (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] #16744: Class based view should have the view object in the context

[Django]

#16744: Class based view should have the view object in the context
---+
 Reporter:  reinout|Owner:  tobias
 Type:  New feature|   Status:  assigned
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by reinout):

 Is "variable that points to the ``View`` instance" in the documentation
 clear enough? I understand what's happening, but I wonder if an "(the
 view's ``self``)" addition would make it clearer?

-- 
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] #16744: Class based view should have the view object in the context

[Django]

#16744: Class based view should have the view object in the context
---+
 Reporter:  reinout|Owner:  tobias
 Type:  New feature|   Status:  assigned
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 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 claudep):

 * 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] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
-+-
 Reporter:  ikelly   |Owner:  akaariai
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  oracle postgresql|  decision needed
  mysql schemas  |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Correct. The rule is: use Meta.db_schema or connection's
 `settings_dict['SCHEMA']` or settings.DEFAULT_SCHEMA.

-- 
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] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
-+-
 Reporter:  ikelly   |Owner:  akaariai
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  oracle postgresql|  decision needed
  mysql schemas  |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by mitar):

 Replying to [comment:109 akaariai]:
 > This can be settings.DEFAULT_SCHEMA or the search_path default schema.

 Just a quick comment. Shouldn't this be a setting inside the DATABASES
 setting for each entry?

-- 
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] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
-+-
 Reporter:  ikelly   |Owner:  akaariai
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  oracle postgresql|  decision needed
  mysql schemas  |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * stage:  Accepted => Design decision needed


Comment:

 I now have something that passes all the likely-to-break tests on all four
 core backends. Running the full test suite on all backends takes a lot of
 time, so I haven't done that. Code at github.

 The patch is rather large (+1559, -443 lines), and most of that is actual
 code changes. While lines of code isn't that important, this patch
 introduces a source of confusion into introspection. Previously, a Model
 could be identified uniquely by its table name. Unfortunately, there are
 multiple formats for qualified names:
   - (None, table) from models: This format says that the table should
 reside in database default schema. This can be settings.DEFAULT_SCHEMA or
 the search_path default schema. The problem is, on PostgreSQL we really do
 not know what that search path default schema is.
   - (someschema, table) from models
   - (someschame, table) from database

 When we have model with qualified name (foo, tbl) in SQLite it is turned
 into (None, foo_tbl) in the database (no real schema support on SQLite).
 On Oracle & MySQL in testing (foo, tbl) -> (default_foo, tbl) for alias
 default. This is because the production database's schemas and testing
 schemas live in the same namespace.

 The end result of this is that it is really error-prone to do
 introspection and inspection. If you are asked if table foo, tbl exists
 you must know if the foo, tbl is from the model, or from database. If it
 is from a model, you must do conversion to database format first. The
 problem is, in the patch it isn't at all clear when you have database
 format, and when you have Model's format. It works, but mostly by luck. My
 current idea for fixing this is to introduce two namedtuples, DBQname and
 ModelQName so that it is possible to assert the methods get data in the
 format they expect.

 But the most important question at the moment is how much we want schema
 support? I am sure this feature would cause headaches for schema
 migrations for example. Obviously I would like the schema support in core,
 but I think a final design decision is needed, as the feature as
 implemented is much larger and complex than one would have thought
 beforehand. So, I will mark this ticket as design decision needed.

 One option would be to have schema support, but not for introspection. The
 problem with this approach is that you can't use the Django's default test
 runner, as you will not be able to flush & create the database without any
 introspection support. In effect, setting model's meta.db_schema to some
 value would imply managed=False.

 Another option is to support this feature only when full schema support is
 available. That would mean PostgreSQL always, and MySQL and Oracle when
 you run the tests on different database instance, so that production and
 testing schemas do not collide. In effect, you would need TEST_PORT and/or
 TEST_HOST in DATABASES to be set to run the tests on MySQL or Oracle (only
 when using schema support, of course).

-- 
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] #16074: Class-based views clash get_context_data

[Django]

#16074: Class-based views clash get_context_data
-+-
 Reporter:  emyller  |Owner:  tobias
 Type:  Bug  |   Status:  closed
Component:  Generic views|  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  cbv  | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by brutasse):

 The commit has `__future__` imports which are not needed anymore since
 trunk is python2.6+.

-- 
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] #18078: Release notes should mention more clearly removed features

[Django]

#18078: Release notes should mention more clearly removed features
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  SVN
 Severity:  Normal|   Resolution:
 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 claudep):

 * has_patch:  0 => 1
 * 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] #17851: Db Field instances cannot be compared to other objects

[Django]

#17851: Db Field instances cannot be compared to other objects
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  field compare|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * stage:  Accepted => Ready for checkin


Comment:

 Note to the committer: transform the test comment in a docstring and
 replace {{{__cmp__}}} by {{{__lt__}}} in the same comment. Apart from
 that, looks good and tests pass.

-- 
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] #18076: rfc3339 default support since 1.4 - DateTimeField

[Django]

#18076: rfc3339 default support since 1.4 - DateTimeField
+--
 Reporter:  anonymous   |Owner:  nobody
 Type:  Uncategorized   |   Status:  closed
Component:  Forms   |  Version:  1.4
 Severity:  Normal  |   Resolution:  needsinfo
 Keywords:  time zones rfc3339  | 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:   => needsinfo
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I fail to see the relationship between time zone support and RFC 3339.
 From the end user's point of view, this feature doesn't change anything,
 besides avoiding a class of bugs that could easily bit the programmer.

 The design of input formats was centered on formats that humans actually
 use. Since RFC 3339 isn't a format that average users write spontaneously,
 I don't see much of a reason to support it in core.

 Of course, Django makes it very easy to implement your own form field that
 supports (and possibly enforces) RFC 3339 if you need it.

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

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

[Django] #18078: Release notes should mention more clearly removed features

[Django]

#18078: Release notes should mention more clearly removed features
+
   Reporter:  aaugustin |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  SVN
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Currently, it's very easy to miss the link to the deprecation timeline
 located at the beginning of the release notes. As a consequence, there's a
 small but steady flow of tickets complaining about removed features not
 being mentioned.

 We could try to make this link more visible one way or another.

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