SQL Zone is brought to you in partnership with:

Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2576 posts at DZone. You can read more from them at their website. View Full User Profile

O/R Broker: A JDBC Framework for Scala (and Java)

06.14.2010
| 11059 views |
  • submit to reddit
With a minimalist API built for common everyday use cases, O/R Broker provides the functionality of a JDBC framework for Scala developers.  Java developers can use the API for enforcing proper, optimal access (including stored procedure calls).  The open source framework externalizes SQL into text files for organization and post-deployment revisions.  The best part is that O/R Broker 3.0, which is near to its final release, works exclusively with the latest version of Scala - 2.8.

Most Scala developers are aware that Scala 2.8 is not binary compatible with the 2.7 branch.  So being able to use O/R Broker with 2.8 is great news for people who want to use all of the latest language features in a JDBC framework.  O/R Broker is suitable for legacy DB access were ORMs are not as viable.

Nils Kilden-Pedersen, the project's creator, calls it "A framework for the relational database connesuir, i.e. someone for whom query performance is an important and ongoing effort; who knows when to use, and needs, the various transaction isolation levels and where transaction scope is under full control. Or just if you happen to work with a fascist DB admin who forces you to use stored procedures or insist on verifying, or even rewriting, the SQL."  He says that O/R Broker is not a Scala query DSL or an ORM tool in the traditional sense (i.e. SQL generation and JavaBeans).

You can see a simple example using O/R Broker below:

1. Write the SQL
selectCustomer.sql:
SELECT
ID, NAME
FROM
CUSTOMER
WHERE
ID = :custID
The parameters, custID in this case, start with a colon ":"

2. Writing the Row Extractor in Scala
object CustomerExtractor extends RowExtractor[Customer] {

// Construct object from row.
def extract(row: Row) = {
val id = row.integer("ID").get
val name = row.string("NAME").get
new Customer(id, name)
}
}

3. Execute Query
  val customer = broker.readOnly() { session =>
session.selectOne('selectCustomer, "custID"->1234)
}: Option[Customer]
custID is mapped to the supplied ID which will match the :custiD parameter.  Connections are closed automatically.

You can find the recommended configuration here.  That document will explain how O/R Broker finds the .sql file.

Here are a few other points about O/R Broker:

  • Full freedom on class design. O/R Broker does not place any limitations on how you design your classes. No restrictions whatsoever.
  • You write the SQL. This allows you to hand tune any query, even after deployment, is faster than configuring some obscure XML syntax.
  • Full support for JOIN queries, both one-to-one and one-to-many.
  • No N+1 select problem and no transactionally inconsistent lazy loading
  • Support for stored procedure calls.
  • You write the query-to-object extractor code in Scala (or Java). No tired old XML mapping needed.
  • SQL can be in code or, preferably, in simple text files, ready for editing and optimizing if needed.
  • Dynamic SQL using Velocity or FreeMarker template engines. Both are supported, but neither are required.
  • Dealing with new database schema, legacy schema, JavaBeans, or immutable classes? All possible, full flexibility.

You can read the O/R Broker ScalaDoc for full instructions on how to use it.