« Fight ‘em back!
Filter Forge for Mac »


Storing Files as URLs with Hibernate UserType

March 25th, 2009 by Paul

Storing Files in databases as a BLOB always seemed inherently daft to me. I wanted to be able to store user generated Files as URLs in the database, and let an HTTP Server serve them, so why is Hibernate storing BLOBs? Hibernates UserType allows conversion between ungainly classes such as java.net.URL or java.io.File and the somewhat pale and pasty datatypes of the database world.

At Less Rain we produce a lot of projects with User generated content, and a lot of dynamically generated images which need to be stored. Uploading files, and move them to an appropriate place on the server is one task, but storing that information and meta-data about the image (caption, height, width) and associating the file with a user's profile requires a database. We've been working with Hibernate Annotations for sometime, and love the flexibility it gives us in creating Domain Driven Designs, but the standard mapping for hibernate for Files is somewhat disappointing - they are stored as a BLOB in the database.

I've  often heard of people storing files as BLOBs in the database, but could never understand why. Databases are good at storing and retrieving information via queries. Many of our projects feature quite high contention for database connections, and the last thing we want to do is tie them up delivering a few hundred K of user generated imagery for every second request. Thats what file systems and web servers are designed to do.

We were able to make good use of Hibernate UserType to resolve this little dilemma, our first thought was to to store the path of the file in the Database, however an eclectic mix of developer machines, a dev server and a production  server with various Windows, and Linux Distros guaranteed that the path of the File would never remain consistent. We opted instead to store the URL of the file as a java.net.URL instance, after all the files would be served by an HTTP Server. A small configurable utility class allowed us to effortlessly resolve the URLs to file paths at creation, and back again if we needed to manipulate the File.

The User Type needs to be declared at the top of the Java file:

PLAIN TEXT
JAVA:


  1. ...
    2. 

  2.  
    3. 

  3. import com.blah;
    4. 

  4.  
    5. 

  5. @TypeDefs(
    6. 

  6.   {
    7. 

  7.     @TypeDef( name="URLUserType", typeClass = com.lessrain.util.hibernate.URLUserType.class)
    8. 

  8.   }
    9. 

  9. )
    10. 

  10.  
    11. 

  11. public class Image(){
    12. 

  12.  
    13. 

  13. ...

Our annotated Mapping looked like this:

PLAIN TEXT
JAVA:
  1. @Type(type="URLUserType")
  2. public URL getImageUrl()
  3.  
  4. {
  5. return imageUrl;
  6. }


and here is the code for the URLUserType:

PLAIN TEXT
JAVA:
  1. package com.lessrain.util.hibernate;
  2.  
  3. import java.io.Serializable;
  4. import java.net.MalformedURLException;
  5. import java.net.URL;
  6. import java.sql.PreparedStatement;
  7. import java.sql.ResultSet;
  8. import java.sql.SQLException;
  9. import java.sql.Types;
  10. import org.apache.commons.logging.Log;
  11. import org.apache.commons.logging.LogFactory;
  12. import org.hibernate.Hibernate;
  13.  
  14. import org.hibernate.usertype.UserType;
  15.  
  16. public class URLUserType implements UserType {
  17.  
  18. static final Log log = LogFactory.getLog(URLUserType.class);
  19.  
  20. public URLUserType() {
  21. }
  22.  
  23. public int[] sqlTypes() {
  24. return new int[] { Types.VARCHAR };
  25. }
  26.  
  27. @SuppressWarnings("unchecked")
  28. public Class returnedClass() {
  29. return URL.class;
  30. }
  31.  
  32. public boolean equals(Object x, Object y) {
  33. return (x == y) || (x != null && y != null && (x.equals(y)));
  34. }
  35.  
  36. public Object nullSafeGet(ResultSet inResultSet, String[] names, Object o)  throws SQLException {
  37.  
  38. String val =  (String) Hibernate.STRING.nullSafeGet(inResultSet, names[0]);
  39.  
  40. URL url = null;
  41. try {
  42. url = new URL(val);
  43. } catch (MalformedURLException e) {
  44. log.error("problem creating URL from " + val);
  45. }
  46.  
  47. return url;
  48. }
  49.  
  50. public void nullSafeSet(  PreparedStatement inPreparedStatement,  Object o, int i) throws SQLException {
  51.  
  52. URL val = (URL) o;
  53. String url="";
  54. if (val != null){
  55. url = val.toString();
  56. }
  57. inPreparedStatement.setString(i, url);
  58.  
  59. }
  60.  
  61. public Object deepCopy(Object o) {
  62.  
  63. if (o == null) { return null;  }
  64.  
  65. URL deepCopy = null;
  66. try {
  67. deepCopy = new URL(o.toString());
  68. } catch (MalformedURLException e) {
  69. log.error("Problem creating deepcopy of URL" + o.toString());
  70. }
  71. return deepCopy;
  72.  
  73. }
  74.  
  75. public boolean isMutable() {
  76. return true;
  77. }
  78.  
  79. public Object assemble(Serializable cached, Object owner) {
  80. return deepCopy(cached);
  81. }
  82.  
  83. public Serializable disassemble(Object value) {
  84. return (Serializable) deepCopy(value);
  85. }
  86.  
  87. public Object replace(Object original, Object target, Object owner) {
  88. return deepCopy(original);
  89. }
  90.  
  91. public int hashCode(Object x) {
  92. return x.hashCode();
  93. }
  94.  
  95. }


The main action takes place in the  nullSafeGet and nullSafeSet methods. These convert the URL to a varchar compatible String, and from a String back to a URL Object.

nullSafeSet takes our URL Object as an argument and uses it's toString method to get return a String which is Stored in the database as a simple varchar value.nullSafeGet takes the string, uses it to construct a new URL object, and return it.

For completion here is the interface of of our  File to URL converter:

PLAIN TEXT
JAVA:
  1. </code>
  2.  
  3. package com.lessrain.util.conversion;
  4.  
  5. import java.io.File;
  6. import java.net.URL;
  7.  
  8. public interface FileToURLConverter {
  9.  
  10. public URL getUrlFrom(File file);
  11.  
  12. public File getFileFrom(URL url);
  13.  
  14. public void setBasePath(String path);
  15.  
  16. public void setBaseURL(String url);
  17.  
  18. }


So thanks to the UserType we were able to let all the components do their own thing. The database doing relational mapping, the File system delivering files and the domain model expressing the logic of an image in the context of our application.

This entry was posted on Wednesday, March 25th, 2009 at 3:49 pm and is filed under Hibernate, Java. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “Storing Files as URLs with Hibernate UserType”

  1. Fernando Says:
    October 8th, 2009 at 3:50 pm

    My god, what type of anti-spam is that?

  2. Carsten Schneider Says:
    October 8th, 2009 at 4:08 pm

    One that caught 139,426 spam posts we didn’t have to filter out by hand.

Leave a Reply