Oct
2007
ORMs really interest me, so naturally I read a lot of material regarding ORMs of all kinds, especially Hibernate and ActiveRecord. One of the more interesting reviews I read recently complained about the rigidity of the type system in the Rails ORM. According to the author’s examination of the code, ActiveRecord just uses a monolithic switch/case statement to determine the appropriate Ruby type from the SQL type in the result set. This may make sense from a simplicity standpoint, but it may not be the best approach when it comes to flexibility.
The problem with this approach is that it’s impossible to easily add new types to the ORM. Granted, the framework authors could do it by modifying the switch/case statement(s) - and the approach does usually require more than one statement - and releasing a whole new version of the framework. This is not a significant issue as the framework authors already have access to the full library sources. The real trial is with third-party developers who require custom data types.
An alternative approach (suggested in the article) is to implement a series of type delegates inheriting from a common superclass, or possibly using a mixin as allowed by Ruby. These type classes would each be responsible for a single type, handling the mapping both to and from the language-native type to the database type. This would allow for both easy addition and modification of core types by the framework authors, but also trivial support for arbitrary types as implemented by third-party developers.
Not one to shirk good advise when I hear it, I’ve decided to go with this approach to types in ActiveObjects. Formerly, I must admit I had gone with the multiple, giant switch/case statements. This seemed to make sense when I first implemented the framework, but it developed, it became apparent that this was inadequate, especially if third-party types are desired. This decision led to the refactoring of the type system and subsequent creation of the TypeManager class.
TypeManager is basically the singleton manager for the entire type system. It maintains the list of available DatabaseType(s) and can resolve both Java classes and SQL types to the appropriate delegate. A number of core types (VarcharType, IntegerType, etc) are added to the singleton instance of TypeManager, ensuring that basic functionality works without any extra effort on the part of the developer. If a type other than the core types is needed, all that is necessary is to add the type delegate instance to the TypeManager prior to the type’s usage in either migrations or data access. Thusly:
public interface Company extends Entity { public String getName(); public void setName(String name); public Class<?> getJavaType(); public void setJavaType(Class<?> type); } public class ClassType extends DatabaseType<Class<?>> { public ClassType() { super(Types.VARCHAR, 255, Class.class); } @Override public Class<?> convert(EntityManager manager, ResultSet res, Class<? extends Class<?>> type, String field) throws SQLException { try { return Class.forName(res.getString(field)); } catch (Throwable t) { return null; } } @Override public void putToDatabase(int index, PreparedStatement stmt, Class<?> value) throws SQLException { stmt.setString(index, value.getName()); } @Override public Object defaultParseValue(String value) { try { return Class.forName(value); } catch (Throwable t) { return null; } } @Override public String valueToString(Object value) { if (value instanceof Class) { return ((Class<?>) value).getName(); } return super.valueToString(value); } @Override public String getDefaultName() { return "VARCHAR"; } } // ... TypeManager.getInstance().addType(new ClassType()); Company[] stringCompanies = manager.find(Company.class, "javaType = ?", String.class); for (Company c : stringCompanies) { System.out.println(c.getName() + " former held type " + c.getJavaType().getName()); c.setJavaType(Exception.class); c.save(); } |
The most complicated bit of the example above is the database type itself. Yet even this delegate isn’t too horrible. The ClassType class first specifies in its constructor which types it corresponds to, both database and Java. Multiple Java class types can be specified, allowing for cases like IntegerType which maps to both Integer.class and int.class.
The rest of the database type is fairly self-explanatory. There are methods to read the Java value out of a JDBC ResultSet, put the Java value back into a JDBC PreparedStatement, as well as three methods to handle some of the non-database type-sensitive operations, such as parsing a String value into a type-specific value and visa-versa. These database non-specific conversions are required for things like parsing the value of a @Default or an @OnUpdate annotation. Finally, getDefaultName() allows the default DDL rendering of the type to be specified. This can be overridden in the DatabaseProvider implementation for that particular database, but the use of getDefaultName() allows for third party types that the database provider developers may not have foreseen. Thus, it effectively opens the door to third-party types in migrations.
Of course, no example would be complete without another one to complement it! Here’s how we could create a type delegate for the java.awt.Point class:
public class PointType extends DatabaseType<Point> { private static final Pattern PATTERN = Pattern.compile("x=(\\d+),y=(\\d+)"); protected PointType() { super(Types.VARCHAR, 45, Point.class); } @Override public Point convert(EntityManager manager, ResultSet res, Class<? extends Point> type, String field) throws SQLException { return (Point) defaultParseValue(res.getString(field)); } @Override public void putToDatabase(int index, PreparedStatement stmt, Point value) throws SQLException { stmt.setString(index, valueToString(value)); } @Override public Object defaultParseValue(String value) { Point back = null; Matcher matcher = PATTERN.matcher(value); if (matcher.find()) { back = new Point(); back.x = Integer.parseInt(matcher.group(1)); back.y = Integer.parseInt(matcher.group(2)); } return back; } @Override public String getDefaultName() { return "VARCHAR"; } } |
One thing of note here which has changed from the previous example of ClassType is that the second parameter to the super constructor is now 45, instead of 255. This parameter is actually the default precision of the SQL type when rendered into the database. If the SQL type doesn’t have a precision or should just take the database default, a negative value should be specified for this parameter. Another item of note is that we’re delegating work between methods in a way that I simply didn’t do for ClassType. Because the rendering of the type in the database is in VARCHAR (String) form, we can rely upon our default String conversion methods to render into the database. As an aside, the superclass implementation of valueToString(Object) uses the toString() method for that particular value.
As you can see, the type system in ActiveObjects is incredibly powerful and capable of satisfying many use-cases that were impossible in previous versions or other ORMs. Hopefully this brief glimpse into advanced uses of the type system will aid you in databasing efforts.