date:20120112

Re: [Django] #17449: [patch] Default OPTIONS and improved HEAD in base View class

2012-01-12 Thread Django

#17449: [patch] Default OPTIONS and improved HEAD in base View class
---+--
 Reporter:  estebistec |Owner:  estebistec
 Type:  Bug|   Status:  new
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:  1  |UI/UX:  0
---+--
Changes (by estebistec):

 * needs_docs:  1 => 0


Comment:

 Doc was added in that last 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] #17449: [patch] Default OPTIONS and improved HEAD in base View class

2012-01-12 Thread Django

#17449: [patch] Default OPTIONS and improved HEAD in base View class
---+--
 Reporter:  estebistec |Owner:  estebistec
 Type:  Bug|   Status:  new
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by estebistec):

 Replying to [comment:7 claudep]:
 > Small bikeshedding: all !HttpResponse subclasses begin with
 !HttpResponse, that's why I'd rather name the class !HttpResponseOptions,
 unless you have a specific reason not to adopt the model.
 >
 > Then I think it should be mentioned on
 https://docs.djangoproject.com/en/1.3/ref/request-response/#httpresponse-
 subclasses

 Both valid points. Updated patch forthcoming.

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

2012-01-12 Thread 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
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 will@…):

 * cc: will@… (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] #13914: Add natural keys to contrib.auth.User and Group models

2012-01-12 Thread Django

#13914: Add natural keys to contrib.auth.User and Group models
-+-
 Reporter:  jbochi   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  Contrib, Auth,   | Triage Stage:  Accepted
  User, Group, natural keys  |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by jbochi):

 I have checked that data dumped without natural keys can still be loaded
 after this change. The tests were included in the new diff.

-- 
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] #17419: JSON template tag

2012-01-12 Thread Django

#17419: JSON template tag
---+---
 Reporter:  lau|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Template system|  Version:  1.4-alpha-1
 Severity:  Normal |   Resolution:
 Keywords:  json template tag  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+---
Changes (by aaugustin):

 * needs_better_patch:  0 => 1


Comment:

 I don't believe marking the output as safe by default is the right thing
 to do.

 Not everyone adds CDATA markers to its

Re: [Django] #9198: templatetag include adds new line

2012-01-12 Thread Django

#9198: templatetag include adds new line
-+-
 Reporter:  versae   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  1.0
 Severity:  Normal   |   Resolution:  duplicate
 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 aaugustin):

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


Comment:

 I believe this is a special case of #2594.

-- 
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] #13342: MultiValueField - incorrectly use 'required' attribute of MultiValueField for child field validation

2012-01-12 Thread Django

#13342: MultiValueField - incorrectly use 'required' attribute of 
MultiValueField
for child field validation
-+-
 Reporter:  krejcik  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  fields required  | Triage Stage:
  MultiValueField|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by fero):

 * status:  closed => reopened
 * severity:   => Normal
 * resolution:  wontfix =>
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => Bug


Comment:

 Is it allowed to reopen this ticket please?
 Sorry if it is not the right procedure, but I'd like to post some notes
 about this ticket and consequent decision made.

 Behaviour proposed by krejcik sounds good to me because when I have a
 required !MultiValueField, my idea is to require that the whole stuff that
 resides inside validates. Not each single piece, but as one big picture.
 What there is inside is not myproblem.

 Each field that are inside the !MultiValueField knows by itself if it is
 required or not, and because of this they raises validation errors or not.

 My example is a `PlaceField(forms.MultiValueField)` developed to set an
 address which is composed by:

 * Name
 * Address
 * ZIP
 * City
 * State

 Name or address could be blank (not at the same time both), so can be ZIP.

 My needing is that a place MUST be specificed, so !PlaceField must be a
 required=True field,
 BUT to specify a place is NOT REQUIRED to specify address and ZIP so I
 SHOULD have the ability
 to tell that nested fields address and ZIP are not required, and, IMHO,
 Django must respect the constraint.

 My !PlaceField sounds like this

 {{{
 class PlaceField(forms.MultiValueField):
 widget = PlaceWidget
 def __init__(self, *args, **kw):
 fields = (
 forms.IntegerField(), # was: label=_("id")
 forms.CharField(label=_("name")),
 forms.CharField(label=_("address"), required=False),
 forms.CharField(label=_("zip"), required=False),
 forms.CharField(label=_("city")),
 forms.ChoiceField(label=_("state"),choices=PlaceField.STATE_CHOICES),
 )
 super(PlaceField, self).__init__(fields, *args, **kw)
 }}}


 or am I totally wrong?

-- 
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] #15092: Built-in template tags "now" don't accept simple quote

2012-01-12 Thread Django

#15092: Built-in template tags "now" don't accept simple quote
---+
 Reporter:  ninja_otoko|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Template system|  Version:  1.2
 Severity:  Normal |   Resolution:
 Keywords:  template tags,now  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

 * needs_better_patch:  1 => 0
 * ui_ux:   => 0
 * easy:   => 0


Comment:

 I'm attaching an updated patch. It breaks one test: 'now02', but I'm not
 convinced by that test at all, nor by 'now03' and 'now04' that are
 commented out since they were introduced, at the merge of magic-removal.

 I'm suggest to remove these tests and normalize the behavior of `{% now
 ... %}` as shown in the attached 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] #17538: default URLconf import is wrong

2012-01-12 Thread Django

#17538: default URLconf import is wrong
---+
 Reporter:  matt@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  fixed
 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 carljm):

 In [17370]:
 {{{
 #!CommitTicketReference repository="" revision="17370"
 Fixed #17538 -- corrected the section in tutorial 3 about the handler404
 default. Thanks matt at brozowski dot com for the report.

 Backport of r17369 from trunk.
 }}}

-- 
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] r17370 - django/branches/releases/1.3.X/docs/intro

2012-01-12 Thread noreply

Author: carljm
Date: 2012-01-12 14:17:22 -0800 (Thu, 12 Jan 2012)
New Revision: 17370

Modified:
   django/branches/releases/1.3.X/docs/intro/tutorial03.txt
Log:
Fixed #17538 -- corrected the section in tutorial 3 about the handler404 
default. Thanks matt at brozowski dot com for the report.

Backport of r17369 from trunk.

Modified: django/branches/releases/1.3.X/docs/intro/tutorial03.txt
===
--- django/branches/releases/1.3.X/docs/intro/tutorial03.txt2012-01-12 
22:03:34 UTC (rev 17369)
+++ django/branches/releases/1.3.X/docs/intro/tutorial03.txt2012-01-12 
22:17:22 UTC (rev 17370)
@@ -365,17 +365,16 @@
 format the normal URLconf callbacks use. A 404 view itself has nothing
 special: It's just a normal view.
 
-You normally won't have to bother with writing 404 views. By default, URLconfs
-have the following line up top::
+You normally won't have to bother with writing 404 views. If you don't set
+``handler404``, the built-in view :func:`django.views.defaults.page_not_found`
+is used by default. In this case, you still have one obligation: To create a
+``404.html`` template in the root of your template directory. The default 404
+view will use that template for all 404 errors. If :setting:`DEBUG` is set to
+``False`` (in your settings module) and if you didn't create a ``404.html``
+file, an ``Http500`` is raised instead.  So remember to create a ``404.html``.
 
-from django.conf.urls.defaults import *
+A couple more things to note about 404 views:
 
-That takes care of setting ``handler404`` in the current module. As you can see
-in ``django/conf/urls/defaults.py``, ``handler404`` is set to
-:func:`django.views.defaults.page_not_found` by default.
-
-Four more things to note about 404 views:
-
 * If :setting:`DEBUG` is set to ``True`` (in your settings module) then 
your
   404 view will never be used (and thus the ``404.html`` template will 
never
   be rendered) because the traceback will be displayed instead.
@@ -383,15 +382,6 @@
 * The 404 view is also called if Django doesn't find a match after checking
   every regular expression in the URLconf.
 
-* If you don't define your own 404 view -- and simply use the default, 
which
-  is recommended -- you still have one obligation: To create a ``404.html``
-  template in the root of your template directory. The default 404 view 
will
-  use that template for all 404 errors.
-
-* If :setting:`DEBUG` is set to ``False`` (in your settings module) and if
-  you didn't create a ``404.html`` file, an ``Http500`` is raised instead.
-  So remember to create a ``404.html``.
-
 Write a 500 (server error) view
 ===
 

-- 
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] #17538: default URLconf import is wrong

2012-01-12 Thread Django

#17538: default URLconf import is wrong
---+
 Reporter:  matt@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  fixed
 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 carljm):

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


Comment:

 In [17369]:
 {{{
 #!CommitTicketReference repository="" revision="17369"
 Fixed #17538 -- corrected the section in tutorial 3 about the handler404
 default. Thanks matt at brozowski dot com for the 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.

Re: [Django] #17538: default URLconf import is wrong

2012-01-12 Thread Django

#17538: default URLconf import is wrong
---+
 Reporter:  matt@… |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  Documentation  |  Version:  1.3
 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 aaugustin):

 So much for late night triage :/ Please accept my apologies.

-- 
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] r17369 - django/trunk/docs/intro

2012-01-12 Thread noreply

Author: carljm
Date: 2012-01-12 14:03:34 -0800 (Thu, 12 Jan 2012)
New Revision: 17369

Modified:
   django/trunk/docs/intro/tutorial03.txt
Log:
Fixed #17538 -- corrected the section in tutorial 3 about the handler404 
default. Thanks matt at brozowski dot com for the report.

Modified: django/trunk/docs/intro/tutorial03.txt
===
--- django/trunk/docs/intro/tutorial03.txt  2012-01-12 21:55:19 UTC (rev 
17368)
+++ django/trunk/docs/intro/tutorial03.txt  2012-01-12 22:03:34 UTC (rev 
17369)
@@ -363,17 +363,16 @@
 format the normal URLconf callbacks use. A 404 view itself has nothing
 special: It's just a normal view.
 
-You normally won't have to bother with writing 404 views. By default, URLconfs
-have the following line up top::
+You normally won't have to bother with writing 404 views. If you don't set
+``handler404``, the built-in view :func:`django.views.defaults.page_not_found`
+is used by default. In this case, you still have one obligation: To create a
+``404.html`` template in the root of your template directory. The default 404
+view will use that template for all 404 errors. If :setting:`DEBUG` is set to
+``False`` (in your settings module) and if you didn't create a ``404.html``
+file, an ``Http500`` is raised instead.  So remember to create a ``404.html``.
 
-from django.conf.urls import patterns, include, url
+A couple more things to note about 404 views:
 
-That takes care of setting ``handler404`` in the current module. As you can see
-in ``django/conf/urls/defaults.py``, ``handler404`` is set to
-:func:`django.views.defaults.page_not_found` by default.
-
-Four more things to note about 404 views:
-
 * If :setting:`DEBUG` is set to ``True`` (in your settings module) then your
   404 view will never be used (and thus the ``404.html`` template will never
   be rendered) because the traceback will be displayed instead.
@@ -381,15 +380,6 @@
 * The 404 view is also called if Django doesn't find a match after checking
   every regular expression in the URLconf.
 
-* If you don't define your own 404 view -- and simply use the default, which
-  is recommended -- you still have one obligation: To create a ``404.html``
-  template in the root of your template directory. The default 404 view will
-  use that template for all 404 errors.
-
-* If :setting:`DEBUG` is set to ``False`` (in your settings module) and if
-  you didn't create a ``404.html`` file, an ``Http500`` is raised instead.
-  So remember to create a ``404.html``.
-
 Write a 500 (server error) view
 ===
 

-- 
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] r17368 - in django/trunk: django/db/backends tests/regressiontests/transactions_regress

2012-01-12 Thread noreply

Author: aaugustin
Date: 2012-01-12 13:55:19 -0800 (Thu, 12 Jan 2012)
New Revision: 17368

Modified:
   django/trunk/django/db/backends/util.py
   django/trunk/tests/regressiontests/transactions_regress/tests.py
Log:
Fixed #6669 -- Ensured database connections are marked as dirty by 
CursorDebugWrapper.execute/executemany. Refs #9964. Thanks james at 10gic net 
for the report and Claude Paroz for the patch.


Modified: django/trunk/django/db/backends/util.py
===
--- django/trunk/django/db/backends/util.py 2012-01-11 10:19:05 UTC (rev 
17367)
+++ django/trunk/django/db/backends/util.py 2012-01-12 21:55:19 UTC (rev 
17368)
@@ -16,9 +16,12 @@
 self.cursor = cursor
 self.db = db
 
-def __getattr__(self, attr):
+def set_dirty(self):
 if self.db.is_managed():
 self.db.set_dirty()
+
+def __getattr__(self, attr):
+self.set_dirty()
 if attr in self.__dict__:
 return self.__dict__[attr]
 else:
@@ -31,6 +34,7 @@
 class CursorDebugWrapper(CursorWrapper):
 
 def execute(self, sql, params=()):
+self.set_dirty()
 start = time()
 try:
 return self.cursor.execute(sql, params)
@@ -47,6 +51,7 @@
 )
 
 def executemany(self, sql, param_list):
+self.set_dirty()
 start = time()
 try:
 return self.cursor.executemany(sql, param_list)

Modified: django/trunk/tests/regressiontests/transactions_regress/tests.py
===
--- django/trunk/tests/regressiontests/transactions_regress/tests.py
2012-01-11 10:19:05 UTC (rev 17367)
+++ django/trunk/tests/regressiontests/transactions_regress/tests.py
2012-01-12 21:55:19 UTC (rev 17368)
@@ -4,6 +4,7 @@
 from django.db import connection, transaction
 from django.db.transaction import commit_on_success, commit_manually, 
TransactionManagementError
 from django.test import TransactionTestCase, skipUnlessDBFeature
+from django.test.utils import override_settings
 from django.utils.unittest import skipIf
 
 from .models import Mod, M2mA, M2mB
@@ -166,7 +167,14 @@
 except:
 self.fail("A transaction consisting of a failed operation was not 
closed.")
 
+@override_settings(DEBUG=True)
+def test_failing_query_transaction_closed_debug(self):
+"""
+Regression for #6669. Same test as above, with DEBUG=True.
+"""
+self.test_failing_query_transaction_closed()
 
+
 class TestManyToManyAddTransaction(TransactionTestCase):
 def test_manyrelated_add_commit(self):
 "Test for https://code.djangoproject.com/ticket/16818";

-- 
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] #6669: @transaction.commit_on_success does not rollback when it should

2012-01-12 Thread Django

#6669: @transaction.commit_on_success does not rollback when it should
-+-
 Reporter:  james@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  transaction, commit  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 In [17368]:
 {{{
 #!CommitTicketReference repository="" revision="17368"
 Fixed #6669 -- Ensured database connections are marked as dirty by
 CursorDebugWrapper.execute/executemany. Refs #9964. Thanks james at 10gic
 net for the report and Claude Paroz 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] #9964: Transaction middleware closes the transaction only when it's marked as dirty

2012-01-12 Thread Django

#9964: Transaction middleware closes the transaction only when it's marked as
dirty
-+-
 Reporter:  ishirav  |Owner:
 Type:  Uncategorized|  mtredinnick
Component:  Database layer   |   Status:  closed
  (models, ORM)  |  Version:
 Severity:  Normal   |  1.0-beta-1
 Keywords:  transactions |   Resolution:  fixed
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 In [17368]:
 {{{
 #!CommitTicketReference repository="" revision="17368"
 Fixed #6669 -- Ensured database connections are marked as dirty by
 CursorDebugWrapper.execute/executemany. Refs #9964. Thanks james at 10gic
 net for the report and Claude Paroz 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] #17538: default URLconf import is wrong

2012-01-12 Thread Django

#17538: default URLconf import is wrong
---+
 Reporter:  matt@… |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  Documentation  |  Version:  1.3
 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 carljm):

 * status:  closed => reopened
 * type:  Uncategorized => Bug
 * resolution:  worksforme =>
 * stage:  Unreviewed => Accepted


Comment:

 No, unlike those other reports, this one's an actual bug in the tutorial,
 both the trunk and the 1.3 version.

 In both trunk and 1.3, the generated urls.py does not use "import *", and
 there is a built-in default for handler404 (so it's not necessary to have
 a handler404 in root urls.py at all). The "Write a 404 (page not found)
 view" section of tutorial part 3 is wrong in the 1.3 docs because it says
 the default line includes the "*"; in the dev docs the "*" was replaced
 with "patterns, url, include". But in both versions that section is simply
 wrong, because the default handler404 doesn't depend on any import at all
 anymore.

 Thanks for the report, Matt!

-- 
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] #17538: default URLconf import is wrong

2012-01-12 Thread Django

#17538: default URLconf import is wrong
---+--
 Reporter:  matt@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  worksforme
 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:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => worksforme
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 You are using the development version of the docs with a previous version
 of Django.

 See of #17505, #17456, #17353, and several others.

-- 
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] #17538: default URLconf import is wrong

2012-01-12 Thread Django

#17538: default URLconf import is wrong
---+
 Reporter:  matt@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Tutorial 3 has the following sentence:

 By default, URLconfs have the following line up top:

 from django.conf.urls.defaults import *


 But in the urls.pl generated for me it did not have that but rather had:

 from django.conf.urls.defaults import patterns, include, url

-- 
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] #16759: Expensive sql.Query cloning

2012-01-12 Thread Django

#16759: Expensive sql.Query cloning
-+-
 Reporter:  Suor |Owner:  Suor
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  orm performance  |  Needs documentation:  0
  cloning|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 I removed the above mentioned ugliness by moving .clone() from
 utils/tree.py() to db/models/sql/where.py. There is no abstraction leak
 any more.

-- 
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] #16220: Add introspection for multicolumn indexes

2012-01-12 Thread Django

#16220: Add introspection for multicolumn indexes
-+-
 Reporter:  jgelens  |Owner:  jgelens
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:  dceu2011 inspectdb   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by hvdklauw):

 I did note some inconsistencies between the different backends. (SQLite
 didn't output unique indexes)

 Now they do the same, still not sure about the key values, you can't use
 the field name as there might be multiple.

 I don't have access or knowledge of Oracle, so someone who does should fix
 that; also haven't written tests because django by itself doesn't support
 adding indexes on multiple fields (need #5805 for that, which in turn
 needs this to do tests)

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

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

Re: [Django] #16759: Expensive sql.Query cloning

2012-01-12 Thread Django

#16759: Expensive sql.Query cloning
-+-
 Reporter:  Suor |Owner:  Suor
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  orm performance  |  Needs documentation:  0
  cloning|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * needs_better_patch:  1 => 0


Comment:

 I cleaned up the patch, I think it is good to go. Aggregates are handled
 by copy.copy now, and there is an assert that subtree_parents is empty
 when cloning. I removed all deepcopy references from sql/query.py

 There is one bad abstraction leak: tree.clone() must know the internal
 structure of queryset's lookup condition tuples. The fix would be to
 create a class for these tuples also. This would be a quite big change,
 but I think it would make the code much cleaner in sql/query.py and
 sql/where.py, too.

 The speed is from 30% to 60% faster for three simple test-cases, query
 construction only (not compiling it to sql, or executing the sql):
 {{{
 Test 1, 1000x TestModel.objects.all().filter(pk=1)
 Test 2, 1000x TestModel.objects.all().filter(pk=1).filter(pk=1)
 Test 3, 1000x
 TestModel.objects.all().filter(pk=1).filter(pk=1).filter(pk=1)
 }}}

 I would expect 70%+ speedup is possible for complex realworld queries.

 All tests passed on sqlite3.

 I think there is still much room for improvement, but this is the low-
 hanging fruit. I do think this would be a good candidate for 1.4. I have
 seen reports of 200+ms time used for queryset construction for single page
 load. So the problem is real.

-- 
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] #17449: [patch] Default OPTIONS and improved HEAD in base View class

2012-01-12 Thread Django

#17449: [patch] Default OPTIONS and improved HEAD in base View class
---+--
 Reporter:  estebistec |Owner:  estebistec
 Type:  Bug|   Status:  new
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by claudep):

 * needs_docs:  0 => 1


Comment:

 Small bikeshedding: all !HttpResponse subclasses begin with !HttpResponse,
 that's why I'd rather name the class !HttpResponseOptions, unless you have
 a specific reason not to adopt the model.

 Then I think it should be mentioned on
 https://docs.djangoproject.com/en/1.3/ref/request-response/#httpresponse-
 subclasses

-- 
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] #14964: create_attachment support for unicode symbols in filename

2012-01-12 Thread Django

#14964: create_attachment support for unicode symbols in filename
-+-
 Reporter:  Anton Chaporgin  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  email attachment,| Triage Stage:  Accepted
  filenames, i18n|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * needs_better_patch:  1 => 0
 * type:  New feature => Bug
 * needs_tests:  1 => 0


Comment:

 My patch was inspired by
 
http://docs.python.org/library/email.message.html#email.message.Message.add_header

-- 
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] #10938: add inlines into fieldsets

2012-01-12 Thread Django

#10938: add inlines into fieldsets
---+-
 Reporter:  ctao   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  inlines fieldsets  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+-
Changes (by gezuru@…):

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


Comment:

 With the syntax proposition by melinath this ticket has become a duplicate
 of #4848.

-- 
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] #10938: add inlines into fieldsets

2012-01-12 Thread Django

#10938: add inlines into fieldsets
---+
 Reporter:  ctao   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  inlines fieldsets  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by gezuru@…):

 * cc: gezuru@… (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] #17118: list_editable will update wrong rows on a multiuser system if pagination is enabled

2012-01-12 Thread Django

#17118: list_editable will update wrong rows on a multiuser system if 
pagination is
enabled
-+-
 Reporter:  emilianodelvalle@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  list_editable list   | Triage Stage:
  multiuser  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by chad.lyon@…):

 That work around doesn't work but is really close. I think you want to
 avoid using the query set altogether when list editing because it could
 possibly return different results than it did when the list to be edited
 was POSTed. This actually works as a work around:

 {{{
 def _existing_object(self, pk):
 return self.model._default_manager.get_query_set().get(pk = pk)
 }}}

 ...but has side effects. For example, what if another user deletes one of
 the items in the list to be edited? This workaround will raise
 {{{DoesNotExist}}}. Django committers need to get busy on the solution
 talked about in #11313 because this bug is really ugly.

-- 
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] #17536: Filename encoding broken for attachments in EmailMessage class

2012-01-12 Thread Django

#17536: Filename encoding broken for attachments in EmailMessage class
-+-
 Reporter:  alexey   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  SVN
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  EmailMessage,| Triage Stage:
  broken encoding, unicode, i18n |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


Comment:

 Duplicate of #14964

-- 
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] #17535: list_detail call to len(queryset) should be queryset.exists()

2012-01-12 Thread Django

#17535: list_detail call to len(queryset) should be queryset.exists()
--+
 Reporter:  hedleyroos@…  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Generic views |  Version:  1.3
 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 claudep):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 The code you mention is in deprecated code. Moreover, this  queryset
 evaluation is done in the non paginated section of the context build. The
 query, even if large, would be evaluated anyway later in the code. So this
 part seems a 'won't fix' for me.

 However, the issue is similar in the new class-based view code
 
(https://code.djangoproject.com/browser/django/trunk/django/views/generic/list.py#L116).
 And in this case, the len(queryset)==0 is done before the pagination take
 place. So this might be an issue.

 If you take the case of a costly query with not so many results, your
 proposal would call the query twice (once for exists and once for the real
 query), hence resulting in poorer performance when the query is not empty.
 Your solution might be better for a quick query that returns many results.
 The real solution would be probably to follow the same logic than the old
 function-based view and do this test later in the process
 (get_context_data).

-- 
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] #17537: Writing your first Django app, part 4 - Generic Views - Update to index.html needed

2012-01-12 Thread Django

#17537: Writing your first Django app, part 4 - Generic Views - Update to
index.html needed
+
 Reporter:  canice_lambe@…  |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Documentation   |Version:  1.3
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I could only get the Generic Views to work after I gave the detail view a
 name 'poll_details' in the urlpatterns and updated index.html to have
 line:

 {{ poll.id }}.
 {{ poll.question }}

-- 
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] #17536: Filename encoding broken for attachments in EmailMessage class

2012-01-12 Thread Django

#17536: Filename encoding broken for attachments in EmailMessage class
-+-
 Reporter:  alexey   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  EmailMessage,| Triage Stage:
  broken encoding, unicode, i18n |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by alexey):

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


Comment:

 It seems that bug is in _create_attachment method. I solved this by
 monkey-patching:

 {{{
 def _create_attachment(self, filename, content, mimetype=None):
 """
 Converts the filename, content, mimetype triple into a MIME attachment
 object.
 """
 if mimetype is None:
 mimetype, _ = mimetypes.guess_type(filename)
 if mimetype is None:
 mimetype = DEFAULT_ATTACHMENT_MIME_TYPE
 attachment = self._create_mime_attachment(content, mimetype)
 if filename:
 attachment.add_header('Content-Disposition', 'attachment',
 filename=('utf-8','',filename)) # Changed here!!!
 return attachment
 }}}

-- 
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] #17536: Filename encoding broken for attachments in EmailMessage class

2012-01-12 Thread Django

#17536: Filename encoding broken for attachments in EmailMessage class
-+-
 Reporter:  alexey   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core |Version:  SVN
  (Mail) |   Keywords:  EmailMessage, broken encoding,
 Severity:  Normal   |  unicode, i18n
 Triage Stage:   |  Has patch:  0
  Unreviewed |  UI/UX:  0
Easy pickings:  0|
-+-
 Message encoding broken if creating messages with EmailMessage class.

 Test case:
 {{{#!python
 subject = u"Тест"
 body = u"Тест"
 recepients = ["t...@test.com"]

 filename = u"тест.txt"
 report = "some binary data"

 email = EmailMessage(subject,body,to=recepients)
 email.attach(filename.encode("utf-8"),report)
 email.send()
 }}}

 filename will NOT be properly encoded and pushed into the message "as is".
 And some email clients such as MS Outlook will show broken stuff instead
 of filename.

-- 
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] #17535: list_detail call to len(queryset) should be queryset.exists()

2012-01-12 Thread Django

#17535: list_detail call to len(queryset) should be queryset.exists()
--+
 Reporter:  hedleyroos@…  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Generic views |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Refer to
 
https://code.djangoproject.com/browser/django/trunk/django/views/generic/list_detail.py#L97.
 The line `if not allow_empty and len(queryset) == 0` executes slowly for
 large querysets. We are already dealing with a real Queryset and not just
 any iterable (there is an earlier call queryset._clone) so we can use the
 `exists` method. I propose `if not allow_empty and not queryset.exists()`.

-- 
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] #17449: [patch] Default OPTIONS and improved HEAD in base View class

Re: [Django] #17449: [patch] Default OPTIONS and improved HEAD in base View class

Re: [Django] #16426: sqlite: Cannot delete more than 999 things if there is a relation pointing to them

Re: [Django] #13914: Add natural keys to contrib.auth.User and Group models

Re: [Django] #17419: JSON template tag

Re: [Django] #9198: templatetag include adds new line

Re: [Django] #13342: MultiValueField - incorrectly use 'required' attribute of MultiValueField for child field validation

Re: [Django] #15092: Built-in template tags "now" don't accept simple quote

Re: [Django] #17538: default URLconf import is wrong

[Changeset] r17370 - django/branches/releases/1.3.X/docs/intro

Re: [Django] #17538: default URLconf import is wrong

Re: [Django] #17538: default URLconf import is wrong

[Changeset] r17369 - django/trunk/docs/intro

[Changeset] r17368 - in django/trunk: django/db/backends tests/regressiontests/transactions_regress

Re: [Django] #6669: @transaction.commit_on_success does not rollback when it should

Re: [Django] #9964: Transaction middleware closes the transaction only when it's marked as dirty

Re: [Django] #17538: default URLconf import is wrong

Re: [Django] #17538: default URLconf import is wrong

[Django] #17538: default URLconf import is wrong

Re: [Django] #16759: Expensive sql.Query cloning

Re: [Django] #16220: Add introspection for multicolumn indexes

Re: [Django] #16759: Expensive sql.Query cloning

Re: [Django] #17449: [patch] Default OPTIONS and improved HEAD in base View class

Re: [Django] #14964: create_attachment support for unicode symbols in filename

Re: [Django] #10938: add inlines into fieldsets

Re: [Django] #10938: add inlines into fieldsets

Re: [Django] #17118: list_editable will update wrong rows on a multiuser system if pagination is enabled

Re: [Django] #17536: Filename encoding broken for attachments in EmailMessage class

Re: [Django] #17535: list_detail call to len(queryset) should be queryset.exists()

[Django] #17537: Writing your first Django app, part 4 - Generic Views - Update to index.html needed

Re: [Django] #17536: Filename encoding broken for attachments in EmailMessage class

[Django] #17536: Filename encoding broken for attachments in EmailMessage class

[Django] #17535: list_detail call to len(queryset) should be queryset.exists()

33 matches

Site Navigation

Mail list logo

Footer information