I'm a little confused by the track the discussion took recently... my impression was that the solution would *not* be to change from last_modified to a checksum, or to add an additional checksum method. Instead, storage backeds could support a has_changed method, which could be overridden to provide last_modified checking *or* checksum comparisons - or any other method of checking whether a file has changed. This seems like a useful, easy-to-explain, very generic way to handle checking whether a file has changed. And since what staticfiles actually cares about is whether the file has changed, it seems like it would make more sense to use a method that checks whether the file has changed, rather than just checking the last modification date.
Would I be correct in thinking that the main argument against this is API bloat, or is there something else that I'm not seeing? On Thursday, September 27, 2012 9:51:52 AM UTC-7, Dan Loewenherz wrote: > > Hey all! > > This is a feature request / proposal (one which I'm willing to build out, > given that I've already developed a solution for my own uploader). > > I run a consulting business that helps small startups build initial MVPs. > When the time ultimately comes to deciding how to store static assets, my > preference (as is that of many others) is to use Amazon S3, with Amazon > CloudFront acting as a CDN to the appropriate buckets. For the purposes of > this ticket, s/S3/your object storage of choice/g. > > Now, Django has an awesome mechanism for making sure static assets are up > on S3. With the appropriate static storage backend, running ./manage.py > collectstatic just searches through your static media folders and copies > the files. > > The problem I've run into is that collectstatic copies all files, > regardless of whether they already exist on the destination. Uploading > 5-10MB of files is pretty wasteful (and time consuming) when none of the > files have changed and no new files have been added. > > As I wrote in the trac ticket (https://code.djangoproject.com/ticket/19021), > my current solution was to write a management command that does essentially > the same thing that collectstatic does. But, there are a few differences. > Here's a rundown (copied straight from the trac ticket). > > I currently solve this problem by creating a file containing metadata of >> all the static media at the root of the destination. This file is a JSON >> object that contains file paths as keys and checksum as values. When an >> upload is started, the uploader checks to see if the file path exists as a >> key in the dictionary. If it does, it checks to see if the checksums have >> changed. If they haven't changed, the uploader skips the file. At the end >> of the upload, the checksum file is updated on the destination. > > > I'll contribute the patch. I know there is not a lot of time before the > feature freeze, but I'm willing to make this happen if there's interest. > > If we don't want to change behavior, perhaps adding a flag such as > --skip-unchanged-files to the collectstatic command is the way to go? > > All the best, > Dan > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/khLi3g_3z4EJ. 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.
