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
·
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 ·
Why, I think I know the source of slide 71.Slawomir ·
very nice and deep presentation, it was pleasure to read, good work!John DeRosa ·
Oops, I mean slide 67. Hmm, did you update the file?Xof ·
Nope, no changes to the slides. The IN problem is pretty much universal across Django applications; don't take it too personally. :)Ben Finney ·
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 ·
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 ·
Really interesting. Particularly the bits about the ORM internals and postgres table modifying. Cheers.Luke Plant ·
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 ·
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 ·
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 ·
It was recorded at PyCon Argentina, and I'll post the link to it when I have it!