Would it not be **massively** more efficient for everyone if you contributed patches back to Django itself, rather than tell people how to work around its deficiencies? For example, in getting Django the ability to use named cursors with pyscopg2?
Or at least some documentation patches? We've got a dedicated section on database access optimization, and we've get several core committers dedicated to documentation.
Please do not treat Django as something 'out there' - if you are a user, then you are stakeholder.
Xof
· 8 October 2011
I'm not sure I can completely agree that the choices are one or the other. Many people have to use Django-as-it-is, right now, and thus the advice on how to deal with its current codebase is useful, even if that advice may well become obsolete in the future.
In most cases, the points I raise aren't failings in Django, but misapprehensions about how to best use its features. In other cases, such as the transaction API, it would be tricky to clean it up without breaking backwards compatibility.
I am in fact working on a patch for the named cursors issue, but it's not super-simple, since the naive implementation introduces overhead into all operations, which isn't very desirable.
But, of course, yes, by all means, nothing I write here should be considered a discouragement from contributing to Django!
Comments
John DeRosa · 26 July 2011
Why, I think I know the source of slide 71.Slawomir · 27 July 2011
very nice and deep presentation, it was pleasure to read, good work!John DeRosa · 27 July 2011
Oops, I mean slide 67. Hmm, did you update the file?Xof · 27 July 2011
Nope, no changes to the slides. The IN problem is pretty much universal across Django applications; don't take it too personally. :)Ben Finney · 16 August 2011
Is the audio for the presentation online for download? It would be really helpful to hear what you were talking about at some of the slides.Kevin Bowling · 21 September 2011
I think you just saved me a year of heartache and despair. This really needs to be the first documentation entry on the Django website.Rolo · 21 September 2011
Really interesting. Particularly the bits about the ORM internals and postgres table modifying. Cheers.Luke Plant · 8 October 2011
Would it not be **massively** more efficient for everyone if you contributed patches back to Django itself, rather than tell people how to work around its deficiencies? For example, in getting Django the ability to use named cursors with pyscopg2? Or at least some documentation patches? We've got a dedicated section on database access optimization, and we've get several core committers dedicated to documentation. Please do not treat Django as something 'out there' - if you are a user, then you are stakeholder.Xof · 8 October 2011
I'm not sure I can completely agree that the choices are one or the other. Many people have to use Django-as-it-is, right now, and thus the advice on how to deal with its current codebase is useful, even if that advice may well become obsolete in the future. In most cases, the points I raise aren't failings in Django, but misapprehensions about how to best use its features. In other cases, such as the transaction API, it would be tricky to clean it up without breaking backwards compatibility. I am in fact working on a patch for the named cursors issue, but it's not super-simple, since the naive implementation introduces overhead into all operations, which isn't very desirable. But, of course, yes, by all means, nothing I write here should be considered a discouragement from contributing to Django!Carlos Aguilar · 15 November 2012
Hi, I want know if exists video or audio. In some parts of your slides I not understand with the context of your talk. Best RegardsXof · 17 November 2012
It was recorded at PyCon Argentina, and I'll post the link to it when I have it!