On Aug 5, 2006, at 8:12 PM, Malcolm Tredinnick wrote: >> Yes, this will be slower than having Apache serve the file directly, >> but it has the huge advantage that the file is served as the result >> of a view. That means you can do all kinds of interesting permission >> checking, url mapping, and general futzing around internal to Django, >> without having to interact with whichever web server you're using. > > I'm not a big fan of this idea, so I'm not going to address the > details > (although it does make me think that we need a documented way of > extending fields so that people can do this without needing to dive > into > the core and so that this stuff can be shipped independently of > Django). > However, this paragraph needs correcting. You can *already* serve > files > through views and take advantage of Django's permissions system. The > HTTP interfaces can take iterables as their source for output, so a > well-designed wsgi server should have no real memory problems with a > well-designed iterator. Or if somebody wants to store their static > files > on another system entirely, you can do that with redirects (which > could > be internal) and views and custom header (with encrypted token) as > well. > > The only thing we can't do internally at the moment is do direct > filehandle passing or anything like that.
Right. It is all possible, but it involves reading in a file from the filesystem and re-outputting it through Django. Even though that's the supposed reason that you should use the real filesystem--because Django's ill-suited to serving files and it's better to use Apache for that kind of stuff. (At least that's what the documentation says.) And I agree with the sentiment, but when there are use cases that require fine grained control over access to binary data, I find myself wishing that it were at least possible to use the wonderful database API that's built into Django to make it easier. I gave the case of controlling permissions on user files that are uploaded. The responses ranged from "Apache is not a CMS" to "store the file somewhere inaccessible and then move it somewhere accessible when you need to serve it." Isn't *Django* supposed to be a CMS? :-) Another guy said that he needed transactional control on his binaries, and asked for a link to where the issues of why Django doesn't support binary database fields were discussed: http://groups.google.com/group/django-developers/browse_thread/thread/ 4ed4ca102062f8be/3c2193a8774c1455?lnk=gst&q=blob&rnum=2#3c2193a8774c1455 As of now, his question is unanswered. So, if you have to run files through the system anyway, what are the reasons people don't want BLOB/bytea fields in the database? Todd --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
