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.