Re: [Django] #18985: DeprecationWarning no longer loud by default in Python 2.7+

[Django]

#18985: DeprecationWarning no longer loud by default in Python 2.7+
--+
 Reporter:  dstufft   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 OK. Making them verbose when `DEBUG = True` sounds like a good compromise.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18985: DeprecationWarning no longer loud by default in Python 2.7+

[Django]

#18985: DeprecationWarning no longer loud by default in Python 2.7+
--+
 Reporter:  dstufft   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by ptone):

 If I have to pick between siding with what is in the best interest of
 Django Users, or Python core, I'm going to bias slightly toward the users.
 I had also considered using a different warning class - but I think we are
 actually using DeprecationWarning exactly as intended - and really the
 decision is the same as changing the filters, just getting there via
 another route.  It seems pretty clear that Django is a developer tool -
 not end user software.  The end users are web users and aren't exposed to
 warnings.

 http://docs.python.org/dev/whatsnew/2.7.html#the-future-for-python-2-x

 Reenabling warning output is suggested as an option in the above docs - so
 I'm not sure why it is considered anti-python (Alex to this position on
 IRC) to choose to display warnings in a context where it makes sense (a
 Django development environment).

 Another option is to just enable the deprecation warning output inside the
 runserver command - as we make clear this is a dev server.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19299: Foreign keys using to_field and having legitimate empty string values fail with NULL errors

[Django]

#19299: Foreign keys using to_field and having legitimate empty string values 
fail
with NULL errors
-+-
 Reporter:  evan@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 tunixman):

 And here's the new repo and branch I've cloned for this ticket, including
 all of the changes I've made so far:
 
[https://github.com/tunixman/django/commit/386ef64784a90aafbd8eace51d512dee886030a4]

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19299: Foreign keys using to_field and having legitimate empty string values fail with NULL errors

[Django]

#19299: Foreign keys using to_field and having legitimate empty string values 
fail
with NULL errors
-+-
 Reporter:  evan@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 tunixman):

 I also do believe in the `get_db_prep_save` case we will need to check
 since we're not just returning the value in the case of NULL, but also
 chaining on some additional processing. I've updated the code locally and
 I'm rerunning the tests for it now.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19299: Foreign keys using to_field and having legitimate empty string values fail with NULL errors

[Django]

#19299: Foreign keys using to_field and having legitimate empty string values 
fail
with NULL errors
-+-
 Reporter:  evan@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 tunixman):

 I'm reworking the patch now to include another case of collapsing `''` to
 `None` regardless of the `interprets_empty_strings_as_nulls` feature now,
 and I'll post an update momentarily.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:  akaariai
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 I removed the join_cache as I haven't been able to show it improves
 performance in any of the djangobench benchmarks. If needed it is fairly
 simple to re-add the cache.

 What the patch does is that it splits setup_joins() into two parts.
 Currently we do "for each lookup in the given lookup path, resolve lookup
 part, immediately add the found joins to query". This is changed to "First
 resolve the whole lookup path. After resolve add the joins into the
 query".

 The names_to_path() method does the resolving. It is somewhat complex, but
 the code is pretty much exactly what we had before in setup_joins() minus
 the actual join generation. As a result of the split the actual join setup
 is around 10 lines and trim_joins() is made cleaner, too.

 While for this ticket this refactoring isn't the minimal change, the work
 done allows doing two further improvements:
   1. Moving of the names_to_path() call into the beginning of add_filter()
 - this in turn will allow resolving some more bugs (for example F() are
 currently double-added in multi_join exclude cases), and will also make
 custom lookups much easier to add (see #16187).
   2. Moving the names_to_path() method to model._meta. This will allow
 custom meta objects to alter the behaviour of join generation, and will
 also allow code outside sql/query.py to reuse the same resolution code
 (Admin for example has duplicate code for this).

 So, the patch isn't about this ticket alone.

 Reading the patch itself is nearly impossible. The diff generated just
 happens to interleave badly. After applying the patch the resulting code
 should be more readable than the old code. Is there some specific part of
 the resulting code which seems hard to understand? I would really
 appreciate if you could do a side-by-side read of the old and new
 setup_joins() + trim_joins(). If the old code is easier to understand than
 the new code then that is a problem. This is of course a possibility - it
 is easy for me to understand the code I just wrote...

 This change is a big change, and big changes to ORM tend to be scary. In
 my opinion the change is needed. Now seems to be the perfect time to add
 this into master. 1.6 is more than six months away so we have plenty of
 time to find regressions and fix them.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19303: ModelAdmin.formfield_overrides is ignored for fields with choices

[Django]

#19303: ModelAdmin.formfield_overrides is ignored for fields with choices
---+--
 Reporter:  bendavis78 |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by bendavis78):

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


Comment:

 Pull request here: https://github.com/django/django/pull/519

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #16455: Postgis 2.0 Compatibility

[Django]

#16455: Postgis 2.0 Compatibility
-+-
 Reporter:  ckarrie  |Owner:  jbronn
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  postgis 2.0  | 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 anonymous):

 That much is obvious, otherwise the bugs wouldn't be there ;)

 Is there any specific reason why there shouldn't be Postgis 2 support in
 DJango?
 Postgis 1.x development will cease eventually so it would be good to start
 thinking about Postgis 2 support.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19302: Add option to disable Admin log (LogEntry)

[Django]

#19302: Add option to disable Admin log (LogEntry)
---+--
 Reporter:  shadow |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by shadow):

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


Comment:

 It would also be preferable if you could have options to:

 * disable it globally (also disabling logging for the Auth app etc.)
 * disable it for individual models
 * disable it for individual apps

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19303: ModelAdmin.formfield_overrides is ignored for fields with choices

[Django]

#19303: ModelAdmin.formfield_overrides is ignored for fields with choices
---+
 Reporter:  bendavis78 |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Let's say we have custom field that extends CharField, which holds comma-
 separated values. Then, let's say we've made a custom widget that
 overrides CheckboxMultipleSelect, and takes the field's choices and
 combines them into comma-separated values, and we want to use that in the
 admin:

 {{{#!python
 class MyModel(models.Model):
 foo = models.MyCustomField(choices=(('FOO', 'Foo'),('BAR',
 'Bar')))

 class MyAdmin(admin.ModelAdmin):
  formfield_overrides = {
  MyCustomField: MyCustomWidget
  }
 }}}


 In ModelAdmin, the formfield_for_dbfield will normally check
 formfield_overrides to see if there are any overrides. That is, unless,
 the field has choices.  If the field has choices,
 formfield_for_choice_field is called, and formfield_overrides is ignored
 completely.

 I know that there are other ways of overriding form fields, but it seems
 that ModelAdmin.formfield_overrides does not work as advertised.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
---+
 Reporter:  pixelcort  |Owner:  Gargamel
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  1
---+

Comment (by bjola):

 Another bug: in contrib/admin/static/js/inlines.js, the lines:
 {{{
 // Update Form Properties
 template.find('#id_' + formset_prefix + '-TOTAL_FORMS').val(1);
 update_props(template, normalized_formset_prefix, formset_prefix);
 }}}

 should be
 {{{
 // Update Form Properties
 update_props(template, normalized_formset_prefix, formset_prefix);
 template.find('#id_' + formset_prefix + '-TOTAL_FORMS').val(1);
 template.find('#id_' + formset_prefix + '-INITIAL_FORMS').val(0);
 }}}

 Because the TOTAL_FORMS and INITIAL_FORMS inputs do not have the right IDs
 until update_props is run. And INITIAL_FORMS needs to be 0, otherwise the
 server-side validation tries to save non-existing nested forms.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19302: Add option to disable Admin log (LogEntry)

[Django]

#19302: Add option to disable Admin log (LogEntry)
---+
 Reporter:  shadow |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 Could there please be an option to disable the Admin log (LogEntry model).

 Use case: An app designed for sensitive information, where deletion of
 objects must leave no trace.

 cheers

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #11732: ModelAdmin.get_changelist_form should use ModelAdmin.form

[Django]

#11732: ModelAdmin.get_changelist_form should use ModelAdmin.form
-+-
 Reporter:  edcrypt  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  1.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 Any updates on this ?

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18985: DeprecationWarning no longer loud by default in Python 2.7+

[Django]

#18985: DeprecationWarning no longer loud by default in Python 2.7+
--+
 Reporter:  dstufft   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by russellm):

 @aaugustin - I agree with the broad principle that we shouldn't diverge
 from Python, but in this case, it seems to undermine our broader strategy.
 We specifically chose PendingDeprecationWarning and DeprecationWarning as
 a 2 phase mechanism for slowly introducing change in a way that couldn't
 be easily ignored; Python core policy seems to be undermining our
 intentions in this case.

 Another option: Can we introduce a new warning subclass that *isn't*
 silenced by default? Reading the 2.7 release notes, it seems clear to me
 that the intention from Python core is that DeprecationWarning is for a
 different purpose to what we're using it; in which case, it would make
 sense to introduce a new warning type that serves *our* purposes.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:  akaariai
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by milosu):

 Maybe one question regarding the latest patch:

 Why setup_join_cache was removed?

 Are performance implications of this removal well understood / measured
 somehow ?

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:  akaariai
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by milosu):

 Being the author of all the previous patches to this ticket, I have to say
 that (without a week of poking and testing) I can't understand your latest
 patch anymore.

 Hope there are enough regression tests there.

 I will make a deeper review of the new ORM code path in a year or two.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19296: LiveServerTestCase does not share connection to sqlite if using spatialite

[Django]

#19296: LiveServerTestCase does not share connection to sqlite if using 
spatialite
-+-
 Reporter:  pegler@… |Owner:  pegler
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite spatialite| Triage Stage:  Accepted
  LiveServerTestCase |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by pegler):

 * has_patch:  0 => 1


Comment:

 I added a patch that fixes this.  I was unsure how to write a test for
 this.  Conceivably the test could start a LiveServer and override the
 default database to be spatialite and then make sure that a particular
 view loads data from the DB correctly.  This test is in core and geodjango
 is in contrib, so I was not sure where the test should go or if it was
 reasonable to require spatialite be installed in order to run the tests of
 django core.  Please advise on what test is required for this.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19299: Foreign keys using to_field and having legitimate empty string values fail with NULL errors

[Django]

#19299: Foreign keys using to_field and having legitimate empty string values 
fail
with NULL errors
-+-
 Reporter:  evan@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 tunixman):

 I think if Oracle treats them the same way, it will regardless of which we
 return, so maybe we can just return the correct value regardless. The
 databases that make the distinction will, and the ones that don't won't,
 but we'll have the right value coming out of this function regardless. It
 may also be something we don't actually want to check in other places
 either for the same reasons: Oracle collapses both values to NULL, other
 databases make a distinction.

 I'm happy to look for other places this check might happen though, and if
 adding a check to connection.features.interprets_empty_strings_as_nulls is
 actually necessary add that as well.

 Thanks!

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #16572: select_related doesn't work (silent/masked TypeError) over multiple one-to-one relationships

[Django]

#16572: select_related doesn't work (silent/masked TypeError) over multiple 
one-to-
one relationships
-+-
 Reporter:  rfrankel |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  select_related orm   |  Needs documentation:  0
  queryset   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 This seems to be fixed in the commits of #13781. The test in comment:13
 passed on sqlite for me, and charettes reports fixed for him too. On a
 quick look the tests of #13781 seems to cover this ticket's issue, so I
 will not commit the tests.

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

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

Re: [Django] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ungenio):

 * cc: david@… (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 https://groups.google.com/groups/opt_out.

Re: [Django] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

 In [changeset:"7cfb567e457379f52a80fe0e8d98dd8191391c6e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7cfb567e457379f52a80fe0e8d98dd8191391c6e"
 Another regression fix for select_related handling

 This time gis compiler.get_default_columns() wasn't up to date. Thanks
 to CI another regression fixed.

 Refs #13781
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 7cfb56: Another regression fix for select_related handling

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 7cfb567e457379f52a80fe0e8d98dd8191391c6e
  
https://github.com/django/django/commit/7cfb567e457379f52a80fe0e8d98dd8191391c6e
  Author: Anssi Kääriäinen 
  Date:   2012-11-15 (Thu, 15 Nov 2012)

  Changed paths:
M django/contrib/gis/db/models/sql/compiler.py

  Log Message:
  ---
  Another regression fix for select_related handling

This time gis compiler.get_default_columns() wasn't up to date. Thanks
to CI another regression fixed.

Refs #13781



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 Alright, didn't want to push you to backpatch, just wanted to know if you
 were planing to.

 Good work on those patches!

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * cc: charette.s@… (removed)


Comment:

 OK, I will see about adding the tests of #16572. I am planning of
 committing a couple more ORM fixes and then go through all the ORM tickets
 and close those which aren't relevant any more.

 I am not yet sure if I should backpatch this to 1.5. The problem is that
 the ORM is somewhat fragile due to all the different query combinations
 and thus I don't feel too comfortable about backpatching...

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * cc: charette.s@… (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 https://groups.google.com/groups/opt_out.

Re: [Django] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
---+
 Reporter:  jarrow |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+

Comment (by revolunet):

 Any update on @graveyboat patch ?
 Does it work as expected ?
 What happens when user click "save and continue" ? The referer is gone so
 we may need to keep the initial one from POST if specified ?

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:  akaariai
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 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 akaariai):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


Comment:

 Last call.

 Patch available from
 https://github.com/akaariai/django/compare/ticket_10790_final

 The patch is pretty big so I will do a full test suite run on all DBs
 during the night. Any reviews are welcome, and if more time is needed for
 a review please make a note and I will postpone the commit.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 FWIW f51e409a5fb34020e170494320a421503689aea0 also fixed #16572 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 https://groups.google.com/groups/opt_out.

Re: [Django] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 Is this going to be backported to 1.5?

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

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

Re: [Django] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 The commit above didn't contain some important lines in get_cached_row(),
 fixed in 1194a9699932088385f9f88869be28a251597f45.

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 1194a9: Fixed a regression in select_related

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1194a9699932088385f9f88869be28a251597f45
  
https://github.com/django/django/commit/1194a9699932088385f9f88869be28a251597f45
  Author: Anssi Kääriäinen 
  Date:   2012-11-15 (Thu, 15 Nov 2012)

  Changed paths:
M django/db/models/query.py

  Log Message:
  ---
  Fixed a regression in select_related

The regression was caused by the fix for #13781 (commit
f51e409a5fb34020e170494320a421503689aea0). Reason was leaving
off some crucial lines when resolving a merge conflict.



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18985: DeprecationWarning no longer loud by default in Python 2.7+

[Django]

#18985: DeprecationWarning no longer loud by default in Python 2.7+
--+
 Reporter:  dstufft   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 I don't think we should diverge from Python, no matter how we feel about
 that decision.

 IMO the reasonable course of action is to fix the docs and teach -Wd.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18347: Unit tests contain raw inserts to an identity column

[Django]

#18347: Unit tests contain raw inserts to an identity column
-+-
 Reporter:  manfre   |Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  identity |  checkin
  insert,mssql   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

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

 In [changeset:"a1fd9555f2cc32d10cdbc4aa71f86bac50ffd9c1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a1fd9555f2cc32d10cdbc4aa71f86bac50ffd9c1"
 [1.5.x] Fixed #18347 -- Removed autofield raw SQL inserts from tests

 Backpatch of 71e14cf3aa024496adcb23e83ddf13a7c5ddeb32
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] a1fd95: [1.5.x] Fixed #18347 -- Removed autofield raw SQL ...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: a1fd9555f2cc32d10cdbc4aa71f86bac50ffd9c1
  
https://github.com/django/django/commit/a1fd9555f2cc32d10cdbc4aa71f86bac50ffd9c1
  Author: Anssi Kääriäinen 
  Date:   2012-11-15 (Thu, 15 Nov 2012)

  Changed paths:
M tests/regressiontests/transactions_regress/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #18347 -- Removed autofield raw SQL inserts from tests

Backpatch of 71e14cf3aa024496adcb23e83ddf13a7c5ddeb32



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18347: Unit tests contain raw inserts to an identity column

[Django]

#18347: Unit tests contain raw inserts to an identity column
-+-
 Reporter:  manfre   |Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  identity |  checkin
  insert,mssql   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"71e14cf3aa024496adcb23e83ddf13a7c5ddeb32"]:
 {{{
 #!CommitTicketReference repository=""
 revision="71e14cf3aa024496adcb23e83ddf13a7c5ddeb32"
 Fixed #18347 -- Removed autofield raw SQL inserts from tests
 }}}

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

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

[django/django] 71e14c: Fixed #18347 -- Removed autofield raw SQL inserts ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 71e14cf3aa024496adcb23e83ddf13a7c5ddeb32
  
https://github.com/django/django/commit/71e14cf3aa024496adcb23e83ddf13a7c5ddeb32
  Author: Anssi Kääriäinen 
  Date:   2012-11-15 (Thu, 15 Nov 2012)

  Changed paths:
M tests/regressiontests/transactions_regress/tests.py

  Log Message:
  ---
  Fixed #18347 -- Removed autofield raw SQL inserts from tests



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #5726: inspectdb should recognize default values

[Django]

#5726: inspectdb should recognize default values
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  inspectdb|  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 [http://www.e-nofaxpaydayloans.com]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 https://groups.google.com/groups/opt_out.

Re: [Django] #5335: Add an append method to ErrorDict

[Django]

#5335: Add an append method to ErrorDict
-+-
 Reporter:  Thomas Güttler   |Owner:
   |  jkocherhans
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  append errodict  | 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):

 Check [http://www.google.com]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 https://groups.google.com/groups/opt_out.

Re: [Django] #13781: select_related and multiple inheritance

[Django]

#13781: select_related and multiple inheritance
-+-
 Reporter:  shauncutts   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"f51e409a5fb34020e170494320a421503689aea0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f51e409a5fb34020e170494320a421503689aea0"
 Fixed #13781 -- Improved select_related in inheritance situations

 The select_related code got confused when it needed to travel a
 reverse relation to a model which had different parent than the
 originally travelled relation.

 Thanks to Trac aliases shauncutts for report and ungenio for original
 patch (committed patch is somewhat modified version of that).
 }}}

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

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

[django/django] f51e40: Fixed #13781 -- Improved select_related in inherit...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f51e409a5fb34020e170494320a421503689aea0
  
https://github.com/django/django/commit/f51e409a5fb34020e170494320a421503689aea0
  Author: Anssi Kääriäinen 
  Date:   2012-11-15 (Thu, 15 Nov 2012)

  Changed paths:
M django/db/models/options.py
M django/db/models/query.py
M django/db/models/sql/compiler.py
M tests/regressiontests/select_related_onetoone/models.py
M tests/regressiontests/select_related_onetoone/tests.py

  Log Message:
  ---
  Fixed #13781 -- Improved select_related in inheritance situations

The select_related code got confused when it needed to travel a
reverse relation to a model which had different parent than the
originally travelled relation.

Thanks to Trac aliases shauncutts for report and ungenio for original
patch (committed patch is somewhat modified version of that).



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #10933: Avoid " TypeError: Cannot convert Decimal("0.0000") to Decimal " when the decimal module has been reloaded

[Django]

#10933: Avoid " TypeError: Cannot convert Decimal("0.") to Decimal  " when 
the
decimal module has been reloaded
-+-
 Reporter:  gagravarr|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  dceu2011 |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by jonaskoelker):

 
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Multiple_Python_Sub_Interpreters
 explicitly mentions decimal.Decimal in the context of psycopg2.  I'm
 experiencing this problem using sqlite3 as my database, so it's obviously
 not limited to PostgreSQL.  I think this explains why the
 workaround/solution in comment:15 works.  HTH :-)

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19296: LiveServerTestCase does not share connection to sqlite if using spatialite

[Django]

#19296: LiveServerTestCase does not share connection to sqlite if using 
spatialite
-+-
 Reporter:  pegler@… |Owner:  pegler
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite spatialite| Triage Stage:  Accepted
  LiveServerTestCase |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by pegler):

 * owner:  nobody => pegler


-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19301: Free Annual Credit Report

[Django]

#19301: Free Annual Credit Report
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:  Free Annual Credit Report
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 [http://freeannualcreditreport.bcz.com Free Annual Credit Report]

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

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

Re: [Django] #19058: Inserting NULL value in Oracle spatial backend causes crash.

[Django]

#19058: Inserting NULL value in Oracle spatial backend causes crash.
-+-
 Reporter:  jtiai|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  gis oracle orm   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

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

 In [changeset:"25e041f270bec5a69e525d47f18a73fe917d1787"]:
 {{{
 #!CommitTicketReference repository=""
 revision="25e041f270bec5a69e525d47f18a73fe917d1787"
 [1.4.x] Fixed #19058 -- Fixed Oracle GIS crash

 The problem is the same as in #10888 which was reintroduced when
 bulk_insert was added. Thanks to Jani Tiainen for report, patch and
 also testing the final patch on Oracle GIS.

 Backpatch of 92d7f541da8b59520c833b19fbba52d3ecef2428
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 25e041: [1.4.x] Fixed #19058 -- Fixed Oracle GIS crash

[GitHub]

  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: 25e041f270bec5a69e525d47f18a73fe917d1787
  
https://github.com/django/django/commit/25e041f270bec5a69e525d47f18a73fe917d1787
  Author: Anssi Kääriäinen 
  Date:   2012-11-15 (Thu, 15 Nov 2012)

  Changed paths:
M django/contrib/gis/db/backends/oracle/compiler.py
M django/contrib/gis/db/backends/oracle/operations.py
M django/db/backends/__init__.py
M django/db/models/sql/compiler.py

  Log Message:
  ---
  [1.4.x] Fixed #19058 -- Fixed Oracle GIS crash

The problem is the same as in #10888 which was reintroduced when
bulk_insert was added. Thanks to Jani Tiainen for report, patch and
also testing the final patch on Oracle GIS.

Backpatch of 92d7f541da8b59520c833b19fbba52d3ecef2428



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19058: Inserting NULL value in Oracle spatial backend causes crash.

[Django]

#19058: Inserting NULL value in Oracle spatial backend causes crash.
-+-
 Reporter:  jtiai|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  gis oracle orm   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

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

 In [changeset:"33f1181c31e0ee5bc5e20ca2a8549508de807623"]:
 {{{
 #!CommitTicketReference repository=""
 revision="33f1181c31e0ee5bc5e20ca2a8549508de807623"
 [1.5.x] Fixed #19058 -- Fixed Oracle GIS crash

 The problem is the same as in #10888 which was reintroduced when
 bulk_insert was added. Thanks to Jani Tiainen for report, patch and
 also testing the final patch on Oracle GIS.

 Backpatch of 92d7f541da8b59520c833b19fbba52d3ecef2428
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 33f118: [1.5.x] Fixed #19058 -- Fixed Oracle GIS crash

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 33f1181c31e0ee5bc5e20ca2a8549508de807623
  
https://github.com/django/django/commit/33f1181c31e0ee5bc5e20ca2a8549508de807623
  Author: Anssi Kääriäinen 
  Date:   2012-11-15 (Thu, 15 Nov 2012)

  Changed paths:
M django/contrib/gis/db/backends/oracle/compiler.py
M django/contrib/gis/db/backends/oracle/operations.py
M django/db/backends/__init__.py
M django/db/models/sql/compiler.py

  Log Message:
  ---
  [1.5.x] Fixed #19058 -- Fixed Oracle GIS crash

The problem is the same as in #10888 which was reintroduced when
bulk_insert was added. Thanks to Jani Tiainen for report, patch and
also testing the final patch on Oracle GIS.

Backpatch of 92d7f541da8b59520c833b19fbba52d3ecef2428



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19058: Inserting NULL value in Oracle spatial backend causes crash.

[Django]

#19058: Inserting NULL value in Oracle spatial backend causes crash.
-+-
 Reporter:  jtiai|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  gis oracle orm   |  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 [changeset:"92d7f541da8b59520c833b19fbba52d3ecef2428"]:
 {{{
 #!CommitTicketReference repository=""
 revision="92d7f541da8b59520c833b19fbba52d3ecef2428"
 Fixed #19058 -- Fixed Oracle GIS crash

 The problem is the same as in #10888 which was reintroduced when
 bulk_insert was added. Thanks to Jani Tiainen for report, patch and
 also testing the final patch on Oracle GIS.
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 92d7f5: Fixed #19058 -- Fixed Oracle GIS crash

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 92d7f541da8b59520c833b19fbba52d3ecef2428
  
https://github.com/django/django/commit/92d7f541da8b59520c833b19fbba52d3ecef2428
  Author: Anssi Kääriäinen 
  Date:   2012-11-15 (Thu, 15 Nov 2012)

  Changed paths:
M django/contrib/gis/db/backends/oracle/compiler.py
M django/contrib/gis/db/backends/oracle/operations.py
M django/db/backends/__init__.py
M django/db/models/sql/compiler.py

  Log Message:
  ---
  Fixed #19058 -- Fixed Oracle GIS crash

The problem is the same as in #10888 which was reintroduced when
bulk_insert was added. Thanks to Jani Tiainen for report, patch and
also testing the final patch on Oracle GIS.



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19299: Foreign keys using to_field and having legitimate empty string values fail with NULL errors

[Django]

#19299: Foreign keys using to_field and having legitimate empty string values 
fail
with NULL errors
-+-
 Reporter:  evan@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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 akaariai):

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


Comment:

 The problem is that Oracle does treat '' and None equivalently. And, this
 shows in some places of Django.

 The fix is likely incorrect as it doesn't check for
 connection.features.interprets_empty_strings_as_nulls.

 I am marking this as accepted. Haven't tested this but the description
 seems correct.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19300: capfirst filter breaks translation context in template

[Django]

#19300: capfirst filter breaks translation context in template
-+
 Reporter:  dyve |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.4
 Severity:  Normal   |   Keywords:  trans context capfirst
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Using the cap first filter breaks any context used in translation using
 the trans template tag.

 {% trans "species" context "singular" %}
 # works as expected, results in translation of 'species' with context
 'singular'

 {% trans "species"|capfirst %}
 # works as expected, results in translation of 'species' without context,
 capfirst applied

 {% trans "species"|capfirst context "singular" %}
 # BROKEN, results in translation of 'species' without context, capfirst
 applied

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19298: MultiValueField should override __deepcopy__

[Django]

#19298: MultiValueField should override __deepcopy__
-+
 Reporter:  nick.phillips@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19293: Update of czech date and time formats

[Django]

#19293: Update of czech date and time formats
---+--
 Reporter:  vzima  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Translations   |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tuttle):

 We're discussing it in the mailing list. Thank you.

 Vlada Macek

-- 
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 https://groups.google.com/groups/opt_out.