This simple change in Spring 2.5.2 and above lets you remove boilerplate code that you have probably written for simple JDBC queries performed with the generics-aware SimpleJdbcTemplate (read my earlier 5 Minute Guide to… if you don’t know what this is). Change this:
new ParameterizedRowMapper<String>() {
@Override
public String mapRow(ResultSet rs, int rowNum) throws SQLException {
return rs.getString("State");
}
}Into this:
new ParameterizedSingleColumnRowMapper<String>()
The fully qualified class name is org.springframework.jdbc.core.simple.ParameterizedSingleColumnRowMapper. Neat! If you’re interested in where this came from, you can have a look at the JIRA issue SPR-4320.
One of the most irritating limitations of plain JDBC is that queries with a variable number of parameters are notoriously painful to deal with. The most common case of this is with the IN clause, which by definition is intended to accept a variable length argument list. JDBC, for those who don’t know, does not allow variable-length bound parameters.
Having worked with Spring’s Hibernate abstraction (HibernateTemplate) for some time, I have gotten used to Spring’s value-added feature of expanding Collections bound to HQL parameters (it’s a shame that Hibernate doesn’t natively support this, AFAIK). I was pleasantly surprised to find out that Spring offers JDBC support for this feature as well. Here’s a simple set of examples…
Continue reading “Auto-Expanding Collections as JDBC Parameters with Spring SimpleJdbcTemplate”
I have noticed a trend recently among some folks in the Java world, where it is simply taken for granted that an ORM provider (usually Hibernate) will be automatically inserted in the technology stack of any new project. Quite often, this happens with little to no technical justification or analysis. If you’re reading this and nodding your head, this should be frightening to you. The reason is that if the use of an ORM isn’t required, it can cause projects (especially small ones) to have unneeded complexity. Additionally, abstraction without understanding what’s underneath can set a dangerous level of ignorance on the part of developers, who will simply collapse when the abstraction breaks and critical thinking through the abstraction is required to solve a problem.
In that spirit, I recently worked on a personal project to learn how one can write dead-simple plain old JDBC applications using only Spring Framework 2.5 without an ORM layer. Spring 2.5 has many features that provide some of the convenience of ORM libraries (simple mapping from ResultSets to Objects), some convenience above and beyond ORM libraries (mapping from ResultSets to primitives!*), and removes some of the complexity (caching, cascading, etc.). For applications with fewer tables than you have fingers on your hand, this can greatly ease development.
I’ll assume you already know how to work with Spring, and at least know (or can dredge up) the basics of JDBC. We’ll work through a simple example, mapping the ubiquitous “Person” table to a Person object, and back again through an insert operation. Hopefully this will open your mind to non-ORM solutions. I promise that in 5 minutes (or less!) you will be amazed at the things you can do with simple JDBC 
Continue reading “5 Minute Guide to Spring and Simple[r!] JDBC”
