On Sat, 2006-08-05 at 22:07 -0400, Todd O'Bryan wrote: > 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.)
I only brought this up so that you could focus you discussion on the new bits you are developing (a new storage method, not new access controls). The drawbacks and advantages of files through views are largely the same, whether the files are in the database or on the filesystem, although obviously there are some subtleties and differences in each case, such as binary field size limits. That is all I was trying to say. Keeping focused on the main point of your addition will make it easier for everybody to follow the details. :-) [...] > Isn't *Django* supposed to be a CMS? :-) No. You could build a CMS with Django (e.g. Ellington), though. [...] > 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? So far there hasn't been a really strong proposal to include one. The size limitation with MySQL, for example, is very real. The need to escape the data on the way in is an issue -- we need to ensure all the backends do this properly. For example, although PostgreSQL can store nuls in its bytea fields, you still need to octal-escape them on input. That is something the forthcoming tests for ticket #2417 will need to include. Including a binary field type is not in any way ruled out -- in fact, as you can see from #2417, it's considered promising. It just hasn't been included yet. I would like to see somebody put some effort into completing the necessary parts of #2417 so that we can commit it and then people like you can start building filestorage methods or whatever they like on top of it. It feels a little cart-before-the-horse at the moment, since you're talking about an app that uses the binary field before we even have a binary field to use. Best wishes, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
