On 10/23/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Currently, get_filename uses os.path.basename, and after filestorage > > goes in, get_available_filename will do the same. This means that any > > directory information is lost, unless it's preserved separately. It's > > possible, but will take a bit of doing. > > I don't understand this paragraph. Currently, if you use upload_to, we > store the full upload_to prefix + the filename (with the implicit > assumption that it's all appended to MEDIA_ROOT), both in the database > field and in the model attribute. Why wouldn't you do the same -- store > the full relative path -- in the new world? What am I missing.
Well, that was probably an unnecessary point, really. That was a drawback in the proof-of-concept implementation I threw together last night, because I was just replacing the original filename with a model-based one. That filename would then be appended to the upload_to argument before being stored in the database. But os.path.basename was dropping the subdirectory portion of the filename, so '/songs/2007/Test_song.mp3' was being stored as '/songs/Test_song.mp3'. Like I said though, doing it right is possible, it just needs more work than I put into it last night. So ignore that point. > Unless you allow subdirectory support, I doubt it's worth adding much > customisation here, since it's not going to be too useful. My impression > has been that allowing customisation inside a Model.save() override is > the real wish -- so rather than having to specify upload_to (or filename > in your case) up-front, it can be changed a bit more dynamically just > prior to saving. Quite true. Unfortunately, the filestorage patch will actually complicate the case of FileField saving even more than it already is, by shifting the actual saving into a completely separate package. Right now, it's possible to override either _save_FIELD_file() or its curried counterpart to customize things a bit more. With filestorage in place (as it stands now), it would require subclassing FileField as well as the new File class, just to be able to override save_file() for the necessary effect. A simple change to how FileField figures out which File class it uses would remove the necessity to subclass FileField, but there's still the matter of having to import and subclass the File class to do this, and those are guts I'd rather leave inside, except for cases where those kinds of customizations are really necessary, such as adding new file types. All in all, I guess I'm torn. Some kind of filename/subdirectory format string avoids numerous questions on how to subclass File or ImageFile just to use a user id as a subdirectory. But filestorage's save_file() is much smaller than _save_FIELD_file(), and so overriding it might not be that terrible, I suppose, and it would save code on our end, and make it more flexible. Adding in an optional 'subdirectory' argument would make overriding it even easier. Well, I'll think about it some more and see if I can work up a reasonable solution to it. I won't add it to the existing filestorage patch though, that's already handling enough. -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
