Category Archive

In Java projects we often face the following scenario… In a server application we read a set of associated objects from a database. For example:

This data is sent to a client application. A client application user might modify Band name, add some Instruments and then remove a Manager. Then a user clicks submit/proceed and we are supposed to store the state of the object graph into a database.

You would like to store only truly changed objects with the correct SQL operation. In some cases ORM tools could perhaps help us with smart cascade settings. However, we prefer specifically controlling insert/update/delete SQL operation (since our client can track what has happened and we don’t want to execute any additional SQL). So we have used the following pattern…

There is BaseEntity that all persistent objects extend:

public class BaseEntity {
  // set true if entity needs to be deleted
  private boolean deleted;

  // set true if entity needs to be updated
  private boolean changed;

  // set true if entity needs to be inserted
  private boolean newEntity;

  // necessary get/setters...

In a client application we call methods setChanged(), setDeleted(), setNewEntity() in user event listeners. When objects need to be stored in a database, we can choose the appropriate SQL operation based on these flags. For example:

if (entity.isDeleted()) {
  session.delete(entity);
} else if (entity.isNewEntity()) {
  session.save(entity);
} else if (entity.isChanged()) {
  session.update(entity);
}

The only trick here is to write code that iterates all objects found in an object graph. To avoid coding this manually for all object graphs, we have implemented a small helper class that uses reflection to do this. So all we need to code in an application is something like this:

daoHelper.persistWholeGraph(myBand);

This would investigate all BaseEntity objects found inside myBand. It checks Collections of course and finds out the correct order of SQL statements.

We have used this pattern with Hibernate. And if you have read about Kauklahti, you probably guessed by now, that it supports this pattern. All you need to do is implement OperationResolver, for example:

public class BaseEntityOperationResolver implements OperationResolver {
  @Override
  public Operation resolve(Object obj) {
    if (obj instanceof BaseEntity) {
      BaseEntity entity = (BaseEntity) obj;
      if (entity.isNewEntity()) {
        return Operation.INSERT;
      } else if (entity.isDeleted()) {
        return Operation.DELETE;
      } else if (entity.isChanged()) {
        return Operation.UPDATE;
      }
  }
  return Operation.IGNORE;
}

So you can pass this resolver to Mapper.writeInsertUpdateDelete method. This writes the correct SQL operation for each Object in given object graph.

Generally, I am interested in to hear about other peoples experiences about this. What pattern has been good/bad in storing a client modified object graph? Does your ORM handle this well enough? What about if we needed to update only specific columns?

Couple of weeks ago I posted news about Kauklahti in TSS
http://www.theserverside.com/news/thread.tss?thread_id=58266.

I was hoping to get people’s attention with this title “Replacing
Hibernate with library of just 1300 lines of code”. I didn’t want to
post “Kauklahti 0.5.5 released”, nobody would have noticed that.

So what happened? I was expecting that people would criticize
(not-another-ORM!). Basically every new framework is accused of
reinventing the wheel.

But I was suprised how aggressive the critics were! They called my code shit :)

And I was also criticized for creating “hype”. Come on, one news
about Kauklahti is not hype. Of course I’m writing about benefits of
my solution (in my opinion)!

I know that creating your own ORM sounds ridiculous nowadays. There
are thousands of already coded solutions. But when I started thinking
about it, I realized that this was actually quite a simple task. It
sounded so stupid, but at the same the solution was so simple, that I
was almost laughing while coding it.

But hey, why not? Writing frameworks is good practice for your
coding skills. Of course, you must have a vision, that this solution
makes sense. It should be useful at least for one real project. If it
is, why not to code it yourself?

Why do we always attack against new frameworks? Although we know the
current ones are far from optimal solutions? Why not to support
creativity and the will to create a new perspective?

Even if it was invented before, why not to compete with it? Who can
reinvent it better, faster and lighter? Who is the best coder on this
planet?

I challenge you to write a lighter ORM than Kauklahti! I promise not to blame you for “reinventing the wheel”.

I recently established a new open source project http://sourceforge.net/projects/kauklahti/

Nowadays, JPA and Hibernate is the object-relational mapping standard. So it is quite stupid to write your own solution, right?

Well, we’ve been using Hibernate several years in different kinds of projects. We’ve seen solutions and problems from other vendors as well. Common problem is that complex class hierachies with many tables easily cause performance problems.

Inexperienced coders don’t check the actual SQL and only trust table generation tools. Even with best coders, we spend a lot of time with tuning fetching strategies and caching solutions. And then we might switch to custom SQL and JDBC in most complex queries. When this is done carefully, we get things right in the end.

In my opinion, this tuning and configuring takes too much time. I am not happy with the productivity of current JPA tools.

Furthermore, there are a lot of other “minor” problems. Lazy initializations and library-specific Collections are problems for a remote client and Swing applications. There are lot of library dependencies and we need exactly the correct versions (yes, there is Maven/Ivy, but still conflicts with application server classpath and other frameworks might cause a major headache). And I don’t like writing xml or annotations that make your code messy.

I wanted a simpler solution. I looked at couple of alternatives, but APIs weren’t exactly what I was looking for.

However, Spring framework has this simple class JdbcTemplate. It’s great with plain JDBC. Spring also includes BeanPropertyRowMapper that extracts ResultSet into list of JavaBeans. I liked the idea, but I also wanted some support for joined tables and full CRUD generation. I wrote Kauklahti to do just that.

How does it work? Supposing we have tables:

create table guitar (
  id INTEGER PRIMARY KEY,
  name varchar(100));

create table guitarstring (
  id INTEGER PRIMARY KEY,
  tone varchar(1),
  guitar_id INTEGER);

alter table guitarstring add constraint string_guitar_id
  foreign key (guitar_id) references guitar (id);

We write Java classes:

public class Guitar {

  private Long id;
  private String name;
  private List<GuitarString> strings;

  public Guitar() {}

  public Guitar(Long id, String name, List<GuitarString> strings) {
    this.id = id;
    this.name = name;
    this.strings = strings;
  }
}

public class GuitarString {

  private Long id;
  private String tone;

  public GuitarString() { }

  public GuitarString(Long id, String tone) {
    this.id = id;
    this.tone = tone;
  }
}

Then we create table mapping:

Table guitarTable = new Table(Guitar.class, "GUITAR");
Column[] guitarCols = {
  new Column("id", "id", true),
  new Column("name", "name", false)
};
guitarTable.setColumns(guitarCols);

Table stringTable = new Table(GuitarString.class, "GUITARSTRING");
Column[] stringCols = {
  new Column("id", "id", true),
  new Column("tone", "tone", false)
};
stringTable.setColumns(stringCols);

Join stringJoin = new ChildRefJoin("strings", stringTable,
  new String[] {"id"},
  new String[] {"guitar_id"});
guitarTable.setJoins(new Join[] {stringJoin});

Or if you like convention over configuration, you may use AutoConfigurator to create Table-mappings:

AutoConfigurator autoConf = new AutoConfigurator("fi.devtrain.*");
Table table = autoConf.config(Guitar.class);

Now it’s simple to generate SQL:

GuitarString aString = new GuitarString(new Long(1), "A");
List<GuitarString> strings = new ArrayList<GuitarString>();
strings.add(aString);
Guitar guitar = new Guitar(new Long(1), "Strato", strings);
List<WriterResult> inserts = mapper.writeInsert(guitar,guitarTable);
List<WriterResult> updates = mapper.writeUpdate(guitar,guitarTable);
List<WriterResult> deletes = mapper.writeDelete(guitar,guitarTable);

Execute it with Spring JdbcTemplate:

JdbcTemplate jdbcTemplate = new JdbcTemplate(myDataSource);
for (WriterResult wr : inserts) {
    jdbcTemplate.update(wr.getSql(), wr.getParams());
}

For queries, use Spring ResultSetExtractor with Kauklahti mapper.

ResultSetExtractor extr = new ResultSetExtractor() {
  public Object extractData(ResultSet resultSet)
         throws SQLException, DataAccessException {
    return mapper.extract(resultSet, guitarTable);
  }
};
String query = mapper.writeSelect(guitarTable);
List guitars = (List) jdbcTemplate.query(query, new Object[0],extr);

So what’s so great about Kauklahti? I wrote the solution, because it only took about 1300 LOC. And because:

• Mapping API is simple and programmatic
• Every piece of SQL is in my hands before execution
• It provides basic features I need in ORM (and nothing more)
• Only log4j.jar is required library dependency (even Spring is optional)

If you’re interested, download latest release from SourceForge or check out the code from http://kauklahti.svn.sourceforge.net/svnroot/kauklahti

User’s Guide and test examples are included to get things started.