Interactions with hrorm have two major points: building Dao objects and then using them.

Dao building is accomplished with the aptly named DaoBuilder class. DaoBuilder objects are part of the one-time (static, singleton) initiation of your application. There is little point in having more than one builder of any entity type. Of course, some care must be taken: by their nature, DaoBuilder objects are mutable, so if you directly expose them to the rest of your application during start up, it's possible that you can do something stupid.

Dao objects themselves are what perform the actual tasks of persisting and instantiating entity objects. To make a Dao requires a Connection object. Since a Dao keeps a stateful Connection to the underlying data store, it is dangerous to share instances across threads. Generally, the idea is to instantiate a Dao when you need it, and then allow it to be garbage collected. It is up the application itself to deal with reaping the Connection, with some exceptions noted below.

Also take a look at the Quick Start and Javadocs.


Before diving into the nuts-and-bolts of how to use hrorm, it is helpful to understand the ideas it implements.

Designing Entities

Using hrorm means accepting some restrictions on how your entities (both the Java classes and the SQL schema) are designed. Some of these restrictions are good practices regardless of how database and object models are built.

Java Objects

  • Every entity class should have a Long identifier field that will be used as a primary key. Hrorm expects that this is a nullable field and that null means unpersisted. Hrorm will populate this field from a sequence (see restrictions on schema below), unless you use an immutable model. The primary key will be used it when hrorm performs updates.
  • Hrorm expects to work with Javabean like entities with public getters and setters or with entities with public getters for fields and related builder objects with setters for the individual fields. (See documentation for Immutable Models.)
  • Hrorm expects child relationships to be modeled as List types exclusively. No sets or arrays or other collections.

SQL Schema

  • Hrorm expects every table to have a numeric primary key. No string keys or multiple column keys. Hrorm is not really appropriate for a time-series database.
  • Hrorm will populate the primary keys on inserts with values it pulls from a sequence. You can create a separate sequence for each table, or just have one overall sequence if you want. Hrorm does not care, but it wants a sequence for inserts.

At the moment Hrorm supports a limited number of (Java) datatypes: Long, BigDecimal, String, Boolean, and LocalDateTime. Additionally, hrorm supports a mechanism for persisting values that can be converted to and from String, which is intended primarily for enumerated types. Adding supports for new datatypes that are supported by the ResultSet interface should not be particularly difficult if you're a hacker.


One point of using a relational database as opposed to a document store or other mechanism is to preserve the structure of relations between entities. Hrorm supports two kinds of relationships: a parent-child relation where one object contains a list of children, and a sibling relationship, where one object expresses a connection with another entity.

Parent-Child Relations

These relations are defined by using the DaoBuilder.withParent() and DaoBuilder.withChildren() methods.

In a parent-child relationship, the child is assumed to be completely dependent on the parent, so that its very existence depends on the existence of the parent.

Take a look at the recipe example. If a recipe is deleted, it makes no sense to preserve the ingredient rows. So, if a call is made on the recipe Dao.delete() method, all the ingredients will be deleted too. Likewise, on an update hrorm will make the necessary inserts, updates, and deletes to the ingredients table to synchronize the object state.

In fact, you would rarely want to instantiate an ingredients Dao directly. Hrorm will do the work for you.

One tricky thing about these relationships is the reversal in how ownership is expressed between the database schema and the object model. In the object model, the Hand object has Finger objects. In the database, the FINGER table has foreign key references to the HAND table. With hrorm, the DaoBuilder object of both the parent and child need to understand the relationship, not just one or the other.

Sibling Relations

These relations are defined by using the DaoBuilder.withJoinColumn() method.

These are relations between two objects where one object refers in a dependent, but not controlling, way.

In the recipe example, the relationship between an Author and a Recipe is of this type. A Recipe requires an Author, but neither owns the other.

Hrorm requires that sibling objects be persisted first, and will not handle transitive persistence automatically. Likewise, deleting a Recipe will not cause a cascading delete of an Author record.

Note well: Hrorm will do nothing to prevent a dependent sibling from being deleted. The application code, or database schema constraints, (or both!) must be in place to prevent orphaned records of that type.


For the most part, hrorm tries to stay out of the transaction handling business. Applications know what changes must be transactions, hrorm does not. However, hrorm's commands to insert, update, and delete records can lead to multiple SQL statements being run, due to the handling of parent-child relationships. This means in the case of an error, the database is at risk of coming to an illegal state.

If nested transactions were supported natively by every database provider, it would probably be correct to wrap database mutations in an internally nested transaction and commit or rollback on completion. This is not possible for every provider, and mechanisms for how to accomplish this are not identical even for databases that do provide for transaction nesting.

Hrorm does give a minimal amount of support to attempt to alleviate these issues. Hrorm provides a Transactor class with a couple of methods to elminate the boilerplate try ... catch ... finally blocks necessary for doing transactions. In keeping with the hrorm ethos, these methods do not declare any checked exceptions. Keep in mind that a Transactor will automatically close its connection whether or not it completes with a commit or a rollback.

In addition, the Dao interface provides cognate methods for insert, update, and delete named atomicInsert, atomicUpdate, and atomicDelete. These methods provide a no-fuss way to do mutations of parent-child relations. However, these methods must be used with care! In addition to a possibly unexpected early commit if these methods are accidentally used in a larger transaction, remember that, as above, these methods will also close the connection they use when complete.

There is no one-size-fits-all solution to how to marry the problem of database to object mapping with the problems of transactions and atomicity. For this reason, hrorm mostly just tries to stay out of the way.

Dao Builders

Hrorm provides two kinds of builders: one for Javabean style entities (DaoBuilder) and one for immutable object models with separate builder objects (IndirectDaoBuilder). Both support very similar methods, and though most of the examples below show a plain DaoBuilder building for an immutable model is almost identical.

One Table

The easiest case for any ORM tool is persisting a single object backed by a single table. Let's work on persisting a model for a person that includes the following elements:

  • Name (a string or text)
  • Weight in kilograms (an integer)
  • Height in meters (a decimal)
  • Birthday (a date)
  • High school graduate? (a boolean)
  • Hair color (an enumerated type)

To model the person entity, we write a Java Person object.

    class Person {
        Long id;
        String name;
        long weight;
        BigDecimal height;
        LocalDateTime birthday;
        boolean isHighSchoolGraduate;
        HairColor hairColor;

A few small points.

  • Use your imagination to fill in getters, setters, equals, hashCode, etc.
  • We have one extra field that we did not have in our logical model: an id field that is to be used for persistence.
  • Assume that there is an enumerated type for hair color: HairColor.Black, HairColor.Brown, etc.

In the database we will create two structures for persisting this class: a table to store the data and a sequence to issue the IDs.


        NAME TEXT,

Note the somewhat different types than in the Java code. In particular, the boolean and enumeration values have become text fields. SQL has a more limited palate for the expression of types than Java.

To translate between the database reprentation and the Java representation, we plan to use a Dao object. We could build that directly, but hrorm provides a DaoBuilder class that makes things much easier. In hrorm, both Dao objects and their builders are parameterized on the type of thing they persist. We start off by simply calling the DaoBuilder constructor.

    DaoBuilder<Person> daoBuilder = new DaoBuilder<>("PERSON_TABLE", Person::new);

The constructor takes two arguments: the name of the table and a no-argument method for creating a new instance of the parameterized type.

Next, we need to define the primary key for this entity.

    daoBuilder.withPrimaryKey("ID","PERSON_SEQUENCE", Person::getId, Person::setId);

The primary key is defined with four elements:

  1. The name of the primary key column in the table ("ID")
  2. The name of the sequence that populates the primary keys ("PERSON_SEQUENCE")
  3. A function that retrieves the primary key (of type Long) from the Person object.
  4. A function that can set the primary key onto the object.

With that covered, we can being to teach the DaoBuilder about the individual data elements. First, we will teach it about the name field.

    daoBuilder.withStringColumn("NAME", Person::getName, Person::setName);

This explains that that table has a column named "NAME" and that the value in the table can be populated from calling getName() on a Person, and that value can be set by calling setName(). There are other methods on the DaoBuilder for other Java types.

For the integer weight value (which should actually be a Long or long, not an int or short).

    daoBuilder.withIntegerColumn("WEIGHT", Person::getWeight, Person::setWeight);

For fractional, decimal, or floating point values, hrorm supports the java.math.BigDecimal type.

    daoBuilder.withBigDecimalColumn("HEIGHT", Person::getHeight, Person::setHeight);

For dates and times, hrorm supports the java.time.LocalDateTime type.

    daoBuilder.withLocalDateTimeColumn("BIRTHDAY", Person::getBirthday, Person::setBirthday);

And similarly for boolean values. Note that the table should declare a text or string value. ANSI SQL does not support a boolean column type. Hrorm will convert between Java's boolean enumeration of true/false with the strings "T" and "F" in the database.

    daoBuilder.withBooleanColumn("IS_HIGH_SCHOOL_GRADUATE", Person::isHighSchoolGraduate, Person::setHighSchoolGraduate);

For the enumerated HairColor type, hrorm needs a bit more help, via an implementation of its Converter interface. We need a simple class that looks like this:

    class HairColorConverter implements Converter<HairColor, String> {
        public String from(HairColor item) {
            return item.getColorName();

        public HairColor to(String s) {
            return HairColor.forColorName(s);

Once the Converter exists, we can teach the DaoBuilder about it and the hair color field.

    daoBuilder.withConvertingStringColumn("HAIR_COLOR", Person::getHairColor, Person::setHairColor, new HairColorConverter());

Notice that in addition to the usual fields for column name, getter, and setter, we additionally must specify the conversion mechanism.

That completes the DaoBuilder. Now we can actually build a Dao<Person> object, assuming we have a java.sql.Connection.

But before that, we should note that the DaoBuilder supports a fluent interface, so we could write all of the above as:

    DaoBuilder<Person> daoBuilder = new DaoBuilder<>("PERSON_TABLE", Person::new)
                .withPrimaryKey("ID","PERSON_SEQUENCE", Person::getId, Person::setId)
                .withStringColumn("NAME", Person::getName, Person::setName)
                .withIntegerColumn("WEIGHT", Person::getWeight, Person::setWeight)
                .withBigDecimalColumn("HEIGHT", Person::getHeight, Person::setHeight)
                .withLocalDateTimeColumn("BIRTHDAY", Person::getBirthday, Person::setBirthday)
                .withBooleanColumn("IS_HIGH_SCHOOL_GRADUATE", Person::isHighSchoolGraduate, Person::setHighSchoolGraduate)
                .withConvertingStringColumn("HAIR_COLOR", Person::getHairColor, Person::setHairColor, new HairColorConverter());

In just 8 lines of code, we have taught hrorm everything it needs to know to CRUD Person objects.

Parent-Child Relations

When one entity contains a collection of other entities, hrorm calls that a parent child relation.

Here is a simple model for tracking inventories of stocks of things through time. At each instant that we measure, we want to know what quantity of each product we have.

    public class Inventory {
        Long id;
        LocalDateTime date;
        List<Stock> stocks;

    public class Stock {
        Long id;
        String productName;
        BigDecimal amount;

The Inventory class represents a snapshot in time of what was available in inventory, modeled as a List of Stock items, each of which contains a product name and a decimal quantity of how much of that thing is available. Notice that the Stock model includes a reference to the inventory ID, but not the inventory object itself.

To model this in the database, we make each item in the STOCK table point back to an INVENTORY record, as follows.




To model this in hrorm, we need to teach it about the parent-child relationship between the two entities using the DaoBuilder.withParentColumn() and DaoBuilder.withChildren() methods. First we make a Dao for the Stock entity.

    DaoBuilder<Stock> stockDaoBuilder = new DaoBuilder<>("STOCK", Stock::new)
            .withPrimaryKey("ID","STOCK_SEQUENCE", Stock::getId, Stock::setId)
            .withStringColumn("PRODUCT_NAME", Stock::getProductName, Stock::setProductName)
            .withBigDecimalColumn("AMOUNT", Stock::getAmount, Stock::setAmount);

The column INVENTORY_ID is marked not as an integer column, but with the special withParentColumn method. An entity can have only one parent. In the Inventory DaoBuilder we use the withChildren method to complete the relationship definition..

    DaoBuilder<Inventory> inventoryDaoBuilder = new DaoBuilder<>("INVENTORY", Inventory::new)
            .withPrimaryKey("ID", "INVENTORY_SEQUENCE", Inventory::getId, Inventory::setId)
            .withLocalDateTimeColumn("DATE", Inventory::getDate, Inventory::setDate)
            .withChildren(Inventory::getStocks, Inventory::setStocks, stockDaoBuilder);

When we create a Dao in this fashion we create a category of entity, the child, that is wholly dependent upon another, the parent. Whenever we insert, update, delete, or select the parent entity, the changes we make flow through the children and transitively to their children.

Be careful, if you do not want the children to be deleted, this is not the relationship you want to build. In particular, remember that issuing an update will result not just in a SQL UPDATE in the database, but possibly a whole series of INSERT, UPDATE, and DELETE queries being run.

Hrorm always understands child objects to be members of type List. No other collection type is supported.


If your object model for includes a back-reference from the child to the parent, Hrorm will populate it for you. If in the model above, the Stock class had a reference to its parent Inventory we could use an overloaded withParentColumn() method call on its DaoBuilder as follows:

    .withParentColumn("INVENTORY_ID", Stock::getInventory, Stock::setInventory)

That will cause the reference to the parent object to be automatically set when using any of the Dao select methods.

Sibling Relations

When one entity object contains a reference to another entity object, hrorm calls that a sibling or join relationship.

Consider a model of cities and states, where each city contains a reference to a state.

    class State {
        Long id;
        String name;

    class City {
        Long id;
        String name;
        State state;

This could be backed by this schema.

        NAME TEXT,

        NAME TEXT,


Creating the State DaoBuilder is trivial.

    DaoBuilder<State> stateDaoBuilder = new DaoBuilder<>("STATE", State::new)
            .withPrimaryKey("ID", "STATE_SEQUENCE", State::getId, State::setId)
            .withStringColumn("NAME", State::getName, State::setName);

There is one new trick to creating the City DaoBuilder: using the DaoBuilder.joinColumn() method which will refer to the stateDaoBuilder we just defined.

     DaoBuilder<City> cityDaoBuilder = new DaoBuilder<>("CITY", City::new)
            .withPrimaryKey("ID", "CITY_SEQUENCE", City::getId, City::setId)
            .withStringColumn("NAME", City::getName, City::setName)
            .withJoinColumn("STATE_ID", City::getState, City::setState, stateDaoBuilder);

The withJoinColumn method accepts an extra parameter: a DaoDescriptor. Both DaoBuilder and the Dao class implement this interface. Generally, it's much more convenient to create all the builder objects together.

Sibling or join relationships in hrorm are one-way. One object declares that it has a reference to another. Trying to make a circular relationship will lead to errors.

When hrorm instantiates objects like City from the database, it automatically instantiates the appropriate sibling State objects and sets the field in the City object.

Of course, you could just treat these as two one-table Dao objects, and then right some code to glue things together. In addition to being inconvenient, this will likely have poorer performance, since hrorm will issue a SQL left join to load the City and State objects with one query.

Objects can have several join columns, and those objects can have their own join columns. Hrorm will attempt to transitively load the entire object graph when a select() method is called on the Dao. There is a limit to how many joins hrorm can perform. Additionally, there is a limit to how many joins a database engine will allow. Consider this when designing Dao objects. Also remember, sibling relationships are for reading and populating objects, not for making saves or updates. If a sibling object is mutated, it must be saved itself.

Immutable Models

If you prefer that your Java entity model be made up of immutable classes, hrorm can support that.

Hrorm works well with immutable objects that have distinct builder classes for managing their setters. To allow this, hrorm provides an IndirectDaoBuilder class. The indirect moniker is intended to suggest that the entities will not be directly constructed, but that will be handled by the builder objects.

The following example uses lombok style builders, but you can roll your own if that's what you prefer.

    public class ImmutableThing {
        private final Long id;
        private final String word;
        private final BigDecimal amount;

    IndirectDaoBuilder<ImmutableThing, ImmutableThing.ImmutableThingBuilder> immutableThingDaoBuilder =
            new IndirectDaoBuilder<>("immutable_thing", ImmutableThing::builder, ImmutableThing.ImmutableThingBuilder::build)
            .withPrimaryKey("id", "immutable_thing_seq", ImmutableThing::getId, ImmutableThing.ImmutableThingBuilder::id)
            .withBigDecimalColumn("amount", ImmutableThing::getAmount, ImmutableThing.ImmutableThingBuilder::amount)
            .withStringColumn("word", ImmutableThing::getWord, ImmutableThing.ImmutableThingBuilder::word);

    Connection connection = // comes from somewhere

    // this retured object implements the identical interface as any other hrorm Dao
    Dao<ImmutableThing> immutableThingDao = immutableThingDaoBuilder.buildDao(connection);

It works very similarly to the regular DaoBuilder, but some extra details are required. There are now two type parameters: one for the entity itself and one for its builder object. On construction, instead of simply showing how to create a new entity instance, two parameters show how to make a new builder instance and how to make a new entity instance from the builder. Finally, all the setters are specified on the builder class, not the entity instance.

With a regular Dao the object's primary key will be set on the object during the insert(). This is not true for Dao objects created from an IndirectDaoBuilder. The insert method will still return the newly issued ID.

Indirect Dao objects support all the mechanisms for child and sibling records that regular Dao objects do. Due to the lack of population of IDs, some care must be taken. You cannot simply insert a sibling object and then immediately place it into a new entity instance, since it will not yet have its ID set.

Keyless Entities

Hrorm is built to support tables that have sequence valued primary keys. This is generally a good way to design a schema, but it's not always optimal. For instance, if you are storing an event stream in a database, assigning keys might just be a waste of time and space.

Hrorm does have some mechanisms for supporting entities that do not have primary keys. But, you cannot create a full-featured Dao for an entity without a primary key. In these cases, you can create a KeylessDao which has fewer methods.

Another drawback to the entities that are keyless is that they cannot be used as child or sibling entities. Hrorm manages all relationships via keys.


Hrorm provides little support for placing constraints on your object models or schema. The correct place for that is within your object model or schema or, best of all, both.

The DaoBuilder does allow you to mark particular columns as not null, by calling the notNull method. It will apply that constraint to the last column added to the growing definition.

Where a not null condition is defined in hrorm, it will prevent the creation of null entries in the particular field in question, either through inserts or updates. However, hrorm will ignore the constraint when attempting load records from the database, on the theory that loading questionable data is better than not loading it.

Since a properly designed object model and database schema can easily replicate this functionality and provide other much more significant invariant enforcement, it must be admitted that this facility is of little practical use.

One case where this can be helpful is during periods of data migration. If some element is moving from optional to required, Hrorm can at least help creating new records without the newly required element, until such time as more robust enforcement of constraints can be implemented by the application and database.


Hrorm provides a Validator to help in sure the database schema is in sync with the code.

The validation provided is not a substitute for testing that code works as intended. It simply checks that the names of the tables, columns, and sequences provided in the Dao descriptions exist as stated. Columns are checked to make sure they are of a correct type. As such, it can quickly find typos or other simple errors and report them. This can be particularly useful in times of database refactoring.

To check that a particular Dao is correct, simply pass it, or its builder, to the Validator::validate method with a live Connection. If the validation fails, an exception will be raised whose message describes the problems found.

    DaoBuilder<Entity> daoBuilder = new DaoBuilder<>("TABLE", Entity::new)
            .withPrimaryKey("id", "SEQUENCE", Entity::getId, Entity::setId)
            .withStringColumn("STRING_COL", Entity::getStringThing, Entity::setStringThing)
            .withIntegerColumn("INT_COL", Entity::getIntegerThing, Entity::setIntegerThing);

    Connection connection = // create connection just as for your application

    try {
        Validator.validate(connection, daoBuilder);
    } catch (HrormException ex){

The testing that this performs is light. It will not attempt to make any changes to the state of the database. It will merely check to make sure the structures exist as expected. Moreover, each Dao is tested individually. Related Dao objects, even dependent child objects, are not checked by the Validator.


To create a Dao from a DaoBuilder, just pass it a java.sql.Connection:

    // Assume the existence of some ConnectionPool
    Connection connection = ConnectionPool.connect();
    Dao<Person> dao = daoBuilder.buildDao(connection);


To create a new record in the database, we create a new instance of the class and pass it to Dao.insert().

    Person person = new Person();
    // set values for the fields we want
    person.setName("Thomas Bartholomew Atkinson Wilberforce");
    long id = dao.insert(person);

After that code runs, the record will be stored in the database. Hrorm will have pulled a new sequence value and set it on the object. The following assertions will be true. Note that for immutable objects whose Dao implementations were created using an IndirectDaoBuilder the ID will not be set.

    Assert.assertTrue(id == person.getId());

Hrorm will automatically insert child records of the instance being saved, if any.


If the record has sibling entities, references to those will be persisted. But be careful, those sibling references must be persisted first. Sibling inserts and updates do not cascade.


Hrorm provides a few methods for reading data out of the database and instantiating entity objects.

All of the selection mechanisms below will fully read and populate the entire relevant object graph including all children and siblings and all their transitive references.

Primary Key

You can read an item from the database if you know its primary key.

    Person person =;

If you want to read several IDs at once, you can.

    List<Person> personList = dao.selectMany(Arrays.asList(432L,21L,7659L));
All Records

If you want all the records (presumably for a smallish table) just do

    List<Person> personList = dao.selectAll();
By Columns

Most of the time, you do not know up front what ID or IDs you are intersted in, so hrorm allows you to select by columns. To do this, we make an instance of the entity we are searching for and populate it with the values we want to match or compare to. Suppose we want to find all the people who are high school graduates and that weigh more than 100 kilograms and who have the string fragment "Bart" in their names. We start by creating an instance of the entity with the critical values to be included in our query.

    Person personTemplate = new Person();

Then, we create a Map detailing what columns we are interested in and what comparisons to use when running the query.

    Map<String, Operator> columnMap = new HashMap<>();
    columnMap.put("IS_HIGH_SCHOOL_GRADUATE", Operator.EQUALS);
    columnMap.put("WEIGHT", Operator.GREATER_THAN);
    columnMap.put("NAME", Operator.LIKE);

Now we are ready to query for all the matching records.

    List<Person> people = personDao.selectManyByColumns(personTemplate, columnMap);

Notice that hrorm wants the names of the database columns, not the fields on the object. Also note that query generated will link the various parts of the where clause with "AND"s. The returned records will match all the specified criteria.

In addition to the like, equals, and comparison operators, hrorm supports creating ranges for numeric and date types that support comparison. There are methods for both open and closed ranges. The value for the field in question set in the template object becomes the low end of the range, and the methods for creating the ranges accept the upper limit as an argument.

If we want to find records using only the equals operator, hrorm provides a convenience method that does not require us to build the column name-operator map.

    List<Person> people = personDao.selectManyByColumns(personTemplate, "IS_HIGH_SCHOOL_GRADUATE", "WEIGHT", "NAME");

If we know that a particular query will only return 0 or 1 results (for instance, if there is a uniqueness constraint on the name field), hrorm provides a further convenience method for that.

    Person personTemplate = new Person();

    Person person = personDao.selectByColumns(personTemplate, "NAME");

If you use this method and hrorm finds more than one record, it will raise an exception.


After making changes to the state of the object, we can call


This will issue an update in the database based on the primary key (id) field.

Updates will automatically propagate to children, but not to siblings.


When we are done with a person, we can issue


To remove the record from the database, using the primary key, as with an update.

Deletes will automatically propagate to children, but not to siblings.


In addition to the insert, update, and delete methods, hrorm Dao objects provide variants of those methods called atomicInsert, atomicUpdate, and atomicDelete. These are useful if you do not mind your changes being committed automatically. But they cannot be used inside larger transactions. Additionally, these methods will close the Connection object their enclosing Dao was built with.


Many ORMs (and other database connectivity tools) provide some mechanism for lazily loading data. This is a useful feature since it's quite common to work on data sets in your application that are too large for it.

The biggest problem with this approach is that it can lead to peculiar bugs when a connection is closed too early and something that was to be lazily loaded cannot be.

Hrorm's select methods are not lazy and so are only suitable for selecting limited quantities of data. But, Hrorm does provide a way to run a select without instantiating a list of all the found objects with the Dao::foldingSelect method. This method allows a general select to be done, and then a flexible folding operation to take place on the database's returned result set.

At times, it might be more sensible to write the logic required as a select with a group by clause. But at other times you cannot express the application logic necessary in the database, and this facility exists for those times.


The SQL that hrorm generates to make a Dao can be accessed by calling the queries() method. The SQL is formatted in a way suitable for passing to a PreparedStatement with embedded question marks for variable substitution.

You can also access a Queries object by calling buildQueries() on a DaoBuilder object. This provides an identical instance, but does not require a Connection, which building a Dao does.



Hrorm thinks that checked exceptions are a mistake. In an application with a database dependency, you have three choices:

  1. Have SQLException declared in most methods all over your application.
  2. Try to handle SQLException somehow when doing interactions with Connection, Statement, and ResultSet objects, defeating the purpose of exception handling being centralized and removed from normal application flow.
  3. Convert SQLException to some other type, descended from RuntimeException.

Hrorm opts for method 3.

Hrorm will throw a HrormException when it has a problem. If there was an underlying SQLException that will be exposed on the HrormException.


The state of Java logging is a tiny bit unfortunate.

The java.util.logging package in the standard library is not widely used. Unfortunately, rather than a set of pluggable interfaces, they provided a concrete implementation.

Log4j is pretty ubiquitous, but not universal. Additionally, hrorm currently has no dependencies. It would be a shame to add one.

Hrorm therefore uses java.util.logging implementation. There are ways to redirect that to log4j and other logging frameworks.

Hrorm logs to a logger named "org.hrorm" all the SQL it issues at INFO level.


Hrorm is designed to have a small surface area for clients. Most of the time, clients should only need to interact with three hrorm types: DaoBuilder, Dao, and HrormException. There are a few other types that a client may want to use, but most of the classes in hrorm are internal to it.

In spite of this, almost all the classes in hrorm are public and contain public constructors and methods. If you feel like instantiating a JoinColumn object, hrorm feels no need to try to stop you.

Most of the time, hrorm will point out in the Javadocs where classes are not intended for clients to use directly.