I'm short on time right now so I just want to respond to one part of this that I just noticed and I'll come back later to digest the rest. Thanks for the background on the why to r9766. I knew it was model-validation related but didn't know what the specific issue was. It helps to have a clearer idea of the actual problem it's trying to solve.
Now the additional wrinkle I just noticed: On Thu, Apr 2, 2009 at 12:33 PM, Marty Alchin <gulop...@gmail.com> wrote: > As for addressing this one in particular, I think we'll have to add > something similar to the _committed flag, so we can identify whether > the filename has been processed or not. If it has, return it; > otherwise, generate it using upload_to when it's requested. The > trouble with just moving it up into save_form_data() is that if > someone assigns a file manually, save_form_data() won't get the chance > to generate a proper filename and we'll have a separate issue on our > hands. I hate having to add all these flags to determine what part of > the process we're in, but at a glance, that seems the most reasonable > approach. > Upon further investigation, I think it's going to be pretty hard to disentangle setting the right file name from the actual save. While the adding in of the upload_path part can be done whenever, the possible underscore additions are done, I now see, as part of save. There's actually a loop in _save() that deals with multiple threads possibly picking the same name and colliding on save -- if it turns out the tentatively assigned name is already in use, get_available_name() is called again (adding at least one more underscore) to generate the next available name: http://code.djangoproject.com/browser/django/trunk/django/core/files/storage.py#L150 Thus, as it is right now, the actual file name on disk isn't going to be really known for sure until the file is saved. I need to head out the door in a few minutes and don't at the moment have any good idea for how to deal with this. "Reserving" the name by actually creating the file on disk before save I think just puts things back to where they were pre-r9766: you'd wind up with possibly something (maybe just an empty file) saved on disk when in the end ultimately the model containing the file field was not saved, unless we do something clever to un-do the "reservation" at some (what?) point. Ugh. Maybe there's a better way I'm overlooking? Finally one thought I'll throw out there -- since r9766 was needed for model validation, and that's not now going to be in 1.1, does r9766 need to stay in 1.1? Personally I'd prefer to solve the issues now if it's going to be needed for model validation anyway in the future...but if it comes down to the wire and we don't have good answers for some of these side-effects, could we just un-do r9766? Karen --~--~---------~--~----~------------~-------~--~----~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
