Re: Proposal for 1.2: built-in logging with django.core.log
+1 on the logging proposal. The stock python logging module is definitely a bit of a finicky and confusing creature, especially for people coming to Python for the first time with Django. -0 On the signals based approach. I would be wary of the potential performance overhead of replacing logging with signals and/or implement logging in certain high traffic areas with signals. It would definitely be interesting to see some proof of concept performance tests (i.e. what Simon did with the handlerless logging) before going too far down that path. -Sean O'Connor On Sep 17, 1:40 pm, Eric Florenzano wrote: > On Sep 17, 1:25 am, Simon Willison wrote: > > > 1. We'll be able to de-emphasise the current default "e-mail all > > errors to someone" behaviour, which doesn't scale at all well. > > I'm a big fan of this proposal, for exactly this reason. > > +1 > > Thanks, > Eric Florenzano --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
Another fun wrinkle to think about in this discussion is third-party
apps. Currently there are numerous useful apps out there which you
can't really use if you want to have HTML(5) output because they have
XHTML output hard-coded. The developers of these apps haven't done a
"bad" thing here, they simply mirrored Django's own behavior.
As an interim solution I've forked django-html (http://github.com/
SeanOC/django-html) and added a middleware which does the XHTML=>HTML
string replacement. This is obviously a fairly messy approach but it
is the only way I've figured out to work with third party apps without
maintaining HTML compatible forks of everything.
To address this problem the "right" way, I'd suggest that in addition
to fixing Django's own HTML output to respect a {% doctype %} tag, we
should also provide tools to make it easy for developers to respect
that tag. I'm not sure what form those tools should take right now
but it's definitely something that should be consider as part of the
solution to this problem.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Model.objects.raw() (#11863)
Hello All, During the Djangocon sprints I started to work on a patch which would add a nicer interface for dealing with raw SQL queries. While there I talked to RKM about where it should fit into the ORM API and where in the code base should live. I've finally gotten around to finishing the code I wrote during the sprint and have posted a patch to the related ticket (http://code.djangoproject.com/ticket/11863). You can also get the code from http://github.com/SeanOC/django. So far the patch is functional and has some basic unit tests but it is not documented. I'll be working on the documentation this week. In the mean time, the unit tests are probably the best place too look for how to use the code. If anybody would like to look over the code and provide some feedback it would be greatly appreciated. Thanks! -SeanOC --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model.objects.raw() (#11863)
> The first is that I'd like it to be compatible with deferred loading > of model attributes - I haven't looked in to it, but my hunch is that > this won't be too hard (it might even work in its present form without > any further changes). The current implementation doesn't support this. It will actually raise an exception if not all of the fields have been provided. For now I was looking to get something basic out there to get the ball rolling. Once I have the docs for the current implementation done I'll look into what it will take to do this. > > The second one is probably a lot harder - it feels to me like this > feature would be much more useful if it could perform select_related > style graph population. One of the key use-cases for raw SQL is > improving performance - writing queries which perform better than the > ORM (SQL optimisations, or queries that hit an alternative view or use > a stored procedure or similar). It's very plausible that a developer > might want to write a custom query that populates a full graph of > objects, just like select_related() does. It would be really useful if > the QuerySet.raw() method let them do that. > > I haven't looked at how much work it would be to support graph > population - it will certainly complicate the user-facing API, and it > might require a bunch of work at the ORM level. If it's just too much > hassle I think the feature would be worth including without it, but > it's certainly worth some further investigation. > This one also isn't implemented right now. I've had a few thoughts on how it could be done but they all result in a somewhat ugly API. The least ugly option I've thought of so far would be to accept an optional parameter called related_available which would expect a tuple of tuples. The inner tuple(s) would include a prefix for the columns with related data and the name of the related field. I definitely would be interested in hearing other suggestions. -Sean --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model.objects.raw() (#11863)
I've posted a new patch to the ticket (http://code.djangoproject.com/ ticket/11863) and have pushed my latest code to http://github.com/SeanOC/django/tree/ticket11863. All of the issues which Jacob raised should now be resolved and an initial version of caching the query results has been implemented. The main remaining task is to write some documentation. Hopefully I should have a first pass at having that complete this weekend. Any feedback or comments would be great. Thanks! -Sean -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
