Re: [Django] #18310: Make named return URLs configurable

[Django]

#18310: Make named return URLs configurable
---+
 Reporter:  russellm   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  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:  1  |UI/UX:  0
---+

Comment (by ramiro):

 See also #8001.

-- 
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] #18310: Make named return URLs configurable

[Django]

#18310: Make named return URLs configurable
-+
   Reporter:  russellm   |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |Version:  1.3
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 As of 1.4, The admin views have been modified to use named URLs instead of
 ../../.. paths for the redirects on success for add and change views (the
 return values of ModelAdmin.response_add() and
 ModelAdmin.response_change()).

 However, the use of these named URLs requires that the named URL exists,
 which won't necessarily be the case.

 As an example, [https://github.com/jphalip/django-treemenus django-
 treemenus] adds some customisations to make it easy to define a tree
 hierarchy of MenuItem objects. To do this, it registers Menu with admin; A
 dummy ModelAdmin for MenuItem is used to provide the views for the entries
 on the menu.

 MenuItem.response_add() tries to return to the named URL
 'treemenus_menuitem_changelist' -- however this named URL doesn't exist,
 because MenuItem isn't registered with the admin.

 There's no easy way to customize the named URL that you want the change
 view to return to. This would be an easy thing to configure with an
 argument (or arguments) to response_change and response_add.

-- 
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] #18308: Tutorial needs "disable django.contrib.sites' instruction

[Django]

#18308: Tutorial needs "disable django.contrib.sites' instruction
---+--
 Reporter:  esnolte@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anonymous):

 Interesting.  I experience this on Django (1, 4, 0, 'final', 0) as
 installed by MacPorts' py27-django package with MacPorts' Python 2.7.3 and
 a sqlite3 database.  What environment was the tutorial tested in?  A Linux
 or Windows environment?  I can try and replicate the problem to help
 narrow down the cause.

-- 
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] #18306: Deferred models should automatically issue update_fields when saving

[Django]

#18306: Deferred models should automatically issue update_fields when saving
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by anonymous):

 I understand! I will try to implement and integrate, and if integrated
 well, great for everyone! And if not, then leave it as is.

 I have not written any kind of documentation, because I'm still doing
 tests and I'm playing a bit. When ready, do a pull-request and review 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] #18309: Prefetch related does not work for fkey to multitable inherited model

[Django]

#18309: Prefetch related does not work for fkey to multitable inherited model
-+-
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by milosu):

 * has_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 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] #18309: Prefetch related does not work for fkey to multitable inherited model

[Django]

#18309: Prefetch related does not work for fkey to multitable inherited model
-+-
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   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 milosu):

 * needs_better_patch:   => 0
 * version:  1.4 => master
 * 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 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] #18309: Prefetch related does not work for fkey to multitable inherited model

[Django]

#18309: Prefetch related does not work for fkey to multitable inherited model
--+
 Reporter:  milosu|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Using Django 1.4 with some latest prefetch related patches from trunk, the
 prefetch_related does not work for fkeys to models that are inherited from
 some other model.

 Without the applied patch, the attached test case fails with:

 {{{

 ==
 ERROR: test_foreignkey
 (modeltests.prefetch_related.tests.MultiTableInheritanceT
 est)
 --
 Traceback (most recent call last):
   File "C:\Python26\Lib\site-
 packages\django_versions\trunk\tests\modeltests\pre
 fetch_related\tests.py", line 344, in test_foreignkey
 reviews = [obj.book.title for obj in qs]
   File "C:\Python26\lib\site-
 packages\django_versions\trunk\django\db\models\fie
 lds\related.py", line 379, in __get__
 raise self.field.rel.to.DoesNotExist
 DoesNotExist

 }}}

-- 
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] #18308: Tutorial needs "disable django.contrib.sites' instruction

[Django]

#18308: Tutorial needs "disable django.contrib.sites' instruction
---+--
 Reporter:  esnolte@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by kmtracey):

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


Comment:

 It's not necessary to disable sites to get the tutorial to work properly,
 there is something else going on with the sequence of events here that is
 causing the problem. I don't know exactly what sequence of events would
 lead to the default site being missing, but I did just run through the
 tutorial following the instructions, with 1.4, and did not see this
 problem.

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

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

[django/django] bbb125: Replaced im_func and im_self by __func__ and __sel...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: bbb12581dbd91945857cb4731368671776d4d388
  
https://github.com/django/django/commit/bbb12581dbd91945857cb4731368671776d4d388
  Author: Claude Paroz 
  Date:   2012-05-12 (Sat, 12 May 2012)

  Changed paths:
M django/dispatch/dispatcher.py
M django/dispatch/saferef.py
M tests/regressiontests/decorators/tests.py

  Log Message:
  ---
  Replaced im_func and im_self by __func__ and __self__.

The new names are Python 3 compatible.



-- 
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] #14026: Setting for TRANSACTION_LEVEL on db backends

[Django]

#14026: Setting for TRANSACTION_LEVEL on db backends
-+-
 Reporter:  adamnelson   |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   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 gcbirzan):

 Replying to [comment:6 akaariai]:
 > FWIW I would find a feature allowing transaction isolation level
 settings per transaction/per session to be useful. Now, the setting would
 have to be database specific (there is absolutely no hope to guarantee
 similar behaving isolation levels cross-backend) and should come with a
 big warning that using any other isolation level than the default voids
 your warranty.

 You can, even now, do that, for PostgreSQL. I was planning on implementing
 this by making sure all backends support the setting the serialisation
 level and using that. One could then also use a generic function for
 setting isolation, at whatever point.

 > My main use-case would be SERIALIZABLE transactions in PostgreSQL 9.1+.
 The "true serializable" behavior is really nice if your application can
 use it.

 Yeah, that's what I want it for too. :-)

-- 
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] #18194: File-based session never expire

[Django]

#18194: File-based session never expire
--+
 Reporter:  ej|Owner:  crodjer
 Type:  Bug   |   Status:  assigned
Component:  contrib.sessions  |  Version:  1.4
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by crodjer):

 * owner:  nobody => crodjer
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 I made some attempts with this in `file-session-server-
 expiry-{2,3}.patch`. The 2nd uses files modification time to decide on
 expiry. The 3rd uses the signing framework's timed signer for handling the
 expiration. Also added a test which is supposed to emulate the ticket
 behaviour.

 Moreover, `sessions-cleanup-files-1.patch` adds support for cleaning of
 file sessions with management cleanup command. It moves the session
 backend specific cleanup logic to their own modules and the management
 command invokes cleanup command according to the current backend. The base
 backend implements a cleanup class method which is supposed to be
 overridden by the backends.

-- 
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] #18308: Tutorial needs "disable django.contrib.sites' instruction

[Django]

#18308: Tutorial needs "disable django.contrib.sites' instruction
---+
 Reporter:  esnolte@…  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If you're running Django 1.4 and follow the online tutorial (presumably a
 tutorial for 1.4), you'll encounter the following error when you try to
 access the admin site (http://127.0.0.1:8000/admin/) in part 2:

   DoesNotExist at /admin/
   Site matching query does not exist.

 The fix is to comment out the "django.contrib.sites" line in
 INSTALLED_APPS in settings.py.

 So part 2 should read:

 * Uncomment "django.contrib.admin" in the INSTALLED_APPS setting.
 * Comment "django.contrib.sites" in the INSTALLED_APPS setting.
 * Run python manage.py syncdb. Since you ...

-- 
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] #14026: Setting for TRANSACTION_LEVEL on db backends

[Django]

#14026: Setting for TRANSACTION_LEVEL on db backends
-+-
 Reporter:  adamnelson   |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   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 akaariai):

 FWIW I would find a feature allowing transaction isolation level settings
 per transaction/per session to be useful. Now, the setting would have to
 be database specific (there is absolutely no hope to guarantee similar
 behaving isolation levels cross-backend) and should come with a big
 warning that using any other isolation level than the default voids your
 warranty.

 My main use-case would be SERIALIZABLE transactions in PostgreSQL 9.1+.
 The "true serializable" behavior is really nice if your application can
 use it.

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

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

[django/django] 33ffd2: Added missing relative imports in test files.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 33ffd28d76d775c970691a3da282e98b349735c4
  
https://github.com/django/django/commit/33ffd28d76d775c970691a3da282e98b349735c4
  Author: Claude Paroz 
  Date:   2012-05-12 (Sat, 12 May 2012)

  Changed paths:
M django/contrib/admindocs/tests/__init__.py
M tests/modeltests/tablespaces/tests.py
M tests/regressiontests/admin_inlines/admin.py

  Log Message:
  ---
  Added missing relative imports in test files.



-- 
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] #18304: MySQL generates an unecessary select when updating inherited models

[Django]

#18304: MySQL generates an unecessary select when updating inherited models
-+-
 Reporter:  akaariai |Owner:  anonymous
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  mysql|  checkin
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+-
Changes (by anonymous):

 * owner:  nobody => anonymous


-- 
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] #18304: MySQL generates an unecessary select when updating inherited models

[Django]

#18304: MySQL generates an unecessary select when updating inherited models
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  mysql|  checkin
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+-
Changes (by anonymous):

 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * easy:  0 => 1
 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * ui_ux:  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 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] #11803: Admin does not update every ForeignKey select of the same model

[Django]

#11803: Admin does not update every ForeignKey select of the same model
-+-
 Reporter:  danilo   |Owner:  nobody
   |   Status:  new
 Type:  Bug  |  Version:  1.1
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  admin select |  Needs documentation:  0
  foreignkey |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by roland):

 second vote

-- 
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] #14026: Setting for TRANSACTION_LEVEL on db backends

[Django]

#14026: Setting for TRANSACTION_LEVEL on db backends
-+-
 Reporter:  adamnelson   |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   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 gcbirzan):

 * status:  closed => reopened
 * cc: gcbirzan@… (added)
 * resolution:  invalid =>
 * version:  1.2 => master
 * ui_ux:   => 0
 * type:  Uncategorized => New feature


Comment:

 This only works for MySQL. There should be a DB agnostic way of doing
 this. That should be split into two parts, a the config setting and the
 actual setting/fetching of isolation level.

-- 
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] #18306: Deferred models should automatically issue update_fields when saving

[Django]

#18306: Deferred models should automatically issue update_fields when saving
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * needs_docs:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 The implementation looks suspiciously clean... :) However there is going
 to be some problems to get the updating of manually set fields to work
 correctly. (the a.age = 31 case in original description). Apart of this
 problem the patch needs some documentation (only()/defer() docs need a
 mention of this, maybe also in .save()).

 If it turns out to be at all problematic to support the
 model._state.update_fields attribute lets just leave that out from this
 ticket. I'd like to try that idea out, but there is no need to complicate
 this ticket with that idea.

-- 
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] #18306: Deferred models should automatically issue update_fields when saving

[Django]

#18306: Deferred models should automatically issue update_fields when saving
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by anonymous):

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


Comment:

 The current work is done on this branch:
 https://github.com/niwibe/django/commits/defer_only_interaction

 So far I have not sent the request to pull.

-- 
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] #18307: Git workflow guidelines

[Django]

#18307: Git workflow guidelines
---+--
 Reporter:  akaariai   |  Owner:  akaariai
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 We are currently missing guidelines for how to work using Git, Github and
 Trac. In addition, most references to SVN should be removed from our
 documentation.

 I will start writing guidelines for Git workflow. The work will be tracked
 in [https://github.com/akaariai/django/tree/django_git_guidelines
 django_git_guidelines] github branch.

 I welcome everybody to give feedback.

-- 
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] #18019: ./manage.py testserver with in-memory sqlite database fails on 1.4

[Django]

#18019: ./manage.py testserver with in-memory sqlite database fails on 1.4
-+-
 Reporter:  hcarvalhoalves   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  regression   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Accepted => Ready for checkin


Comment:

 The patch looks good to me, and I can verify it fixes the testserver
 issue.

 It is a bit unfortunate that we don't have a way to test these issues.

-- 
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] #17631: edge case: django.test.client should handle fields and files with the same name

[Django]

#17631: edge case: django.test.client should handle fields and files with the 
same
name
---+
 Reporter:  dnozay |Owner:
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  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 obeattie):

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

[Django] #18306: Deferred models should automatically issue update_fields when saving

[Django]

#18306: Deferred models should automatically issue update_fields when saving
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When saving a model fetched through deferred model loading (.only() or
 .defer()) and then saving these models it would be useful to issue an
 update_fields automatically.

 Currently, all the model's deferred fields are fetched from the DB and
 then saved back - this doesn't make sense. Instead, doing
 {{{
 (assume Author with fields age + name)
 a = Author.objects.only('name').get(pk=1)
 a.name = 'Anssi'
 a.save()
 }}}
 should be equivalent to doing:
 {{{
 a = Author.objects.only('name').get(pk=1)
 a.name = 'Anssi'
 a.save(update_fields=['name'])
 }}}

 In addition, the following must work:
 {{{
 a = Author.objects.only('name').get(pk=1)
 a.name = 'Anssi'
 a.age = 31
 a.save()
 }}}
 both age and name must be saved in this case.

 Also, if save is given update_fields argument, it must override the
 deferred model argument.

 I would like to investigate the possibility of storing the fields to
 update in model._state.update_fields - the reason is that this would be a
 nice hook for 3rd party model subclasses which could use that variable to
 implement automatic tracking of changed fields. There is a lot of
 discussion of this feature in #4102, and the decision there seems clear:
 we can't include automatic change tracking in Django core. However,
 allowing easy creation of state-tracking subclasses would be a nice
 addition.

-- 
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] #18305: force_update/force_insert not passed up the inheritance chain in .save()

[Django]

#18305: force_update/force_insert not passed up the inheritance chain in .save()
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

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


Comment:

 Patches for force_update and force_insert fixes available at:
 https://github.com/akaariai/django/tree/ticket_18305 (just force_update)
 and https://github.com/akaariai/django/tree/ticket_18305_both (contains
 also force_insert).

 I am marking this DDN, as I am not sure if fixing the force_insert can be
 considered backwards compatible. If there were a way to save only the
 child model (the restaurant), then this would be easier to accept, as we
 could add "do this instead:" to the release notes.

-- 
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] #18304: MySQL generates an unecessary select when updating inherited models

[Django]

#18304: MySQL generates an unecessary select when updating inherited models
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  mysql|  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Ready for checkin


Comment:

 https://github.com/django/django/pull/61 contains an RFC 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.

[Django] #18305: force_update/force_insert not passed up the inheritance chain in .save()

[Django]

#18305: force_update/force_insert not passed up the inheritance chain in .save()
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When saving a model, the force_update and force_insert are not passed up
 to parent model saves in model.save(). For example:
 {{{
 class Place(models.Model):
 name = TextField()

 class Restaurant(Place):
 serves_pizza = models.BooleanField()

 r = Restaurant.objects.create(name='Pizzeria pizza-kebab',
 serves_pizza=True)
 r.serves_pizza = False
 r.save(force_update=True)
 }}}
 Now, the r is updated correctly. Then, when saving the Place, the
 force_update isn't passed to the save_base, and thus the Place is first
 queried - so, the force_update isn't honored.

 The same is true for force_insert. However, in this case it is possible
 that the force_insert is meant only for the Restaurant. You can currently
 do this:
 {{{
 p = Place.objects.create(name='p')
 r = Restaurant(place=p, serves_pizza=False)
 r.save(force_insert=True)
 }}}
 This would however be impossible if the force_insert would be passed up
 the inheritance chain.

 Fixing the force_update case seems clear - however the force_insert case
 needs at least some consideration for backwards compatibility reasons.

-- 
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/django] de79d2: Avoided test failure on MySQL by skipping a failin...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: de79d23ce04193e0bc140991533359002f62ddf9
  
https://github.com/django/django/commit/de79d23ce04193e0bc140991533359002f62ddf9
  Author: Anssi Kääriäinen 
  Date:   2012-05-12 (Sat, 12 May 2012)

  Changed paths:
M tests/modeltests/update_only_fields/tests.py

  Log Message:
  ---
  Avoided test failure on MySQL by skipping a failing test

MySQL generates an extra query in inheritance cases when doing an update.
This results in a test failure when checking for number of queries in
update_only_fields tests. Added a skip temporarily to avoid this test
failure. Refs #18304.



-- 
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] #18304: MySQL generates an unecessary select when updating inherited models

[Django]

#18304: MySQL generates an unecessary select when updating inherited models
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal| Resolution:
 Keywords:  mysql |   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+

Comment (by Anssi Kääriäinen):

 Avoided test failure on MySQL by skipping a failing test

 MySQL generates an extra query in inheritance cases when doing an update.
 This results in a test failure when checking for number of queries in
 update_only_fields tests. Added a skip temporarily to avoid this test
 failure. Refs #18304.
  Changeset: de79d23ce04193e0bc140991533359002f62ddf9

-- 
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] #18304: MySQL generates an unecessary select when updating inherited models

[Django]

#18304: MySQL generates an unecessary select when updating inherited models
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:  mysql
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The reason is in !SQLUpdateCompiler.pre_sql_setup(): it checks if there
 are multiple tables in the query, and if the backend can't do a self
 select on update ("update_can_self_select" db feature) the pre_sql_setup
 will run a query to fetch the pks to update. However, in inheritance cases
 this leads to queries like:
 {{{
 SELECT U0.`person_ptr_id` FROM `update_only_fields_employee` U0 WHERE
 U0.`person_ptr_id` = 2
 }}}
 which is non-necessary to run.

 The problem was spotted when running update_only_fields tests on MySQL -
 the test will be skipped on MySQL, but the test_num_queries_inheritance
 test shows the problem if the skip is removed.

-- 
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] #4102: Allow UPDATE of only specific fields in model.save()

[Django]

#4102: Allow UPDATE of only specific fields in model.save()
-+-
 Reporter:  Collin Grady |Owner:  cgrady
   |   Status:  closed
 Type:  New feature  |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:  update fields sql|  Needs documentation:  0
  row table modified |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Andrei Antoukh):

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


Comment:

 Fixed #4102 -- Allow update of specific fields in model.save()

 Added the ability to update only part of the model's fields in
 model.save() by introducing a new kwarg "update_fields". Thanks
 to all the numerous reviewers and commenters in the ticket
  Changeset: 365853da016f242937a657b488514e2f69fa6d82

-- 
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/django] 365853: Fixed #4102 -- Allow update of specific fields in ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 365853da016f242937a657b488514e2f69fa6d82
  
https://github.com/django/django/commit/365853da016f242937a657b488514e2f69fa6d82
  Author: Andrei Antoukh 
  Date:   2012-05-12 (Sat, 12 May 2012)

  Changed paths:
M django/db/models/base.py
M django/db/models/signals.py
M docs/ref/models/instances.txt
M docs/ref/signals.txt
M docs/releases/1.5.txt
A tests/modeltests/update_only_fields/__init__.py
A tests/modeltests/update_only_fields/models.py
A tests/modeltests/update_only_fields/tests.py

  Log Message:
  ---
  Fixed #4102 -- Allow update of specific fields in model.save()

Added the ability to update only part of the model's fields in
model.save() by introducing a new kwarg "update_fields". Thanks
to all the numerous reviewers and commenters in the ticket



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