date:20120527

Re: [Django] #18135: Sleeping Database Connections on Startup with MySQL

2012-05-27 Thread Django

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  MySQL| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by akaariai):

 I missed the security-only status of 1.3.x. I will revert the patch later
 on today from 1.3.

-- 
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] #18388: Add more hooks in the ModelAdmin (get_extra, get_max_num)

2012-05-27 Thread Django

#18388: Add more hooks in the ModelAdmin (get_extra, get_max_num)
---+
 Reporter:  d.willy.c.c@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 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 anonymous):

 I think 'GET' is the easiest way to personalize this, and also believe
 that all variables should have a 'GET'

-- 
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] #17208: Dogfood class-based views in contrib.admin

2012-05-27 Thread Django

#17208: Dogfood class-based views in contrib.admin
-+-
 Reporter:  melinath |Owner:  julien
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  class-based views|  Needs documentation:  1
  admin  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by rasca):

 * cc: rasca (added)


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

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

Re: [Django] #17208: Dogfood class-based views in contrib.admin

2012-05-27 Thread Django

#17208: Dogfood class-based views in contrib.admin
-+-
 Reporter:  melinath |Owner:  julien
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  class-based views|  Needs documentation:  1
  admin  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by rasca):

 I disagree that the code is more complex now. At least for me, being used
 to the generic CBV I think the code is much clearer and easy to understand
 than before, being split in familiar methods.

 Said that, I think there's much room for improvement. For example joining
 all the formsets construction and prefix checking:
 https://github.com/rasca/django/commit/3c1c28329ff2310191aa7ba29acfadc020771516
 I don't know why it won't let me pull request to your fork (it lets me
 pull request any other fork). Please cherry pick...

 I would love to get rid of the `ChangeList` class too. It will be hard
 work tough, and might be considered BC.

 As you said, much of the code could live in a generic CBV from #16256. One
 of the things we need to decide in that ticket is for example if we are
 aiming to use those views here or not. I don't know how much of those can
 be used without breaking BC or without making the API based on not
 breaking the admin BC. If we decide to break BC (for example in a new-new-
 admin) there's many, many things that can be improved and dogfood other
 tickets as well..

 I agree with julien (talked with him in IRC) that the best thing is to
 tackle the problems separately and then see if we can merge them at a
 latter step.

 Another thought on future work (maybe 2.0?) is to get rid of the
 ModelAdmin and just subclass the admin views directly, let's say we have
 #16213 with some sugar on top for example.

 As for the immediate work, I think we really need to look closer at the
 failing tests, it seems like a deeper problem in the generic CBV than in
 this refactor. Otherwise this looks good for me.

-- 
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] #18390: p90x workout

2012-05-27 Thread Django

#18390: p90x workout
--+--
 Reporter:  anonymous |  Owner:  oqSkKZTH
 Type:  Bug   | Status:  new
Component:  contrib.sessions  |Version:  1.1-beta-1
 Severity:  Normal|   Keywords:  p90x workout
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  1
--+--
 [http://tickets-here.com p90x reviews] I greatly appreciate this. You must
 keep up the good work.

-- 
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] #17646: Create a get_list_filter hook in ModelAdmin

2012-05-27 Thread Django

#17646: Create a get_list_filter hook in ModelAdmin
---+
 Reporter:  rasca  |Owner:  mateusgondim
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by mateusgondim):

 * 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] #18332: No generic way to get database backend version

2012-05-27 Thread Django

#18332: No generic way to get database backend version
-+-
 Reporter:  apollovy@…   |Owner:
 Type:  Bug  |  vanessagomes
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by vanessagomes):

 * has_patch:  0 => 1


Comment:

 An example of use is:


 {{{
 from django.db import connection
 print (connection.backend_info())
 sqlite 3.7.2
 }}}

 The patch only resolve the solution for sqlite3 database. After I'll
 submit patches for postegresql, and other databases.

-- 
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] #17736: django.contrib.gis.geos.polygon from_bbox loss of floating-point accuracy

2012-05-27 Thread Django

#17736: django.contrib.gis.geos.polygon from_bbox loss of floating-point 
accuracy
-+
 Reporter:  tdihp@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by DavidEklund):

 * cc: daek@… (added)
 * has_patch:  0 => 1


Comment:

 As noted above the str() method of floats rounds the input to 12 digits. I
 guess python floats are double precision (depends on the machine one is
 using?), which means roughly 16 digits of accuracy. In contrast to str(),
 the repr() method of floats preserves double precision: it truncates the
 input to 17 digits. So for floats it might make more sense to use repr()
 than to use str().

 Perhaps one wants to keep the option of passing strings to from_bbox() and
 also create the polygon using GEOSGeometry directly. In that case, one
 might consider using repr() if the coordinate is a float and str()
 otherwise:
 {{{
 def from_bbox(cls, bbox):
 "Constructs a Polygon from a bounding box (4-tuple)."
 box_string = []
 for z in bbox:
 if isinstance(z, float):
 box_string.append(repr(z))
 else:
 box_string.append(str(z))
 x0, y0, x1, y1 = box_string
 return GEOSGeometry( 'POLYGON((%s %s, %s %s, %s %s, %s %s, %s
 %s))' %  (
 x0, y0, x0, y1, x1, y1, x1, y0, x0, y0) )
 }}}

-- 
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] #18135: Sleeping Database Connections on Startup with MySQL

2012-05-27 Thread Django

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  MySQL| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by russellm):

 Why has this patch been applied to the 1.3.X branch? The *only* patches
 that should be applied to 1.3 are those that will result in a security
 release.

-- 
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] #17208: Dogfood class-based views in contrib.admin

2012-05-27 Thread Django

* needs_docs: 0 => 1
* has_patch: 0 => 1

Comment:

So, I have rewritten the admin views into CBVs. The code can be viewed
here: https://github.com/jphalip/django/compare/master...features%2Fadmin-
cbv

This is only the first pass, the main aim as this stage being to remain
completely backwards compatible. Thus, the whole test suite currently
passes unchanged, except for 2 failures which are apparently due to some
generic CBVs executing one more database query than needed — this could be
somewhat related to #18354.

{{{
==
FAIL: test_group_permission_performance
(regressiontests.admin_views.tests.GroupAdminTest)
--
Traceback (most recent call last):
File

"/Users/julien/Documents/Development/eclipse/workspace/DjangoCore/django/tests/regressiontests/admin_views/tests.py",
line 3314, in test_group_permission_performance
self.assertEqual(response.status_code, 200)
File "/Users/julien/.virtualenvs/djangotests2.6/lib/python2.6/site-
packages/django/test/testcases.py", line 273, in __exit__
executed, self.num
AssertionError: 7 != 6 : 7 queries executed, 6 expected

==
FAIL: test_user_permission_performance
(regressiontests.admin_views.tests.UserAdminTest)
--
Traceback (most recent call last):
File

"/Users/julien/Documents/Development/eclipse/workspace/DjangoCore/django/tests/regressiontests/admin_views/tests.py",
line 3276, in test_user_permission_performance
self.assertEqual(response.status_code, 200)
File "/Users/julien/.virtualenvs/djangotests2.6/lib/python2.6/site-
packages/django/test/testcases.py", line 273, in __exit__
executed, self.num
AssertionError: 9 != 8 : 9 queries executed, 8 expected
}}}

The immediate benefit is that we're getting more hooks, as through this
refactoring process some of the views' code has been broken into smaller
pieces.

Some opportunities that can now be considered are:
- Add even more hooks, by breaking down some of the remaining long chunks
of code into smaller methods, where it makes sense.
- Finally get rid of the `ChangeList` class, which is a private API and
has always been a PITA to work with. It could potentially be merged into
the change list CBV.
- Write more generic views for handling some use cases that are needed in
the admin and that could potentially be needed in other contexts (e.g.
inline formsets: #16256).
- As part of future work, we could provide a RESTful API for the admin so
it can be manipulated via Ajax requests.

So, again, I see this work as the initial step towards making the admin
more flexible and customizable. That said, I'm still not entirely sold on
the approach. Using CBVs does provide a lot more flexibility, but it comes
at the cost of increasing the code's complexity. While the admin is
arguably the Django app that needs the most flexibility in the world, we
still want to keep things manageable and not too hard to maintain.

As far as backwards compatibility is concerned, we also need to decide how
compatible we want to remain in 1.5 and beyond? If breaking compatibility
is necessary at some stage to ensure that we start off with a manageable
and maintainable codebase, then I'd personally be ok as long as the
upgrade path is made simple.

I'd love to get feedback on the work done so far and hear some ideas on
the next steps. Since this is a pretty massive effort which would impact a
lot of people, I'll also probably bring this topic up on the mailing list.

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

Re: [Django] #17736: django.contrib.gis.geos.polygon from_bbox loss of floating-point accuracy

2012-05-27 Thread Django

#17736: django.contrib.gis.geos.polygon from_bbox loss of floating-point 
accuracy
-+
 Reporter:  tdihp@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by DavidEklund):

 I think this makes sense, I have attached a patch making this change.

 Replying to [comment:2 anonymous]:
 > I think
 >
 > {{{
 > return Polygon(((l,t),(r,t),(r,b),(l,b),(l,t)))
 > }}}
 >
 > would be good enough for the from_bbox function.
 > Django's geos documention didn't mention that bbox can be strings, yet
 (am I right?).
 > So that we can forget the digits, 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 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] #18332: No generic way to get database backend version

2012-05-27 Thread Django

#18332: No generic way to get database backend version
-+-
 Reporter:  apollovy@…   |Owner:
 Type:  Bug  |  vanessagomes
Component:  Database layer   |   Status:  new
  (models, ORM)  |  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 anonymous):

 * easy:  1 => 0


Comment:

 This bug takes some effort, because we have to implement a function for
 each backend database. And test for each one. So this pain, to install,
 connect and check for each database makes the bug less-easy.

-- 
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] #17700: Django formset documentation missing Class Based View Docs

2012-05-27 Thread Django

#17700: Django formset documentation missing Class Based View Docs
-+-
 Reporter:  rh0dium  |Owner:  Fandekasp
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:  invalid
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by rasca):

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


Comment:

 Hi, I'm going to close this as we are preparing class based generic views
 for formsets and there's were we will be adding the documentation. Adding
 docs about creating a formset cbv sounds more like a tutorial on how to
 make your own generic cbv (which is not a bad thing, but that sound like a
 separate ticket).

 If you'd like to chime in in ticket #16256 you are more than welcome! I'm
 not an english native speaker and docs is always my weakest front. Any
 help we'll be much appreciated.

-- 
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] c3b56c: Used call_command in i18n compilation tests.

2012-05-27 Thread GitHub

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

  Changed paths:
M tests/regressiontests/i18n/commands/compilation.py

  Log Message:
  ---
  Used call_command in i18n compilation tests.

Now that call_command does not raise SystemExit any more, we can
use call_command again for testing compilemessages.



-- 
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] cc4b4d: Used CommandError in createcachetable command.

2012-05-27 Thread GitHub

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

  Changed paths:
M django/core/management/commands/createcachetable.py
M tests/regressiontests/cache/tests.py

  Log Message:
  ---
  Used CommandError in createcachetable command.

Raising CommandError whenever a management command meets an error
condition is the standard way to handle errors in commands.



-- 
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] #10403: provide declarative syntax to define FormSets - including ModelFormSet and InlineFormSet

2012-05-27 Thread Django

#10403: provide declarative syntax to define FormSets - including ModelFormSet 
and
InlineFormSet
-+-
 Reporter:  Koen Biermans|Owner:  nobody
|   Status:  new
 Type:  New feature  |  Version:  master
Component:  Forms|   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  formset  |  decision needed
  modelformset inlineformset |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by rasca):

 Adding a comment from #16289:

 > This would be very useful for a nicer implementation of the formset
 derived cbv #16256.
 >
 > The BaseInlineFormSet? is the only tricky one with the
 _get_foreign_key() and the max_num override when fk.unique=True .
 >
 > I'd also move the defaults (e.g. extra=3) to the BaseFormSet? and make
 the factories only pass dict keys whose value isn't None to type().

-- 
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] #18389: Field type attributes not permitted on models

2012-05-27 Thread Django

#18389: Field type attributes not permitted on models
-+-
 Reporter:  john.arnfield@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 anonymous):

 Maybe the resolution here is that anything with contribute_to_class will
 be tried for add to class. This could be solved if the contribute_to_class
 method must be a bound method by checking for
 `value.contribute_to_class.__self__` is not None.

-- 
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] #18389: Field type attributes not permitted on models

2012-05-27 Thread Django

#18389: Field type attributes not permitted on models
-+-
 Reporter:  john.arnfield@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 anonymous):

 * 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 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] #18389: Field type attributes not permitted on models

2012-05-27 Thread Django

#18389: Field type attributes not permitted on models
--+
 Reporter:  john.arnfield@…   |  Owner:  nobody
 Type:  Uncategorized | 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
--+
 I have a situation where I need to reference a django model-field type in
 my models, something that would look like the following:

 {{{
 from django.db import models
 class MyModel(models.Model):
   referenced_field = models.CharField
   # ... field declarations here
 }}}

 The omission of parenthesis on the CharField is intentional. I do not want
 to create a field on this model, I simply need to reference a field type
 that this model is associated with.

 Unfortunately this causes a type error:

 {{{
 TypeError: Error when calling the metaclass bases
 unbound method contribute_to_class() must be called with AutoField
 instance as first argument (got ModelBase instance instead)
 }}}

 This is down to ModelBase.add_to_class being overly naive in the way it
 calls contribute_to_class (it uses hasattr to check for things that define
 contribute_to_class, but doesn't care if they're types or objects).

 One solution to this problem would be to change the class attribute in to
 a classmethod, but the problem seems a little unnecessary and feels like
 it should be cleaned up regardless. Unfortunately, I'm not sure what the
 ideal solution would be for this case, else I'd already have submit a
 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] #16418: Class based generic DetailView tries to access non-existant _meta field when get_object has been modified to return a ModelForm

2012-05-27 Thread Django

#16418: Class based generic DetailView tries to access non-existant _meta field
when get_object has been modified to return a ModelForm
-+-
 Reporter:  kd4ttc   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  genericviews | Triage Stage:  Accepted
  modelform  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I agree that isinstance check is the correct one here. I don't see the
 value of duck typing in this case, it is not at all well defined what
 behavior the duck should have. It just having the _meta/model attribute is
 _not_ what we are interested in. So, isinstance is valid 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 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] #18135: Sleeping Database Connections on Startup with MySQL

2012-05-27 Thread Django

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  MySQL| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

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

 In [a15d3b58d8c4cbb6137f0458544ec03f3394bb08]:
 {{{
 #!CommitTicketReference repository=""
 revision="a15d3b58d8c4cbb6137f0458544ec03f3394bb08"
 [1.3.x] Fixed #18135 -- Close connection used for db version checking

 On MySQL when checking the server version, a new connection could be
 created but never closed. This could result in open connections on
 server startup.

 Backport of 4423757c0c50afbe2470434778c8d5e5b4a70925.
 }}}

-- 
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] a15d3b: [1.3.x] Fixed #18135 -- Close connection used for ...

2012-05-27 Thread GitHub

  Branch: refs/heads/stable/1.3.x
  Home:   https://github.com/django/django
  Commit: a15d3b58d8c4cbb6137f0458544ec03f3394bb08
  
https://github.com/django/django/commit/a15d3b58d8c4cbb6137f0458544ec03f3394bb08
  Author: Michael Newman 
  Date:   2012-05-27 (Sun, 27 May 2012)

  Changed paths:
M django/db/backends/mysql/base.py
M tests/regressiontests/backends/tests.py

  Log Message:
  ---
  [1.3.x] Fixed #18135 -- Close connection used for db version checking

On MySQL when checking the server version, a new connection could be
created but never closed. This could result in open connections on
server startup.

Backport of 4423757c0c50afbe2470434778c8d5e5b4a70925.



-- 
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] #15605: Testing cannot be loaded when models.py is missing

2012-05-27 Thread Django

#15605: Testing cannot be loaded when models.py is missing
---+--
 Reporter:  the_drow   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.2
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by rasca):

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


Comment:

 You shouldn't reopen a ticket that was closed by a core developer. If you
 think the decision was wrong you can take it to the mailing list. Closing
 it for this reason (duplicate of #7198).

 As stated by aagustin (
 https://code.djangoproject.com/ticket/7198#comment:22 ) removing the need
 for a models.py isn't trivial. If IIRC the soc2010-app-loading branch had
 this into consideration.

-- 
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] #18135: Sleeping Database Connections on Startup with MySQL

2012-05-27 Thread Django

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  MySQL| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

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

 In [0f69a16785b88d03dc246a652cf348e0f2704e8e]:
 {{{
 #!CommitTicketReference repository=""
 revision="0f69a16785b88d03dc246a652cf348e0f2704e8e"
 [1.4.x] Fixed #18135 -- Close connection used for db version checking

 On MySQL when checking the server version, a new connection could be
 created but never closed. This could result in open connections on
 server startup.

 Backport of 4423757c0c50afbe2470434778c8d5e5b4a70925.
 }}}

-- 
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] 0f69a1: [1.4.x] Fixed #18135 -- Close connection used for ...

2012-05-27 Thread GitHub

  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: 0f69a16785b88d03dc246a652cf348e0f2704e8e
  
https://github.com/django/django/commit/0f69a16785b88d03dc246a652cf348e0f2704e8e
  Author: Michael Newman 
  Date:   2012-05-27 (Sun, 27 May 2012)

  Changed paths:
M django/db/backends/mysql/base.py
M tests/regressiontests/backends/tests.py

  Log Message:
  ---
  [1.4.x] Fixed #18135 -- Close connection used for db version checking

On MySQL when checking the server version, a new connection could be
created but never closed. This could result in open connections on
server startup.

Backport of 4423757c0c50afbe2470434778c8d5e5b4a70925.



-- 
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] #10200: loaddata command does not raise CommandError on errors

2012-05-27 Thread Django

#10200: loaddata command does not raise CommandError on errors
-+-
 Reporter:  lgs  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  exit status  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


Comment:

 Here's an updated patch for this issue.

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

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

Re: [Django] #18387: Provide a way to skip sys.exit() when using call_command()

2012-05-27 Thread Django

#18387: Provide a way to skip sys.exit() when using call_command()
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   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 Claude Paroz ):

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


Comment:

 In [f2b6763ad7cb281ca8699a9c3d532a82f965be4f]:
 {{{
 #!CommitTicketReference repository=""
 revision="f2b6763ad7cb281ca8699a9c3d532a82f965be4f"
 Fixed #18387 -- Do not call sys.exit during call_command.

 Moved sys.exit(1) so as failing management commands reach it
 only when running from command line.
 }}}

-- 
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] f2b676: Fixed #18387 -- Do not call sys.exit during call_c...

2012-05-27 Thread GitHub

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

  Changed paths:
M django/contrib/auth/tests/management.py
M django/core/management/base.py
M docs/howto/custom-management-commands.txt
M docs/releases/1.5.txt
M tests/modeltests/fixtures/tests.py
M tests/modeltests/user_commands/management/commands/dance.py
M tests/modeltests/user_commands/tests.py

  Log Message:
  ---
  Fixed #18387 -- Do not call sys.exit during call_command.

Moved sys.exit(1) so as failing management commands reach it
only when running from command line.



-- 
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] #18388: Add more hooks in the ModelAdmin (get_extra, get_max_num) (was: problematic code in InlineModelAdmin)

2012-05-27 Thread Django

#18388: Add more hooks in the ModelAdmin (get_extra, get_max_num)
---+
 Reporter:  d.willy.c.c@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 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
---+
Changes (by rasca):

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


Comment:

 This is in tone with #17646, #17006 and #16841.

 I'm accepting this based on that they are similar to the other ones,
 adding hooks to the ModelAdmin.

 Maybe we can think a way to add this "hooks" in a more DRY way than adding
 a function get_FOO(self, request): return self.FOO

-- 
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] #18135: Sleeping Database Connections on Startup with MySQL

2012-05-27 Thread Django

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  MySQL| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [4423757c0c50afbe2470434778c8d5e5b4a70925]:
 {{{
 #!CommitTicketReference repository=""
 revision="4423757c0c50afbe2470434778c8d5e5b4a70925"
 Fixed #18135 -- Close connection used for db version checking

 On MySQL when checking the server version, a new connection could be
 created but never closed. This could result in open connections on
 server startup.
 }}}

-- 
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] 442375: Fixed #18135 -- Close connection used for db versi...

2012-05-27 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 4423757c0c50afbe2470434778c8d5e5b4a70925
  
https://github.com/django/django/commit/4423757c0c50afbe2470434778c8d5e5b4a70925
  Author: Michael Newman 
  Date:   2012-05-27 (Sun, 27 May 2012)

  Changed paths:
M django/db/backends/mysql/base.py
M tests/regressiontests/backends/tests.py

  Log Message:
  ---
  Fixed #18135 -- Close connection used for db version checking

On MySQL when checking the server version, a new connection could be
created but never closed. This could result in open connections on
server startup.



-- 
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] #18332: No generic way to get database backend version

2012-05-27 Thread Django

#18332: No generic way to get database backend version
-+-
 Reporter:  apollovy@…   |Owner:
 Type:  Bug  |  vanessagomes
Component:  Database layer   |   Status:  new
  (models, ORM)  |  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
-+-
Changes (by anonymous):

 * owner:  nobody => vanessagomes


-- 
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] #18332: No generic way to get database backend version

2012-05-27 Thread Django

#18332: No generic way to get database backend version
-+-
 Reporter:  apollovy@…   |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:  1|
-+-
Changes (by akaariai):

 * stage:  Unreviewed => Accepted


Comment:

 I am accepting this ticket, but I think there should be some generic
 property returning not the server version, but a more generic string
 explaining the used server backend:
 {{{
 from django.db import connection
 print(connection.backend_info)
 OUT: PostgreSQL 8.4.11, Psycopg2 2.4.4.
 }}}
 So, this should not aim for programmatic usability (the pg_version is
 useful for that), instead something that would be usable in for example
 django-users: "Can you provide your backend info (as reported by
 connection.backend_info)".

 A more generic Django.debug_info could be usable, too, but of course not
 this ticket's problem. This could include such things as used Python
 version, OS, backend info for each backend, and of course Django version.
 This would be pretty useful to require in tickets...

-- 
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] #18135: Sleeping Database Connections on Startup with MySQL

2012-05-27 Thread Django

#18135: Sleeping Database Connections on Startup with MySQL
-+-
 Reporter:  Mnewman  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Uncategorized|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by akaariai):

 I think the problem is gone in master, but this still needs to be fixed in
 1.4 and 1.3. Master should get this fix, too, even if the problem isn't
 present in model validation.

-- 
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] #18343: Refactor deferred model implementation

2012-05-27 Thread Django

#18343: Refactor deferred model implementation
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (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 Anssi Kääriäinen ):

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


Comment:

 In [a8a81aae20a81e012fddc24f3ede556501af64a2]:
 {{{
 #!CommitTicketReference repository=""
 revision="a8a81aae20a81e012fddc24f3ede556501af64a2"
 Fixed #18343 -- Cleaned up deferred model implementation

 Generic cleanup and dead code removal in deferred model field loading
 and model.__reduce__().

 Also fixed an issue where if an inherited model with a parent field
 chain parent_ptr_id -> id would be deferred loaded, then accessing
 the id field caused caused a database query, even if the id field's
 value is already loaded in the parent_ptr_id field.
 }}}

-- 
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] a8a81a: Fixed #18343 -- Cleaned up deferred model implemen...

2012-05-27 Thread GitHub

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

  Changed paths:
M django/db/models/base.py
M django/db/models/query_utils.py
M tests/modeltests/defer/tests.py
M tests/modeltests/field_subclassing/tests.py

  Log Message:
  ---
  Fixed #18343 -- Cleaned up deferred model implementation

Generic cleanup and dead code removal in deferred model field loading
and model.__reduce__().

Also fixed an issue where if an inherited model with a parent field
chain parent_ptr_id -> id would be deferred loaded, then accessing
the id field caused caused a database query, even if the id field's
value is already loaded in the parent_ptr_id field.



-- 
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] #11916: Extra params + aggregation creates incorrect SQL.

2012-05-27 Thread Django

#11916: Extra params + aggregation creates incorrect SQL.
-+-
 Reporter:  jaklaassen@… |Owner:  nobody
 Type:  Uncategorized|   Status:  reopened
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Is there some actual error here, to me it seems the fix was just adding
 parentheses in there, and backends other than Oracle are supposed to work
 with the subquery in the GROUP BY clause.

-- 
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] #11916: Extra params + aggregation creates incorrect SQL.

2012-05-27 Thread Django

#11916: Extra params + aggregation creates incorrect SQL.
-+-
 Reporter:  jaklaassen@… |Owner:  nobody
 Type:  Uncategorized|   Status:  reopened
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by roberto.maurizzi@…):

 * status:  closed => reopened
 * severity:   => Normal
 * resolution:  fixed =>
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => Uncategorized


Comment:

 I just tested this in 1.3, 1.3.1, 1.4 with PostgreSQL and on a 1.4 demo
 project with SQLITE
 Every time I got a whole subquery expanded in my GROUP BY

 Assuming this Book model (taken fromthe aggregation docs at
 en/dev/topics/db/aggregation/, the link is caught as spam :-) )

 {{{#!python

 class Author(models.Model):
name = models.CharField(max_length=100)
age = models.IntegerField()
friends = models.ManyToManyField('self', blank=True)

 class Publisher(models.Model):
name = models.CharField(max_length=300)
num_awards = models.IntegerField()

 class Book(models.Model):
isbn = models.CharField(max_length=9)
name = models.CharField(max_length=300)
pages = models.IntegerField()
price = models.DecimalField(max_digits=10, decimal_places=2)
rating = models.FloatField()
authors = models.ManyToManyField(Author)
publisher = models.ForeignKey(Publisher)
pubdate = models.DateField()

 class Store(models.Model):
name = models.CharField(max_length=300)
books = models.ManyToManyField(Book)
 }}}

 if I define
 {{{#!python
qs = Book.objects.extra(select={'example': 'SELECT COUNT(*) FROM BOOK
 WHERE pages < 100'}).filter(price__gte=20).annotate(totpages=Sum('pages'))
 }}}
 then I get
 {{{#!python
 >>> print qs.query
 SELECT (SELECT COUNT(*) FROM BOOK WHERE pages < 100) AS "example",
 "bugtest_book"."id", "bugtest_book"."isbn",
 "bugtest_book"."name", "bugtest_book"."pages", "bugtest_book"."price",
 "bugtest_book"."rating", "bugtest_book"."publisher_id",
 "bugtest_book"."pubdate", SUM("bugtest_book"."pages") AS "totpages"
 FROM "bugtest_book" WHERE "bugtest_book"."price" >= 20
 GROUP BY "bugtest_book"."id", "bugtest_book"."isbn",
 "bugtest_book"."name", "bugtest_book"."pages",
 "bugtest_book"."price", "bugtest_book"."rating",
 "bugtest_book"."publisher_id", "bugtest_book"."pubdate",
 (SELECT COUNT(*) FROM BOOK WHERE pages < 100)   <
 }}}


 The code originally in django/db/models/sql/query.py is now in
 django/db/models/sql/compiler.py @ line 555 and is the same that was used
 in query.py before 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] #10810: FormWizard validates the last form twice

2012-05-27 Thread Django

#10810: FormWizard validates the last form twice
---+
 Reporter:  Qrilka |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  contrib.formtools  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  wizard validation  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by anonymous):

 woops... massive mistake there!  that if statement should be the other way
 around!

 {{{
 if form_key != self.steps.last and not form_obj.is_valid():
 }}}

 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 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] #10810: FormWizard validates the last form twice

2012-05-27 Thread Django

#10810: FormWizard validates the last form twice
---+
 Reporter:  Qrilka |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  contrib.formtools  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  wizard validation  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by hal_robertson@…):

 Replying to [comment:9 hal_robertson@…]:
 > Replying to [comment:8 jezdez]:
 > > Superseded by #9200.
 >
 > why does the last form need to be validated twice?
 >
 > the above could be modified as:
 >
 >  1. first validation after each form is submitted
 >  2. second validation, once we validate the last form, when all wizard
 forms are validated together (all except the last one again!), .
 >
 > that way you could retain the ability to put a captcha on the last form

 {{{
 --- views.py2012-05-27 09:15:46.0 -0300
 +++ views.py.new2012-05-27 09:15:25.0 -0300
 @@ -316,11 +316,11 @@
  # walk through the form list and try to validate the data again.
  for form_key in self.get_form_list():
  form_obj = self.get_form(step=form_key,
  data=self.storage.get_step_data(form_key),
  files=self.storage.get_step_files(form_key))
 -if not form_obj.is_valid():
 +if not form_obj.is_valid() and form_key != self.steps.last:
  return self.render_revalidation_failure(form_key,
 form_obj, **kwargs)
  final_form_list.append(form_obj)

  # render the done view and reset the wizard before returning the
  # response. This is needed to prevent from rendering done with
 the
 }}}

-- 
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] #15574: IndexError: list index out of range caused by inline formsets

2012-05-27 Thread Django

#15574: IndexError: list index out of range caused by inline formsets
-+-
 Reporter:  poswald  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  inline formset   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by visik7):

 Patch doesn't apply on 1.3.1 is it for 1.4 ?

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

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

Re: [Django] #10810: FormWizard validates the last form twice

2012-05-27 Thread Django

#10810: FormWizard validates the last form twice
---+
 Reporter:  Qrilka |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  contrib.formtools  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  wizard validation  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by hal_robertson@…):

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


Comment:

 Replying to [comment:8 jezdez]:
 > Superseded by #9200.

 why does the last form need to be validated twice?

 the above could be modified as:

  1. first validation after each form is submitted
  2. second validation, once we validate the last form, when all wizard
 forms are validated together (all except the last one again!), .

 that way you could retain the ability to put a captcha on the last form

-- 
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] #16951: Example for dumpdata of permissions

2012-05-27 Thread Django

#16951: Example for dumpdata of permissions
---+
 Reporter:  googol |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by aaugustin):

 Also, dumping permissions doesn't make sense, because they're
 automatically created by syncdb.

-- 
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] #18388: problematic code in InlineModelAdmin

2012-05-27 Thread Django

#18388: problematic code in InlineModelAdmin
---+
 Reporter:  d.willy.c.c@…  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 in class InlineModelAdmin and def get_formset in line 1401
 defaults = {
 "form": self.form,
 "formset": self.formset,
 "fk_name": self.fk_name,
 "fields": fields,
 "exclude": exclude,
 "formfield_callback": partial(self.formfield_for_dbfield,
 request=request),
 "extra": self.extra,
 "max_num": self.max_num,
 "can_delete": can_delete,
 }
 I think that is more customizable code should be as follows
 "form": self.form,
 "formset": self.formset,
 "fk_name": self.fk_name,
 "fields": fields,
 "exclude": exclude,
 "formfield_callback": partial(self.formfield_for_dbfield,
 request=request),
 "extra": '''self.get_extra()''',
 "max_num": '''self.get_max_num()''',
 "can_delete": can_delete,

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

44 matches

Mail list logo