> One query for each model > containing one or more FileFields is enough to build a list of the files > that ought to exist, and any file not in that list can presumably be > removed.
How can I sleep at night knowing that there is a maintenance cron job deleting files which can be "presumably be removed"? My point is that yes it great that you have removed a data loss from FileField, but you have moved all the complexity to the developers and they will end up having even bigger data loss. Assuming that the purpose of improving django is to make it safer and easier to be used this "improvement" is a double bladed knife. Correct me if I am wrong: - Subclassing FileField will restore the previous issue. - A post delete signal will restore the previous issue. Having a maintenance job deleting file not listed will require a serious maintenance. Suppose a developer adding a file field and forgetting to update the maintenance script will cause all the file of that field to be deleted. Files which for a bad design are in the same folder as the file pointed by the file field will be removed. Thumbnails and other files eventually not pointed by a file field will be removed. And there will be more serious failures depending from the implementation. What I am trying to say is that removing orphaned files, even if with a cron job, should be done by django automatically and not assuming that the developers will take care of that. Said so I will start implementing such a maintenance job, and I am willing to share it so maybe we could include it in a future release of django. -- 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.
