Peace Between Java and SQL

23. November, 2011

There are various attempts to get Java and SQL to behave with each other. We have JDBC, OR mappers like Hibernate and EclipseLink, language support like in Groovy. All of those have advantages and drawbacks.

JDBC is powerful but low-level. The API is not really friendly. You need to write a lot of boiler plate code for even simple tasks.

Languages like Groovy wrap JDBC to make simple tasks simple. The code becomes much more readable but changes in the database schema become runtime errors.

OR mappers try to turn a relational database into a OO database. It works better than you’d expect but it also causes odd problems and leaks into design of your code: You must no’t use the ID field in equals, hiding the session in a thread-local variable can cause exceptions when you use lazy loading, failing to understand the requirements of the OR mapper causes spurious bugs. At least the OR mappers will complain when the schema changes.

Enter jOOQ. It’s like a OO wrapper for JDBC:

  • You get all the power of JDBC if you need it
  • The readability of a fluent interface
  • The database schema is part of the code (so you get compile time errors if it changes)
  • You can iterate over results as if they were a plain Java collection

Related:


Logging JDBC with slf4j

7. October, 2010

 

This chart represents several constituent comp...

Image via Wikipedia

 

If you use slf4j in your project and need to log JDBC events, then have a look at log4jdbc. It has all the usual features: Timing statements, showing all arguments, mapping SQL to connections. It can even log stack traces if you need to know where a JDBC call was made. Sample output:

16:32:56.162 [INFO ] jdbc.connection - 1. Connection opened  java.sql.DriverManager.getConnection(DriverManager.java:525)
16:32:56.168 [DEBUG] jdbc.connection - open connections:  1 (1)
16:32:56.169 [DEBUG] jdbc.audit - 1. Connection.new Connection returned   java.sql.DriverManager.getConnection(DriverManager.java:525)
16:32:56.284 [DEBUG] jdbc.audit - 1. PreparedStatement.new PreparedStatement returned   com.avanon.basic.db.XPreparedStatement.prepare(XPreparedStatement.java:84)
16:32:56.292 [DEBUG] jdbc.audit - 1. Connection.prepareStatement(SELECT *
FROM V_RCSA_40_4_CTRL_RATING) returned net.sf.log4jdbc.PreparedStatementSpy@423606  com.avanon.basic.db.XPreparedStatement.prepare(XPreparedStatement.java:84)
16:32:56.162 [INFO ] jdbc.connection - 1. Connection opened  java.sql.DriverManager.getConnection(DriverManager.java:525)
16:32:56.168 [DEBUG] jdbc.connection - open connections:  1 (1)
16:32:56.169 [DEBUG] jdbc.audit - 1. Connection.new Connection returned   java.sql.DriverManager.getConnection(DriverManager.java:525)
16:32:56.284 [DEBUG] jdbc.audit - 1. PreparedStatement.new PreparedStatement returned   com.avanon.basic.db.XPreparedStatement.prepare(XPreparedStatement.java:84)
16:32:56.292 [DEBUG] jdbc.audit - 1. Connection.prepareStatement(SELECT *FROM V_RCSA_40_4_CTRL_RATING) returned net.sf.log4jdbc.PreparedStatementSpy@423606  com.avanon.basic.db.XPreparedStatement.prepare(XPreparedStatement.java:84)
16:32:56.342 [DEBUG] jdbc.audit - 1. PreparedStatement.clearParameters() returned   com.avanon.basic.db.SetParameters.clear(SetParameters.java:144)
16:32:56.343 [DEBUG] jdbc.sqlonly -  com.avanon.basic.db.XPreparedStatement.executeQuery(XPreparedStatement.java:71)
1. SELECT * FROM V_RCSA_40_4_CTRL_RATING
16:32:56.350 [INFO ] jdbc.sqltiming - SELECT * FROM V_RCSA_40_4_CTRL_RATING  {executed in 7 msec}
16:32:56.356 [DEBUG] jdbc.audit - 1. PreparedStatement.executeQuery() returned net.sf.log4jdbc.ResultSetSpy@2c5444  com.avanon.basic.db.XPreparedStatement.executeQuery(XPreparedStatement.java:71)
16:32:56.412 [DEBUG] jdbc.audit - 1. PreparedStatement.close() returned   com.avanon.basic.db.DBUtil.close(DBUtil.java:114)
16:32:56.418 [INFO ] jdbc.connection - 1. Connection closed  com.avanon.basic.db.DBUtil.close(DBUtil.java:129)
16:32:56.418 [DEBUG] jdbc.connection - open connections:  none

The strange “1.” is the connection number.

Alternatively, check out jdbcdslog.