Re: Model.objects.raw() (#11863)
On Oct 2, 7:35 pm, mrts wrote: > But let me stop right here. Contradicting myself, I've pursued this further and implemented raw_override() for order_by in [1] as a proof of concept. See [2] for what's different and tests [3] for usage. I'd say that for order_by, the implementation is simple and straightforward and not that much more fragile than extra() (see tests for the second model in [3] for a complex-ish example). As for the usefulness, complex ordering can probably be solved with existing extra() by SELECTing the complex order criteria, aliasing them and using that alias in order_by. But perhaps someone likes or needs the idea and wants to take it further for other parts of the query. Once again, over and out on this matter, Mart Sõmermaa [1] branch: http://github.com/mrts/django/tree/raw_sql_override [2] diff: http://github.com/mrts/django/commit/dd127debfed070bb8152f10cb5770b216baee3de [3] tests: http://github.com/mrts/django/blob/raw_sql_override/tests/modeltests/raw_override/models.py --~--~-~--~~~---~--~~ 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)
On Fri, Oct 2, 2009 at 9:37 AM, Russell Keith-Magee wrote: > Django's ORM is designed to make the simple cases really simple, but > once you move beyond the basics, you really should be looking to use > raw SQL. Indeed. I look at raw() really as "I know *exactly* the query I want to run, get the ORM out of my way and just make it easy to get objects". -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Branchy Django developement on GitHub
Many core developers and the GSOC folks use GitHub for Django development, so I hope discussing the best practices is appropriate for django-dev. Let me outline the desired workflow, please amend and correct as you see fit as there are probably errors or omissions. I expect various useful patterns and workarounds for problems have emerged which could be shared with the larger community. I'll create a proper guide in the wiki once feedback has been collected. Assumptions --- You want to work on several fixes and features (tasks) and * keep the changes for a particular task selt-contained in a branch, * frequently update the codebase with upstream changes, * have a has-it-all branch for testing out how the different task branches interact. You have created a fork of django/django on GitHub, `git clone`d the work to local machine, added the upstream repository with `git remote add upstream`. Working on a task - Goal: keep the changes self-contained, create and update patches suitable for attaching to tickets in Django trac. # branch from master $ git checkout -b ticket1234 master $ ... change files, commit often ... $ ... run tests ... # create the remote branch and push changes into it $ git push origin ticket1234 # create a patch, attach it to a relevant ticket in trac $ git diff master > ticket1234.patch After upstream has changed -- Goal: bring in the changes in upstream to a task. # pull in upstream changes $ git pull upstream master $ git checkout ticket1234 # merge, fix any conflicts $ git merge master # push changes to GitHub, remote branch assumed to exist $ git push # update the patch $ git diff master > ticket1234.patch Testing everything in the has-it-all branch --- Goal: a place to try out the code from all tasks together. 'master' can not be used for this as it is used for tracking upstream. This is a temporary branch that can be removed after testing is done. $ git checkout -b has-it-all master $ git merge ticket1234 $ git merge ticket1235 $ ... run tests ... # delete the branch $ git checkout master $ git branch -d has-it-all This is just a (untested) skeleton. All help in improving it, adding caveats and tricks most welcome. Best, Mart Sõmermaa --~--~-~--~~~---~--~~ 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: Branchy Django developement on GitHub
Thanks for putting this together - that's a really useful summary of commands. Any chance you could save it on the wiki somewhere? Cheers, Simon --~--~-~--~~~---~--~~ 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: Branchy Django developement on GitHub
There's http://code.djangoproject.com/wiki/CollaborateOnGithub that I wrote some time ago, but it doesn't give guidelines for branchy development. I will update that page with these instructions, but it would be excellent if others who have collaborated more intensively via GitHub could amend the text if needed. Best, MS On Oct 5, 6:46 pm, Simon Willison wrote: > Thanks for putting this together - that's a really useful summary of > commands. Any chance you could save it on the wiki somewhere? > > Cheers, > > Simon --~--~-~--~~~---~--~~ 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: Adding signing (and signed cookies) to Django core
On Sep 24, 10:18 am, Simon Willison wrote: > This offers two APIs: sign/unsign and dumps/loads. sign and unsign > generate and append signatures to bytestrings and confirm that they > have not been tampered with. dumps and loads can be used to create > signed pickles of arbitrary Python objects. Unpickling data sent by the client seems dangerous, since it can execute arbitrary code on the server [1]. Obviously signing the data goes a long way toward preventing such attacks, but I'm still not comfortable with the idea that a leaked signing key could instantly be escalated to arbitrary code execution. (For example, if the config files are exposed through a misconfigured web server or accidentally checked into public source control.) If you use JSON or some other object serialization by default, then the damage from a leaked secret key would be much more limited in most cases. 1. http://nadiana.com/python-pickle-insecure#HowtoMakeUnpicklingSafer --~--~-~--~~~---~--~~ 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: contrib.admindocs need some love.
On Thu, Aug 27, 2009 at 2:03 PM, Justin Lilly wrote: > Hey guys. > > I started writing some docs for another developer today and hit a few > issues with admindocs that I plan on sprinting on for DjangoCon. I'm > hoping anyone else with complaints / ideas will voice up, though my main > impetus for the post is to announce that I'm going to do it so I > can't back out. ;) > > Things I plan to address: > > 1. No tests. > 2. No docs. > 3. You can't seem to cross-link to views without the link being > app.package.func . I'd like to see it at least configurable. > 4. ManyToManyFields don't show up. > > There's not a ton there, but worth sprinting on, imo. Any other ideas or > changes you'd like to see in admindocs that I might be able to work on? > Shout them out. > It may be out of your scope, but admindocs flat-out breaks with GIS fields. http://code.djangoproject.com/ticket/7977 -- Pete --~--~-~--~~~---~--~~ 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: contrib.admindocs need some love.
I have an icky patch for this. On Oct 5, 2009, at 2:07 PM, Peter Baumgartner wrote: > > On Thu, Aug 27, 2009 at 2:03 PM, Justin Lilly > wrote: >> Hey guys. >> >> I started writing some docs for another developer today and hit a >> few >> issues with admindocs that I plan on sprinting on for DjangoCon. I'm >> hoping anyone else with complaints / ideas will voice up, though my >> main >> impetus for the post is to announce that I'm going to do it so I >> can't back out. ;) >> >> Things I plan to address: >> >> 1. No tests. >> 2. No docs. >> 3. You can't seem to cross-link to views without the link being >> app.package.func . I'd like to see it at least configurable. >> 4. ManyToManyFields don't show up. >> >> There's not a ton there, but worth sprinting on, imo. Any other >> ideas or >> changes you'd like to see in admindocs that I might be able to work >> on? >> Shout them out. >> > > It may be out of your scope, but admindocs flat-out breaks with GIS > fields. http://code.djangoproject.com/ticket/7977 > > -- Pete > > > --~--~-~--~~~---~--~~ 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: contrib.admindocs need some love.
On Mon, Oct 5, 2009 at 2:18 PM, Jeremy Dunck wrote: > I have an icky patch for this. To be clearer, this is a general problem with admindocs-- it has a mapping, DATA_TYPE_MAPPING, and assumes any model field's .get_internal_type() will be in that dictionary. I can think of a couple ways to address this: 1) Have each app which ships custom fields check to see if INSTALLED_APPS includes admindocs, and if so, update DATA_TYPE_MAPPING. 2) Have admindocs check for a new API, Field.get_readable_data_type(), falling back to DATA_TYPE_MAPPING, and finally to the result of .get_internal_type(). The attached patch does the first approach for GIS (applied against django trunk 11125). I think the second approach is better, but doesn't fix your problem immediately. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- gis-admindocs.diff Description: Binary data
Re: Adding signing (and signed cookies) to Django core
On Oct 5, 6:33 pm, Matt Brubeck wrote: > On Sep 24, 10:18 am, Simon Willison wrote: > > This offers two APIs: sign/unsign and dumps/loads. sign and unsign > > generate and append signatures to bytestrings and confirm that they > > have not been tampered with. dumps and loads can be used to create > > signed pickles of arbitrary Python objects. > > Unpickling data sent by the client seems dangerous, since it can > execute arbitrary code on the server [1]. Obviously signing the data > goes a long way toward preventing such attacks, but I'm still not > comfortable with the idea that a leaked signing key could instantly be > escalated to arbitrary code execution. (For example, if the config > files are exposed through a misconfigured web server or accidentally > checked into public source control.) If you use JSON or some other > object serialization by default, then the damage from a leaked secret > key would be much more limited in most cases. You know what, I have to admit I hadn't really thought about JSON as an alternative. Obviously I knew that unpickling was unsafe - that's one of the reasons I'm so keen on signing - but it really doesn't make sense to expose this kind of risk if it's not necessary. The pickling trick is cute, but is the convenience of being able to pass any pickle- able object around really worth the risk? I don't think it is - I think I'll ditch the dumps/loads signed pickle methods in favour for similar functionality that uses JSON instead. Other than dates being a bit more annoying to pass around, I really don't think that telling people they can only dumps/loads JSON-encodable data would be a huge burden. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
How to interpret the performance difference: Tornado vs Django
I read this doc about the performance comparison between Tornado and Django: http://www.tornadoweb.org/documentation I am quite new to both django and tornado (just heard about it). To me there are a few confusing points about the conclusion that "Tornado consistently had 4X the throughput of the next fastest framework, and even a single standalone Tornado frontend got 33% more throughput even though it only used one of the four cores" Maybe the document could add more comments about how the experiment is setup. The context of this statement is that Tornado runs with 4 frontends on a 4 core machine. My question is "Could django apps take advantage of 4 cores?" Is the 4X performance difference due to the setup or is it due to the reason that Tornado could make a better use of a 4 core machine? Any thoughts? Thanks. --~--~-~--~~~---~--~~ 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: How to interpret the performance difference: Tornado vs Django
On Tuesday 06 Oct 2009 10:46:44 am ihomest...@gmail.com wrote: > I read this doc about the performance comparison between Tornado and > Django: http://www.tornadoweb.org/documentation comparison between django and tornado? django is a web framework. Tornado is a web server. Whats to compare? one compares platforms for running django. like: apache + mod_python - sucks apache + mod_wsgi - rocks nginx + tornado - rocks big time with nginx handling the media and tornado handling django. -- regards kg http://lawgon.livejournal.com --~--~-~--~~~---~--~~ 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: How to interpret the performance difference: Tornado vs Django
On Oct 6, 4:16 pm, "ihomest...@gmail.com" wrote: > I read this doc about the performance comparison between Tornado and > Django:http://www.tornadoweb.org/documentation > > I am quite new to both django and tornado (just heard about it). To me > there are a few confusing points about the conclusion that "Tornado > consistently had 4X the throughput of the next fastest framework, and > even a single standalone Tornado frontend got 33% more throughput even > though it only used one of the four cores" Maybe the document could > add more comments about how the experiment is setup. > > The context of this statement is that Tornado runs with 4 frontends on > a 4 core machine. My question is "Could django apps take advantage of > 4 cores?" Is the 4X performance difference due to the setup or is it > due to the reason that Tornado could make a better use of a 4 core > machine? > > Any thoughts? Like so many before them they chose benchmarks results which cast their product/project in a good light. Reality is that it wasn't a fair comparison. The proper comparison would have been to demonstrate a simple WSGI hello world application on both Tornado and Apache/mod_wsgi. If a WSGI application on Tornado is too hard for them, sure they can stick with their own hello world application. Point is though, they should not have been comparing their hello world on their base level infrastructure to something where a heavy weight framework is used. Alternatively they should have demonstrated Django running on both, although I don't know I would trust them to be able to configure Apache/mod_wsgi properly so it runs to its best and to eliminate application loading issues. At least with a WSGI hello world they couldn't have done too much wrong. FWIW, on MacOS X, if you run Tornado with their hello world application and compare it with a hello world WSGI application running on Apache/mod_wsgi and run a straight sequential request test to gauge base performance overheads, then Apache/mod_wsgi performs up to 20% better than Tornado. Granted that on MacOS X Tornado may not be using epoll(), but I wouldn't see it making that much difference. Overall it is just a big pissing contest anyway. The base level web server infrastructure is not where the performance bottlenecks are. It is going to be the application logic and more specifically database interaction. Just because the underlying web server use an asynchronous model will not somehow magically make a real world blocking web application somehow magically run 4 times quicker. So, one could use the old phrase, lies, lies and benchmarks (statistics). Problem is there slanted benchmarks have been propagated around the place by people who know no better and they even stuck them on Wikipedia as well. It will be impossible to get rid of it now or balance the argument. As final point, I would just say you use whatever you feel comfortable with and which you find easy to manage and configure. That is more important ultimately in production environments. If however it makes you feel good to think what you are using the fastest web server available, then by all means use web servers that want to claim that as well. Graham --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
