how do I ensure HTTP file upload (ie multipart etc) is transactional?

How can I ensure that if I am doing a HTTP file upload (e.g. say to update an existing file from v1 in my web application to v2) that it acts transactionally?

That is in this case assume my web application has v1 of the file, but as part of the admin interface I can update this file. If whilst uploading v2 there is an issue with the file upload I want to ensure v1 is still in place, and not some corrupt v2 copy instead.

Another way of asking this question might be whether I can 开发者_JAVA技巧let the server-side file upload code to point the file directly to where it has to go, OR whether (if HTTP file upload isn't transaction) I really need to put in some additional server side code to do a two step process of (a) upload to temporary location and then (b) if successful then transfer it into the final location (but I'd still want to give the client an indication of whether the overall upload worked or not too), and (c) there are some database status fields to update also on the server side.

This I think is a generic question however i can point out that in my case the back end is a Ruby on Rails application.

Any suggestions in terms of a good approach welcome.

Thanks

In most cases, HTTP transferred files are uploaded to a temp directory and it would be your responsibility to move it to its final destination once the upload is complete. So this is usually a given requirement. Also when file transfers fail, in the request process, the system will push something back and stop the original request. Giving you a pseudo transaction, since it will not finish the request and reach the portions of your code that complete the update.

This is all assuming your setup has nothing out of the ordinary going on.

Also if you can, you should think about investing in an attachment plugin/gem that could handle some of the heavy lifting for you. I'm a big fan of Paperclip.

You're definitely on the right track. You'll need another layer to take care of simulating a transaction. The pattern you describe of uploading the file to a temporary location or using a temporary name and then moving or renaming it is quite common. Adding the database update as the last update guarantees that if the update happens then the other steps completed successfully.

You might have to add some additional code to compensate for failed transactions, such as cleaning up files that didn't get uploaded successfully (failure at parts a and b), and updating the database from the file information if possible to compensate for failures during part c.