I'm with you, if not on 100% of what you said, at least 95% of it :) > That said, if throwing directory deleting out > is the thing that's required to get the patch in, I won't object ;)
I just foresee that if there is heavy hesitation on even deleting files, deleting directories might be too liberal a feature for the kind of position that the framework takes. I don't doubt that directory deletion has its use, and that it's safe when used properly. I think that the primary committors (of which I am most certainly not) would not think that it was a critical piece of the framework. So that being said, I'm just folding on that one without any argument > It never occurred to me that we would not a least want the option to > delete the file from disk. I would guess that in 95% of projects > people have exactly one FileField in charge of a particular file. And that's where this patch has an excellent point. Like I kicked things off by saying, letting Django help out and delete a file is hardly different than me hacking in a blind file deletion and 'pass'ing on the exception. I don't think that anybody can argue that there shouldn't at least be the checkbox for "clear this field", even if the file *isn't* deleted. But, without the ability to actually remove the file, I'm unsure that we can say that the FileField and its derivatives are doing 100% of the job that I'm sure a lot of us expect it to do. For the sake of bringing the real-world use case into the picture, I've got an admin change form which has a few FileFields for various uses, such as cover letter documents, email lists, etc. I discard the original file name in favor of something streamlined, like "email_list.csv". Pretty reasonable. But even the smartest system admin sitting next to me can't do anything about the utterly useless duplicate files that pile up on the remote server, without some SSH credentials. So, where the core developers and decision makers might hesitate to delete a file that I declare useless, this patch would instead pick up the slack. The files left behind are 100% useless if I say so. Consider me using a hosted solution, where I can't be bothered with logging in each week and clearing abandoned files out of a folder. The typical "set up a cron job" (or similar) approach doesn't work in every case. > This was classified as > "Small/just bugs" when deciding on features for 1.1 by the way [2]. If that's the case, then that's find it it waits until bugfix phase. I had thought it to be a feature addition, but I'll adjust my understanding accordingly! I hope that a patch which has predated version 1.0 can at last get a decision made. I'm of course bias toward it being implemented very nearly as-is, but a decision is at least a decision. *peacefully waiting for bugfix phase* Tim On Nov 23, 9:41 pm, Jonas Pfeil <[email protected]> wrote: > > It has a kind of goofy option for deleting > > empty directories when removing a file leaves said directory empty. > > Hey, it's not goofy. It's handy ;) I also took _great_ care when > writing the code for directory deletion and it's happily deleting > directories on our production server since a year or so. And it's of > course off by default. That said, if throwing directory deleting out > is the thing that's required to get the patch in, I won't object ;) > > > The patch is marked as "Accepted", but there's some discussion on the > > comments about "deleting files" not being within the scope of what the > > patch should do. I think the intended suggestion is that the patch > > should clear the DB field pointing to the file, yet not remove the > > file itself. > > Originally I wrote the patch for 1.0 starting with code that Brian > gave me. As can be seen from his comment the change was a bit too big > to get in at the last minute. > > It never occurred to me that we would not a least want the option to > delete the file from disk. I would guess that in 95% of projects > people have exactly one FileField in charge of a particular file. But > I can see how deleting files by default is potentially dangerous for a > framework. > > In the current patch just changing the default behavior to not delete > files creates a lot of work for the probably 95% of people who want to > delete the file form disk. I personally would find an option in the > settings file most convenient. Adding an option to the model field > that let's me say "yep, this field has permission to physically delete > it's file" would also be OK. > > > So once again, in summary, I'd like to petition for something of a > > conclusive decision about file deletion, this time on the above-noted > > patch. The ticket comments mention that it would be too late for > > introducing a feature like that into the development cycle, but that > > looks like it was from the 1.1 days. I don't want something like this > > to slip beyond the end of December, and then have it ignored until a > > 1.3-ish release. > > +1 to that ;) Although as Russell pointed out here [1] we are in > feature development phase and as long as this really get's looked at > in the bug fixing phase I won't say anything ;) This was classified as > "Small/just bugs" when deciding on features for 1.1 by the way [2]. > > Cheers, > > Jonas > > [1]http://groups.google.com/group/django-developers/browse_thread/thread... > [2]http://code.djangoproject.com/wiki/Version1.1Features -- 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?hl=en.
