Hi folks,
I've seen this discussed quite a few times, and I went and looked at the archives, but I haven't seen a full description of uploading files into the database. These are the issues that I see: 1. Servlets don't really support handling of "multipart"/upload. Not only does it mean that you need to use a third party solution like Jason Hunter's com.oreilly.servlet (cos.jar), http://www.servlets.com/cos/index.html. It gets even worse. You can't just use this library for the uploads and handle your other variables/params normally. The servlet won't even see your params. I suspect it's probably the nature of the beast and how http://www.ietf.org/rfc/rfc1867.txt sets it up. 2. Once you upload the file you need to insert it into the database. Since we're dealing with large objects, this is not as trivial as inserting normal data types. 3. You also want to keep some information about the mime type, and possibly the original file name of the file that was uploaded. Proposed solution: Jason Hunter has an elegant solution to part of the problem, http://www.javaworld.com/javaworld/jw-06-2001/jw-0622-filters-p4.html He creates a filter that handles multipart/upload part of the request and then passes the rest to the "normal" servlet. This is important for us since it lets us use the request in our standard forms that do a lot of other stuff, such as validation, handling other types with the database, etc. You can see the details at www.zapatec.com. The above filter though creates a file on disk, it doesn't insert the file into the database. One option is to leave things this way, and in the servlet fetch the file and insert it into the db. (As a side note, there could be an architectural decision not to store the files in the database at all, and instead just save them on disk and have a "pointer" from the db to the file on disk). There are a variety of problems with saving the file and then inserting into the db, including dealing with race conditions on the naming, keeping track of disk space, cleanup, etc. For us though, it's not really an option since part of our security model is that we don't let contexts write to disk. I'm thinking of changing the code so that filter inserts a row for each uploaded file into the zp_files table, that had the following structure: create table zp_files ( id int, data bytea --postgress large binary object. Change to blob for others Primary Key ("id") ); Once the filter inserts the object into the db it makes the id available to the servlet as a regular param, with all the other params. The webapp then inserts the other data into the db and the id that points to the row into the zp_files table. This solution avoids race conditions since you're not going to be able to insert duplicate ids in the table, and also provides good separation between the specific issue of upload and the general servlet handling. The downside is that since it involves a filter, you need to be running 2.3. I'd be interested in hearing opinions about this approach. Thanks, Dror -- Dror Matalon Zapatec Inc 1700 MLK Way Berkeley, CA 94709 http://www.zapatec.com ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
