#5361: Support pluggable backends for FileField
------------------------------------------------------------+---------------
Reporter: Marty Alchin <[EMAIL PROTECTED]> | Owner:
Gulopine
Status: new | Milestone:
1.0 beta
Component: Database wrapper | Version:
SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
------------------------------------------------------------+---------------
Comment (by Gulopine):
It's always good to get feedback from people who are doing some more
interesting things with files, it helps narrow down what we're trying to
do.
I had considered something like modtime(), but I was waiting for anyone to
actually ask for it before I bothered with anything. With the current
patch, it's possible to override what `File` object gets used to represent
your files, so it's easy to add a `modtime()` method to it. You can also
override storage systems, so you can add it there too, if you need the
exact behavior you described above. I'd like to leave it as that for now,
and if enough people express displeasure with that, I'll consider it
adding to the rest, but it just doesn't seem like it'd serve enough
people. Then again, it's easy to add, so I'll consider it.
I'll definitely chalk up `delete_by_prefix()` as something you can achieve
by subclassing your favorite storage system and adding a method. I can see
you guys are making good use of it, and you'll be able to quite easily,
but I don't think there's much of a case to be made for having it in core.
I can see value in `list_dir()` for some types of applications, but on the
whole, I think it's outside what file storage is trying to do. If,
however, somebody makes a case for making `FilePathField` aware of storage
systems (nobody's said anything about it yet), then some sort of directory
listing will be absolutely necessary.
I'm willing to entertain the idea of `copy()`, mainly because different
backends will have different (more efficient) ways of handling that than
just opening one file and writing another. S3, for instance, would require
transferring the file over the wire, just to send it back with a different
name, except that it has a separate copy command. I'm not sold on its
usefulness for everybody yet, but there's definitely potential there. I'll
think it over.
--
Ticket URL: <http://code.djangoproject.com/ticket/5361#comment:67>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" 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-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
