date:20140206

Re: [Django] #19705: CommonMiddleware handles If-None-Match incorrectly

2014-02-06 Thread Django

#19705: CommonMiddleware handles If-None-Match incorrectly
---+
 Reporter:  aaugustin  |Owner:
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by hirokiky):

 * owner:  hirokiky =>
 * status:  assigned => new


Comment:

 I de-assign once time. because I won't try to fix this problem these days.
 sorry.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f32e43f674e8945d19b093a7d368eea0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21954: 1.7a1 - Migration syntax error

2014-02-06 Thread Django

#21954: 1.7a1 - Migration syntax error
-+---
 Reporter:  caulagi  |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7-alpha-1
 Severity:  Release blocker  |   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 caulagi):

 * cc: caulagi (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.714d71c03394ba17f0e0ea5ca1eabd3e%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6186: New signal needed - post_create

2014-02-06 Thread Django

#6186: New signal needed - post_create
---+--
 Reporter:  italomaia  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.3-alpha
 Severity:  Normal |   Resolution:  invalid
 Keywords:  signals| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by efgSYH):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * version:  master => 1.3-alpha
 * easy:   => 0
 * severity:   => Normal


Comment:

 http://vccool.org/pdf/#nds>visit website buy provigil online
 us - provigil generic alertec

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6dfeb8120ed4d9d5174620174fe88a00%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16855: select_related doesn't chain as expected

2014-02-06 Thread Django

#16855: select_related doesn't chain as expected
-+-
 Reporter:  Leo  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mrmachine):

 * cc: real.human@… (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.63bd001e85858bbad2ee191fcd2340f1%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16855: select_related doesn't chain as expected

2014-02-06 Thread Django

#16855: select_related doesn't chain as expected
-+-
 Reporter:  Leo  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mrmachine):

 Please do not further reduce the functionality of `select_related()` by
 removing the no-arguments variant (select all related, with a high hard
 coded depth limit to prevent recursive joins).

 I use `select_related()` with no arguments all the time, as I have found
 that in almost all my use cases, following too many joins and returning
 more data than may be necessary is still much more performant than
 returning too little data, and subsequently having template authors
 generate additional queries by accessing related fields that were not
 selected in the view.

 It also saves the view programmer from tediously listing larger numbers of
 related fields when they legitimately want to select most or all related
 fields, and avoids the need for view programmers to know in advance which
 related fields a template author will want to access.

 I much rather fallback to naming explicit fields in `select_related()`
 only when there is an actual performance problem because of too many
 joins, instead of premature optimisation by trying to explicitly list all
 relations, and having to re-visit that code when a template or model
 changes.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.390c49f485e300b5637ab88e129f372a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21961: ForeignKey.on_delete supports database-level cascading options

2014-02-06 Thread Django

#21961: ForeignKey.on_delete supports database-level cascading options
-+-
 Reporter:  Xof  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-1
 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 shai):

 1+2 => When using CASCADE_DB, signals will fire only on backends which do
 not support the feature.

 Similar issues, of course, for 1+3, 1+5.

 I find this result quite disturbing.

 Alternative: When using CASCADE_DB on a backend where the database cannot
 implement it, Django tries to emulate it; this is ''not'' equivalent to
 CASCADE.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.c2fc10ee76118a81161ddcb14c8caa14%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21595: Automatically call as_view() when urlpatterns encounter a CBV.

2014-02-06 Thread Django

#21595: Automatically call as_view() when urlpatterns encounter a CBV.
-+-
 Reporter:  loic84   |Owner:
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Core (URLs)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by russellm):

 This was considered and rejected as part of the original CBV work. See
 [https://code.djangoproject.com/wiki/ClassBasedViews the wiki] for the
 rationale.

 Short version: it's all about keeping a simple contract for urlpatterns.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.d6fceace09791ed58b49feff9ecab326%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21969: Dependent apps do not handle fixture data properly when migration

2014-02-06 Thread Django

#21969: Dependent apps do not handle fixture data properly when migration
-+--
 Reporter:  Ubercore |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Ubercore):

 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_docs:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.081d9d7187d44f5976d611d948c49c15%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21968: Django doesn't detect initial migration when an app is a dependency

2014-02-06 Thread Django

#21968: Django doesn't detect initial migration when an app is a dependency
-+--
 Reporter:  Ubercore |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Ubercore):

 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.07958b2aa787be693087a0a0ee9a6cb9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21969: Dependent apps do not handle fixture data properly when migration

2014-02-06 Thread Django

#21969: Dependent apps do not handle fixture data properly when migration
-+
 Reporter:  Ubercore |  Owner:
 Type:  Uncategorized| Status:  new
Component:  Migrations   |Version:  master
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I have {{{ app_a }}}, and {{{ app_b }}}. {{{ app_a }}} lists {{{ app_b }}}
 as a dependency, and {{{ app_b }}} has a fixture in {{{ initial_data.json
 }}}. When I run {{{ ./manage.py migrate }}}, the dependency is resolved
 correctly, and {{{ app_b }}} is migrated first. However, it seems that the
 fixture tries to load before the table exists:

 {{{
 $ ./manage.py migrate
 Operations to perform:
   Synchronize unmigrated apps: evolve, pipeline, mptt, sessions, admin,
 suit_redactor, sites, auth, reversion, contenttypes, django_extensions,
 taggit, suit, easy_thumbnails
   Apply all migrations: content, translation, sites, auth
 Synchronizing apps without migrations:
   Creating tables...
 Creating table django_admin_log
 Creating table auth_permission
 Creating table auth_group_permissions
 Creating table auth_group
 Creating table auth_user_groups
 Creating table auth_user_user_permissions
 Creating table auth_user
 Creating table django_content_type
 Creating table django_session
 Creating table django_site
 Creating table easy_thumbnails_source
 Creating table easy_thumbnails_thumbnail
 Creating table reversion_revision
 Creating table reversion_version
 Creating table taggit_tag
 Creating table taggit_taggeditem
   Installing custom SQL...
   Installing indexes...
 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/vagrant/ENV/src/django/django/core/management/__init__.py",
 line 427, in execute_from_command_line
 utility.execute()
   File "/home/vagrant/ENV/src/django/django/core/management/__init__.py",
 line 419, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/vagrant/ENV/src/django/django/core/management/base.py", line
 287, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/home/vagrant/ENV/src/django/django/core/management/base.py", line
 336, in execute
 output = self.handle(*args, **options)
   File
 "/home/vagrant/ENV/src/django/django/core/management/commands/migrate.py",
 line 125, in handle
 created_models = self.sync_apps(connection,
 executor.loader.unmigrated_apps)
   File
 "/home/vagrant/ENV/src/django/django/core/management/commands/migrate.py",
 line 281, in sync_apps
 call_command('loaddata', 'initial_data', verbosity=self.verbosity,
 database=connection.alias, skip_validation=True)
   File "/home/vagrant/ENV/src/django/django/core/management/__init__.py",
 line 167, in call_command
 return klass.execute(*args, **defaults)
   File "/home/vagrant/ENV/src/django/django/core/management/base.py", line
 336, in execute
 output = self.handle(*args, **options)
   File
 "/home/vagrant/ENV/src/django/django/core/management/commands/loaddata.py",
 line 56, in handle
 self.loaddata(fixture_labels)
   File
 "/home/vagrant/ENV/src/django/django/core/management/commands/loaddata.py",
 line 85, in loaddata
 self.load_label(fixture_label)
   File
 "/home/vagrant/ENV/src/django/django/core/management/commands/loaddata.py",
 line 140, in load_label
 obj.save(using=self.using)
   File "/home/vagrant/ENV/src/django/django/core/serializers/base.py",
 line 172, in save
 models.Model.save_base(self.object, using=using, raw=True)
   File "/home/vagrant/ENV/src/django/django/db/models/base.py", line 630,
 in save_base
 updated = self._save_table(raw, cls, force_insert, force_update,
 using, update_fields)
   File "/home/vagrant/ENV/src/django/django/db/models/base.py", line 692,
 in _save_table
 forced_update)
   File "/home/vagrant/ENV/src/django/django/db/models/base.py", line 736,
 in _do_update
 return filtered._update(values) > 0
   File "/home/vagrant/ENV/src/django/django/db/models/query.py", line 595,
 in _update
 return query.get_compiler(self.db).execute_sql(CURSOR)
   File "/home/vagrant/ENV/src/django/django/db/models/sql/compiler.py",
 line 991, in execute_sql
 cursor = super(SQLUpdateCompiler, self).execute_sql(result_type)
   File "/home/vagrant/ENV/src/django/django/db/models/sql/compiler.py",
 line 779, in execute_sql
 cursor.execute(sql, params)
   File "/home/vagrant/ENV/src/django/django/db/backends/utils.py", line
 77, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/home/vagrant/ENV/src/django/django/db/backends/utils.py", line
 61, in execute
 return self.cursor.execute(sql, params)
   File "/home/vagrant/ENV

[Django] #21968: Django doesn't detect initial migration when an app is a dependency

2014-02-06 Thread Django

#21968: Django doesn't detect initial migration when an app is a dependency
-+
 Reporter:  Ubercore |  Owner:
 Type:  Uncategorized| Status:  new
Component:  Migrations   |Version:  master
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I have app A, and app B, neither of which have migrations defined (new
 project, new apps). app A imports a model as an FK from app B. I make app
 A's migrations with {{{ ./manage.py makemigrations app_a }}}, and {{{
 app_a/migrations/0001_initial.py }}} is created. In it, app B is marked as
 a dependency: {{{ dependencies = [('app_b', '__first__'),] }}}. If I try
 to run {{{ ./manage.py makemigrations app_b }}}, I get {{{ No changes
 detected in app 'app_b' }}}

 If I remove app A's migrations entirely, and re-run app B's
 makemigrations, I get an initial migration as I would expect.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.697ec353c4f95fd09a1fc622f3a319c9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] c58a98: Updated 1.6.2 release notes for release (and linki...

2014-02-06 Thread GitHub

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: c58a98cc34d471d743cd39e873e5b730a372d01b
  
https://github.com/django/django/commit/c58a98cc34d471d743cd39e873e5b730a372d01b
  Author: Jacob Kaplan-Moss 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
M docs/releases/1.6.2.txt

  Log Message:
  ---
  Updated 1.6.2 release notes for release (and linkified tickets).


  Commit: 687b3d96c40d745371c64bca7fe6d46a4e7e379c
  
https://github.com/django/django/commit/687b3d96c40d745371c64bca7fe6d46a4e7e379c
  Author: Jacob Kaplan-Moss 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
M django/__init__.py

  Log Message:
  ---
  Bump version number for 1.6.2.


  Commit: 63d69837463abb6b660da34be5d762f6b5c6fcea
  
https://github.com/django/django/commit/63d69837463abb6b660da34be5d762f6b5c6fcea
  Author: Jacob Kaplan-Moss 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
M django/__init__.py

  Log Message:
  ---
  Bumped version number post-release.


Compare: https://github.com/django/django/compare/5f03b0691999...63d69837463a

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52f40e5685871_51f4acdd341520e5%40hookshot-fe10-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 43510c: Bumped version number for 1.7a2

2014-02-06 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 43510cffcbf64e73232da1d6209151c7232fd2b6
  
https://github.com/django/django/commit/43510cffcbf64e73232da1d6209151c7232fd2b6
  Author: Jacob Kaplan-Moss 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
M django/__init__.py

  Log Message:
  ---
  Bumped version number for 1.7a2


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52f40dd7c743f_1dcf125dd386415d%40hookshot-fe8-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21763: Misleading Error: 'ManyRelatedManager' object has no attribute 'add'

2014-02-06 Thread Django

#21763: Misleading Error: 'ManyRelatedManager' object has no attribute 'add'
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-

Comment (by timo):

 Looks like the file to modify here will be
 django/db/models/fields/related.py. In particular, look for the comment
 "If the ManyToMany relation has an intermediary model". The `if
 rel.through._meta.auto_created` guard that currently prevents `add()` and
 `remove()` from being added should be moved inside those methods and an
 exception raised something like: `raise AttributeError("add() is disabled
 for ManyToManyFields with through() models.")` It looks like `create()`
 already throws an `AttributeError` with a message. I haven't looked into
 if we can do something similar for direct assignment (the 3rd case in the
 above comment).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c808c012232a44e84690e917403b1488%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 43510c: Bumped version number for 1.7a2

2014-02-06 Thread GitHub

  Branch: refs/tags/1.7a2
  Home:   https://github.com/django/django
  Commit: 43510cffcbf64e73232da1d6209151c7232fd2b6
  
https://github.com/django/django/commit/43510cffcbf64e73232da1d6209151c7232fd2b6
  Author: Jacob Kaplan-Moss 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
M django/__init__.py

  Log Message:
  ---
  Bumped version number for 1.7a2


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52f404c62583b_5f3e1399d3c2708a1%40hookshot-fe7-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 84fb7b: Updated 1.6.2 release notes for release (and linki...

2014-02-06 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 84fb7b468e941602f8f7edccc198dd21f8c9734d
  
https://github.com/django/django/commit/84fb7b468e941602f8f7edccc198dd21f8c9734d
  Author: Jacob Kaplan-Moss 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
M docs/releases/1.6.2.txt

  Log Message:
  ---
  Updated 1.6.2 release notes for release (and linkified tickets).


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52f40487efab6_52ac795d3860336%40hookshot-fe10-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] c58a98: Updated 1.6.2 release notes for release (and linki...

2014-02-06 Thread GitHub

  Branch: refs/tags/1.6.2
  Home:   https://github.com/django/django
  Commit: c58a98cc34d471d743cd39e873e5b730a372d01b
  
https://github.com/django/django/commit/c58a98cc34d471d743cd39e873e5b730a372d01b
  Author: Jacob Kaplan-Moss 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
M docs/releases/1.6.2.txt

  Log Message:
  ---
  Updated 1.6.2 release notes for release (and linkified tickets).


  Commit: 687b3d96c40d745371c64bca7fe6d46a4e7e379c
  
https://github.com/django/django/commit/687b3d96c40d745371c64bca7fe6d46a4e7e379c
  Author: Jacob Kaplan-Moss 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
M django/__init__.py

  Log Message:
  ---
  Bump version number for 1.6.2.


Compare: https://github.com/django/django/compare/c58a98cc34d4^...687b3d96c40d

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52f4045062b4a_58551421d408721e%40hookshot-fe12-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21967: ModelFormMixin have extra logic in get_form_kwargs that crash view

2014-02-06 Thread Django

#21967: ModelFormMixin have extra logic in get_form_kwargs that crash view
-+-
 Reporter:   |  Owner:  nobody
  lagovas.lagovas@…  | Status:  new
 Type:  Bug  |Version:  1.6
Component:  Generic views|   Keywords:  generic edit ModelFormMixin
 Severity:  Normal   |  Has patch:  0
 Triage Stage:  Unreviewed   |  UI/UX:  0
Easy pickings:  0|
-+-
 When view inherit FormView and ModelFormMixin, have correct form_class and
 model fields, view will crash with AttributeError at /
 'AddNoteView' object has no attribute 'object'

 in this code:


 {{{
 class ModelFormMixin:
 
 def get_form_kwargs(self):
 """
 Returns the keyword arguments for instantiating the form.
 """
 kwargs = super(ModelFormMixin, self).get_form_kwargs()
 kwargs.update({'instance': self.object})
 return kwargs

 }}}

 It's due to accessing to self.object before form.save(). Even in get
 request, when object can't be exist.

 To check this you need inherit from FormView and ModelFormMixin:

 class AddNoteView(FormView, ModelFormMixin):

 template_name = 'notes.html'
 form_class = NoteForm
 success_url = reverse_lazy('index')
 model = 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.5d22eb1cce6f11ca2869244bb09abfff%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21906: dumpdata should not use router.allow_syncdb

2014-02-06 Thread Django

#21906: dumpdata should not use router.allow_syncdb
-+-
 Reporter:  yscumc   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.5
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yscumc):

 After doing more digging, it seems that `allow_syncdb` is meant to define
 which models are are available on which particular database, and not just
 to prevent syncdb from acting upon a particular database.

 I guess there should be change in logic and I believe the best resolution
 is to rename `allow_syncdb` or document this in the doc just like how the
 historic naming for `use_for_related_fields` is explained in
 https://docs.djangoproject.com/en/1.5/topics/db/managers/#writing-correct-
 managers-for-use-in-automatic-manager-instances

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.55908bee35b7d60adff26e2f8cd04175%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15667: Implement template-based widget rendering

2014-02-06 Thread Django

#15667: Implement template-based widget rendering
+
 Reporter:  brutasse|Owner:  brutasse
 Type:  New feature |   Status:  new
Component:  Forms   |  Version:
 Severity:  Normal  |   Resolution:
 Keywords:  form-rendering  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by Gwildor):

 Are there any updates on this subject? In my humble opinion the widgets
 are one of the ugliest parts of Django codewise and could logically learn
 a lot from how the CBV's work. Most ''render()'' methods are a bit of a
 mess, and this makes creating custom widgets which subclass an existing
 widget, even subclassing something like ''Input'', one of the hardest
 parts of the general things to do with the framework. Why has nothing
 happened in the past two years?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a12eaedeb2ff12389dfe8cdd55cb813d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21595: Automatically call as_view() when urlpatterns encounter a CBV.

2014-02-06 Thread Django

#21595: Automatically call as_view() when urlpatterns encounter a CBV.
-+-
 Reporter:  loic84   |Owner:
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Core (URLs)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Gwildor):

 I'm sorry for commenting on a closed ticket, but I can't seem to find a
 new ticket for this subject. Has a new ticket been opened yet?

 My quick two cents on this subject: perhaps with the eye on the future the
 way the CBV's work should be changed, which I think is a backwards
 compatible change. At the moment, the CBV's actually function as FBV's in
 the urls, because the {{{as_view()}}} method, as the name states, returns
 a function which is ''then'' called with the url dispatching. My proposal:
 when url dispatching happens, call it as a FBV when it's a view (this way
 FBV's and CBV.as_view() are both still supported as they should). If it's
 a class, initialize and call {{{dispatch()}}} on it ({{{__init__}}} should
 probably be rewritten for this, maybe dispatch can be called directly from
 the {{{__init__}}} if it's a class). If it's a class ''instance'', call
 {{{dispatch()}}} on it. This way, you can still pass {{{initkwargs}}} to
 the CBV in the urls, but the whole thing is more clear and generally makes
 more sense in my opinion. Python's {{{inspect}}} module can help with
 these things to check whether it's a function, a class or a class
 instance. A {{{__call___}}} method on the {{{View}}} class might also come
 in handy here.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.c2d3bb668546fb53e0236aae9076b1a2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21966: Incorrect usage of constraint_checks_disabled in tests

2014-02-06 Thread Django

#21966: Incorrect usage of constraint_checks_disabled in tests
---+
Reporter: wlodek | Owner: nobody
Type: Bug| Status: new
Component: Uncategorized |Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
If a backend implements '''enable/disable_constraint_checking''' (using
database SET CONSTRAINTS) some of the tests fail.

The problem comes from the fact that the usage of context manager
"'''constraint_checks_disabled'''" is based not on the assumptions about
how it should work but on the particular implementation for core backends
ie. that constraints are checked at transaction commit.

Because enable/disable_constraint_checking for those backends are empty
constraint_checks_disabled context manager does nothing and the tests pass
while in fact they should fail.

As I understand "assumptions about how it should work" are such that
context manager constraint_checks_disabled is for constraints checks
something like savepoints for transactions, ie. you can mark a set of
statements inside a transaction such the constraints could not be met
inside that set but should at the end of set/exit from context manager.

Affected are tests in 'backends', 'serializers_regress', ...

For example in test_disable_constraint_checks_context_manager save inside
context manager violates constraints IntegrityError should be raised, it
we want to check that it isn't raised we should correct the references
before context manager exit.

{{{
try:
with connection.constraint_checks_disabled():
a.save()
a.reporter_id= self.r.id
a.save()
except IntegrityError:
self.fail("IntegrityError should not have occurred.")
}}}

Beside that there is a question why enable/disable_constraint_checking are
empty for core backends that could implement that like oracle/postgres?
The fact that those backends make use of INITIALY DEFERRED constraints
doesn't mean that those must be empty and so
test_disable_constraint_checks_context_manager unusable.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/049.264ef4b7683897b0e369ac9e6eb21cbd%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21959: widthratio templatetag fails to handle NaN ratio

2014-02-06 Thread Django

Comment (by rmoe):

You just need to call widthratio with float('inf') as both the value and
max_value. like so:

{{{
{% widthratio 'inf' 'inf' 100 %}
}}}

Which will raise this (because ratio is NaN and can't be converted to an
integer):

{{{
ValueError at /project/
cannot convert float NaN to integer

Request Method: GET
Django Version: 1.5.4
Exception Type: ValueError
Exception Value: cannot convert float NaN to integer
Exception Location: /usr/lib/python2.7/dist-
packages/django/template/defaulttags.py in render, line 467
}}}

For some additional context, this was encountered in the Horizon component
of the OpenStack project.

https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/common/_limit_summary.html#L6

When disabling quotas in the Nova component (the data it's trying to build
the pie charts for) all quota values are set to -1 which equates to an
infinite quota. So in the case where quotas are disabled
usage.limits.totalInstancesUsed and usage.limits.maxTotalInstances are
both float('inf'). This breaks the project overview page because of the
exception raised from the widthratio templatetag.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/062.2868368f4d86922e9d30a13707cb5738%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19149: Generic Relation not cascading with Multi table inheritance.

2014-02-06 Thread Django

#19149: Generic Relation not cascading with Multi table inheritance.
-+-
 Reporter:  thomaspurchas|Owner:  nicolas
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  multitable,  |  Needs documentation:  0
  inheritance, genericforeignkey |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by timo):

 I rebased the PR, but there's a failing test:
 {{{
 ==
 FAIL: test_cascade_delete_proxy_model_admin_warning
 (proxy_models.tests.ProxyModelAdminTests)
 --
 Traceback (most recent call last):
   File "/home/tim/code/django/tests/proxy_models/tests.py", line 386, in
 test_cascade_delete_proxy_model_admin_warning
 collector.collect(ProxyTrackerUser.objects.all())
   File "/home/tim/code/django/django/test/testcases.py", line 110, in
 __exit__
 query['sql'] for query in self.captured_queries
 AssertionError: 13 queries executed, 7 expected
 }}}

 Be sure to uncheck "Patch needs improvement" if you can fix it so the
 ticket shows up for review.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.6e47911090ed9c31a03d73baf6b98d15%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21795: preserve_filter doesn't work on production server

2014-02-06 Thread Django

#21795: preserve_filter doesn't work on production server
---+--
 Reporter:  honyczek   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--

Comment (by timo):

 It looks like the `changelist_view` function in contrib.admin.options is
 throwing an `IncorrectLookupParameters` exception. It would be great if
 you could look into the reason for that. I think the fact that you say it
 worked on localhost not on other servers is a red herring.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.f75994ce77dd95279532991c59e27755%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19878: Stop TemplateView automatically passing kwargs into the context

2014-02-06 Thread Django

#19878: Stop TemplateView automatically passing kwargs into the context
---+
 Reporter:  void   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Generic views  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  django-sprint  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by cjerdonek):

 * cc: chris.jerdonek@… (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.9e80f8a62b555d47d85f42daff7fbb31%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19878: Stop TemplateView automatically passing kwargs into the context

2014-02-06 Thread Django

#19878: Stop TemplateView automatically passing kwargs into the context
---+
 Reporter:  void   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Generic views  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  django-sprint  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by cjerdonek):

 Note that there is a distinction between //passing// `**kwargs` to
 `get_context_data()` and having `get_context_data()` //return//
 `**kwargs`.

 Personally, I would favor `TemplateView` continuing to pass `**kwargs` to
 `get_context_data()` even if its return value is changed by default not to
 include `kwargs`.  This would keep overriding `get_context_data()` simple
 because you can simply access `**kwargs` in the method without having to
 decide between `**kwargs` and `self.kwargs`.

 For consistency, I would like it if all generic views passed the full
 view's keyword arguments to `get_context_data()`.  Some classes like
 `ProcessFormView` restrict what is passed to `get_context_data()`, which
 was surprising to me because then `**kwargs` for the method differs from
 `self.kwargs`.  I just opened #21964 which is about this issue.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.4d2c2846eb1b81de2914684ef1f4d1c1%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21964: ProcessFormView should pass **kwargs to get_context_data()

2014-02-06 Thread Django

#21964: ProcessFormView should pass **kwargs to get_context_data()
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Generic views|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by cjerdonek):

 Sorry, scratch my last comment.  I misread your comment that "pushing
 `kwargs` to the context has been called an anti-pattern" as saying
 "pushing `kwargs` to `get_context_data()` has been called an anti-
 pattern."  `self.kwargs` need not be documented if the view's keyword
 arguments are passed to `get_context_data()` as I suggested in this issue.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0bce8af493488a178f5c8fe6a11d8a60%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21965: weight loss activities

2014-02-06 Thread Django

#21965: weight loss activities
---+-
 Reporter:  anonymous  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Testing framework  |Version:  1.6
 Severity:  Normal |   Keywords:  Zen Cleanse
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 birthday because when you see the way limits you don’t ever heard and on
 anything shares nothing to break up yeah and I’m like for OK'd scorcher
 going to snap day but yet here I am internet my mind you backyard on my
 yeah I don't even know about watt you're [http://zencleansehealth.com/ ZEN
 CLEANSE] not going straight towards the ground and never quite camp coming
 back up and keep looking at it was just a mesh amazing feeling view before
 uniform six months ago there’s no way just for the day and an option for
 me because today job their weight limits certain things and I exceeded
 those weight limit yeah freaking amazing I from five by really Yelp output
 trust MTV's bungee cords and affect ration myself and as the main thing
 that I've got to worry next three months mistrust self a free has
 officially begun reading your 239 right now by the end of these three any
 just be as close to fifty percent of your starting weight as you can
 meeting you need to these between 50 and60 pounds and might be a candidate
 for the skin removal surgery cell it's going to be your face legal oh my
 goodness very hitting it does remove its good at hairdresser crisis now a
 point then Mom Central Mom burns for all and on love running I want to
 question some honest like ensemble of sometimes like our union and just
 here revision be simmered because he gets the way and can get harder and
 harder and harder working out not a problem because think imp between four
 and five hours every single day 18 have even know everything is just and
 kind of control on a nine month by I think it's a good idea for make
 people to exactly how far they’ve come over the last nine months in just
 to give them that glimpse how much they transform arriving here as usual
 as there was no sway as a
 http://zencleansehealth.com/

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.5c9563807b6bb021a53b9e85b5b2a97a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21964: ProcessFormView should pass **kwargs to get_context_data()

2014-02-06 Thread Django

Comment (by cjerdonek):

Thanks for the pointer to the current thinking. In that case, it seems
like `self.kwargs` should be documented somewhere as the recommended way
to access the keyword arguments passed to a view (as opposed to `**kwargs`
to whatever method is being overridden). Currently, `self.kwargs` is set
by `as_view()`

[https://github.com/django/django/blob/d3cf6cfacfb828faad4f4f97c904e259304649b3/django/views/generic/base.py#L68
here]. One place `self.kwargs` could be documented is in the attributes
subsection of the [https://docs.djangoproject.com/en/dev/ref/class-based-
views/base/#view django.views.generic.base.View documentation]. It
doesn't currently seem to be documented anywhere that I've come across.
Maybe the documentation for [https://docs.djangoproject.com/en/dev/ref
/class-based-views/base/#django.views.generic.base.View.as_view as_view()]
could also include a note about setting `self.kwargs`.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.4a76756473c11199a3951f9385e8e57f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21952: Deadlock while dispatching signals

2014-02-06 Thread Django

#21952: Deadlock while dispatching signals
-+
 Reporter:  edevil   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.6
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  signal deadlock  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by edevil):

 Will this be backported to 1.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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.c420487a964aaf541ab9d1f3cda83bb6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21964: ProcessFormView should pass **kwargs to get_context_data()

2014-02-06 Thread Django

#21964: ProcessFormView should pass **kwargs to get_context_data()
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Generic views|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

 * component:  Uncategorized => Generic views


Comment:

 FWIW, pushing `kwargs` to the context has been called an anti-pattern in
 #19878 and we're planning to deprecate that behavior in `TemplateView`. I
 guess this change may still have merit, but I haven't looked into the
 details.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.cab3b5f506e1a2090db3d3db85570324%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21964: ProcessFormView should pass **kwargs to get_context_data()

2014-02-06 Thread Django

#21964: ProcessFormView should pass **kwargs to get_context_data()
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Uncategorized|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by cjerdonek):

 * cc: chris.jerdonek@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.312b08800ebcf1936bbad4f9948b30c6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21964: ProcessFormView should pass **kwargs to get_context_data()

2014-02-06 Thread Django

#21964: ProcessFormView should pass **kwargs to get_context_data()
--+
 Reporter:  cjerdonek |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  1.6
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 In the `ProcessFormView` class, keyword arguments to the view aren't
 available in the template context by default.

 From what I can tell, changing this behavior (so that one can customize
 other aspects of the template) requires relying on undocumented
 implementation details of Django views (namely that `View.as_view()` sets
 `self.kwargs`).  For example:

 {{{
 def get_context_data(self, **kwargs):
 # ProcessFormView doesn't pass the view's keyword arguments in its
 # calls to get_context_data(), so we need to add them back manually.
 context = self.kwargs.copy()
 context.update(kwargs)
 return context
 }}}

 I think things would be simpler and more consistent if `ProcessFormView`
 passed the view's `**kwargs` to `get_context_data()` in the first place,
 in which case `ProcessFormView` could implement its own version of
 `get_context_data()` that would restrict the context.  This would be more
 DRY by eliminating the need to read `self.kwargs` when overriding
 `get_context_data()`.  This will also reduce potential confusion between
 the `**kwargs` argument and the undocumented `self.kwargs` attribute.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.adb8226ee577889418968e96320024c2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17653: using id = 0 on get_or_create

2014-02-06 Thread Django

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |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 timo):

 * has_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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/090.346eb88b9de1c2f467ababeefc3d0f84%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17713: allows_primary_key_0 is misnamed

2014-02-06 Thread Django

#17713: allows_primary_key_0 is misnamed
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"d3cf6cfacfb828faad4f4f97c904e259304649b3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d3cf6cfacfb828faad4f4f97c904e259304649b3"
 Fixed #17713 -- Renamed BaseDatabaseFeatures.allows_primary_key_0 to
 allows_auto_pk_0.

 MySQL does allow primary key with value 0. It only forbids autoincrement
 primary key with value 0.

 Thanks Claude Paroz 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.3cd74218cafe8361c14053f5ff1edc81%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] d3cf6c: Fixed #17713 -- Renamed BaseDatabaseFeatures.allow...

2014-02-06 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d3cf6cfacfb828faad4f4f97c904e259304649b3
  
https://github.com/django/django/commit/d3cf6cfacfb828faad4f4f97c904e259304649b3
  Author: Vajrasky Kok 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
M django/db/backends/__init__.py
M django/db/backends/mysql/base.py
M docs/releases/1.7.txt
M tests/backends/tests.py
M tests/bulk_create/tests.py
M tests/inline_formsets/tests.py
M tests/serializers_regress/tests.py

  Log Message:
  ---
  Fixed #17713 -- Renamed BaseDatabaseFeatures.allows_primary_key_0 to 
allows_auto_pk_0.

MySQL does allow primary key with value 0. It only forbids autoincrement
primary key with value 0.

Thanks Claude Paroz for the report.


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52f3611c20637_7699f3fd407248d%40hookshot-fe7-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20566: Store previous string in po files

2014-02-06 Thread Django

#20566: Store previous string in po files
--+
 Reporter:  nijel |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timo):

 * needs_better_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.7d3ae694008d76367ca03e950becc2c3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19705: CommonMiddleware handles If-None-Match incorrectly

2014-02-06 Thread Django

#19705: CommonMiddleware handles If-None-Match incorrectly
---+
 Reporter:  aaugustin  |Owner:  hirokiky
 Type:  Bug|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timo):

 * needs_better_patch:  0 => 1


Comment:

 Setting as "patch needs improvement" given the previous comment and the
 fact that the PR no longer merges cleanly.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6d0b80d7113ab3eb836afc5019fb0df9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17005: Add CurrentSiteMiddleware to set the current site on the request (was: Adding django.contrib.site.middleware ?)

2014-02-06 Thread Django

#17005: Add CurrentSiteMiddleware to set the current site on the request
-+-
 Reporter:  jordan@… |Owner:
 Type:  New feature  |  chrismedrela
Component:  contrib.sites|   Status:  closed
 Severity:  Normal   |  Version:
 Keywords:   |   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
-+-

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.3ba74a3a023908205d778c1dc0a4cb53%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] b22d6c: Fixed #17005 -- Added CurrentSiteMiddleware to set...

2014-02-06 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: b22d6c47a7e4c7ab26a8b7b033d11fa6743aae86
  
https://github.com/django/django/commit/b22d6c47a7e4c7ab26a8b7b033d11fa6743aae86
  Author: Christopher Medrela 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
A django/contrib/sites/middleware.py
M django/contrib/sites/tests.py
M docs/ref/contrib/sites.txt
M docs/ref/middleware.txt
M docs/releases/1.7.txt

  Log Message:
  ---
  Fixed #17005 -- Added CurrentSiteMiddleware to set the current site on each 
request.

Thanks jordan at aace.org for the suggestion.


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52f359ecb7d0_547cd35d38462e%40hookshot-fe10-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17005: Adding django.contrib.site.middleware ?

2014-02-06 Thread Django

#17005: Adding django.contrib.site.middleware ?
-+-
 Reporter:  jordan@… |Owner:
 Type:  New feature  |  chrismedrela
Component:  contrib.sites|   Status:  closed
 Severity:  Normal   |  Version:
 Keywords:   |   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
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"b22d6c47a7e4c7ab26a8b7b033d11fa6743aae86"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b22d6c47a7e4c7ab26a8b7b033d11fa6743aae86"
 Fixed #17005 -- Added CurrentSiteMiddleware to set the current site on
 each request.

 Thanks jordan at aace.org for the suggestion.
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.767ceebe09069871ba6eb5515f7cf3af%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19552: makemessages ignores translations in templates with inline comment tags

2014-02-06 Thread Django

#19552: makemessages ignores translations in templates with inline comment tags
-+-
 Reporter:  juneih@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.4
  Internationalization   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  makemessages,|  Needs documentation:  0
  template, gettext, xgettext|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by Ihor Kaharlichenko ):

 Extracted as a separate issue: #21963.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/083.e967897f719e3d39f4100e2dfe003474%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21963: makemessages still ignores translations in templates with inline comment tags

2014-02-06 Thread Django

#21963: makemessages still ignores translations in templates with inline comment
tags
-+-
 Reporter:  Ihor Kaharlichenko   |  Owner:  nobody
| Status:  new
 Type:  Bug  |Version:  1.6
Component:   |   Keywords:  makemessages, template,
  Internationalization   |  gettext, xgettext
 Severity:  Normal   |  Has patch:  0
 Triage Stage:  Unreviewed   |  UI/UX:  0
Easy pickings:  0|
-+-
 This bug is claimed to be fixed in #19552, though it's not.

 Here's the test case:

 Template:

 {{{#!django
 {% load i18n %}

 {# Translators: Abbreviated month name #}
 {% trans "Jan" %}

 {# Translators: Abbreviated month name #}{% trans "Feb" %}

 {% comment %}Translators: Abbreviated month name{% endcomment %}{% trans
 "Mar" %}

 {# Translators: Abbreviated month name #} {% trans "Apr" %}

 {% comment %}Translators: Abbreviated month name{% endcomment %} {% trans
 "May" %}

 {# Translators: Abbreviated month name #}
 {% trans "Jun" %}

 {# Translators: Abbreviated month name #}

 {% trans "Jul" %}

 {% comment %}Translators: Abbreviated month name{% endcomment %}

 {% trans "Aug" %}
 }}}

 The extraction session:

 {{{
 $ ./manage.py version
 1.6.1
 $ ./manage.py makemessages -l ru -i venv
 .../trans_real.py:585: TranslatorCommentWarning: The translator-targeted
 comment 'Translators: Abbreviated month name' (file
 app1/templates/i18n_test.html, line 6) was ignored, because it wasn't the
 last item on the line.
   warnings.warn(warn_msg, TranslatorCommentWarning)

 .../trans_real.py:585: TranslatorCommentWarning: The translator-targeted
 comment 'Translators: Abbreviated month name' (file
 app1/templates/i18n_test.html, line 10) was ignored, because it wasn't the
 last item on the line.
   warnings.warn(warn_msg, TranslatorCommentWarning)

 processing locale ru
 }}}

 Resulting po file:

 {{{#!po
 #. Translators: Abbreviated month name
 #: app1/templates/i18n_test.html:4
 msgid "Jan"
 msgstr ""

 #: app1/templates/i18n_test.html:6
 msgid "Feb"
 msgstr ""

 #. Translators: Abbreviated month name gettext(u'Mar')
 #: app1/templates/i18n_test.html:10
 msgid "Apr"
 msgstr ""

 #. Translators: Abbreviated month name  gettext(u'May')
 #. Translators: Abbreviated month name
 #: app1/templates/i18n_test.html:15
 msgid "Jun"
 msgstr ""

 #. Translators: Abbreviated month name
 #: app1/templates/i18n_test.html:19
 msgid "Jul"
 msgstr ""

 #. Translators: Abbreviated month name
 #: app1/templates/i18n_test.html:23
 msgid "Aug"
 msgstr ""
 }}}

 The problems:
 * translations for "Mar" and "May" were completely skipped
 * there was a warning for single-tag comments (for Feb and Apr), but not
 for block comments (for Mar and May), which is inconsistent
 * Apr and Jun got wrong comments

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/083.ca4266947092af7e15f7e58a9f760c98%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21962: Add a flag to ErrorDict.as_json() to escape html

2014-02-06 Thread Django

Some use cases for `ErrorDict.as_json()` are:

* AJAX requests to a form view where the client interprets the response
and puts errors into the page (so HTML escaping would be useful)
* Building an API which handles JSON. In this case HTML escaping is plain
wrong.

In the first case, it is trivial using jQuery to ensure the text is
escaped - simply use `$(el).text(errorText)` rather than `.html()` and
jQuery will escape the HTML for you. We should document that the
`as_json()` method does not not escape the result and can even reference
the relevant jQuery method as an example for how to do this client-side.

from Shai Berger:

We should also probably add a flag for HTML escaping -- it is useful for a
very common use-case of the method, and we shouldn't assume jQuery or any
client-side library. While this is less than totally clean (and that, in
itself, is reason enough not to escape HTML by default), practicality
beats purity -- and adding such a flag will result in more secure Django-
based sites.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/047.5db4909383e2b138c7759ba4ca7ee03a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21731: django.utils.text.javascript_quote does not escape "

2014-02-06 Thread Django

#21731: django.utils.text.javascript_quote does not escape "):

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


Comment:

 In [changeset:"c43c469a2e4633361f5dccf7dc7ce37054008d18"]:
 {{{
 #!CommitTicketReference repository=""
 revision="c43c469a2e4633361f5dccf7dc7ce37054008d18"
 Fixed #21731 -- Made javascript_quote escapes 'https://code.djangoproject.com/ticket/21731#comment:3>
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.05e0657e3fc8b24c62a6d6612d152446%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] c43c46: Fixed #21731 -- Made javascript_quote escapes '

2014-02-06 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: c43c469a2e4633361f5dccf7dc7ce37054008d18
  
https://github.com/django/django/commit/c43c469a2e4633361f5dccf7dc7ce37054008d18
  Author: Vajrasky Kok 
  Date:   2014-02-06 (Thu, 06 Feb 2014)

  Changed paths:
M django/utils/text.py
M tests/utils_tests/test_text.py

  Log Message:
  ---
  Fixed #21731 -- Made javascript_quote escapes 'https://groups.google.com/d/msgid/django-updates/52f34fa684e85_7797829d4453834%40hookshot-fe9-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21961: ForeignKey.on_delete supports database-level cascading options

2014-02-06 Thread Django

#21961: ForeignKey.on_delete supports database-level cascading options
-+-
 Reporter:  Xof  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-1
 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):

 I think the description has parent and child deletion mixed. Deleting the
 parent will delete the child (there is a key from child to parent). The
 problem is child deletion. In Django deleting the child cascades to the
 parent row, too. But there is no column from parent to child you can
 cascade along if you do cascades in the DB. The real problematic case:

 {{{
 class Related(models.Model):
 pass

 class Parent(models.Model):
 pass

 class Child(Parent):
 related = models.ForeignKey(Related, on_delete=DB_CASCADE)
 }}}

 When you delete Related instance, Child instances pointing to it will be
 deleted by db cascade, but the parent instances will be left alone. If you
 instead use standard CASCADE, then the parent instances will be deleted,
 too. This is surprising behaviour. It can be documented, but erroring out
 would be IMO better.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.e49c14f98af9bafd4d59fe822867db86%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21961: ForeignKey.on_delete supports database-level cascading options

2014-02-06 Thread Django

#21961: ForeignKey.on_delete supports database-level cascading options
-+-
 Reporter:  Xof  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-1
 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 charettes):

 5. It is possible to specify the key:

 {{{#!python
 class Parent(models.Model):
 pass

 class Child(Parent):
 parent = models.OneToOneField(Parent, parent_link=True)
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.19d02170afcfd59ccc975f60a4490a99%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21961: ForeignKey.on_delete supports database-level cascading options

2014-02-06 Thread Django

Comment (by aaugustin):

1. is tricky. My instinct would be to fail with an exception when the code
requires something that cannot be achieved. However, I understand that
pluggable apps may want to take advantage of database-level cascades,
while still supporting less capable databases. Short of introducing a
third value (CASCADE_DB_PROVIDED_YOU_ARE_USING_A_REAL_DATABASE), your
proposal is probably the best solution.

A similar argument can be made for 3.

5 might be just another argument against MTI...

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/061.c7a6c0fe06a043e26e20d8707d01ab4d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21961: ForeignKey.on_delete supports database-level cascading options

2014-02-06 Thread Django

#21961: ForeignKey.on_delete supports database-level cascading options
-+-
 Reporter:  Xof  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-alpha-1
 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 mjtamlyn):

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


Comment:

 If 3 can be introspected for (which should be possible) we can at least
 implement a check for it in the new checks framework.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.546e473c1175a8639c28825cf1e02ba3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

51 matches

Mail list logo