The art of doing it right – who knows it?

When I first started developing jOOQ, I was pretty sure that 85% of the people that hear about it for the first time will not take the time to look behind the first impression and think any of these things:

  1. Yet another ORM
  2. Why not just use Hibernate

That’s not surprising, and I can’t blame them. I precisely started developing jOOQ because I thought many people are caught up with these kinds of prejudices, lost in some enterprise architecture astronaut setup, where the lead developer has a strong opinion on how to do things. Don’t get me wrong, there are plenty of good reasons why you should use Hibernate. But in many projects, there are also plenty of good reasons why you shouldn’t. Besides, read about Architecture Astronauts on Joel’s blog, very funny and cynical but true post.

Back to the topic. When you deliver OSS, your users tend to be as demanding as if they had actually paid for it. Which isn’t a bad thing, as this is a big part of the drive behind OSS: actual need. Here’s a list of things I would have never expected to do “wrong”:

  1. Not delivering the sources of my third party dependencies to those users that don’t have Maven. I have only optional dependencies (such as slf4j, log4j, ant, JPA), but if you want to build jOOQ yourself, they may get in your way.
  2. Making a deliverable that’s too big (8MB including all the dependencies from point 1).
  3. Making a binary-only deliverable that’s not as big (800kB instead of 8MB). No one downloaded that one so far.

    Guys, make up your mind!! :-) But the newest one is taken from a comment on ITEYE, a chinese news site (use Google Translate):

  4. Apparently, I release too often (in fact twice a month). This indicates “instability”. If I released less often it would maybe indicate not being agile and flexible enough.

Of course, I don’t take these things personal. And I hope if you requested any of the above changes, you won’t either :-). This is meant to be a funny post to start the week with and I’m hoping to hear some feedback about things that YOU might’ve done “wrong” in the past…

iciql, a fork of H2’s JaQu

I just came across a new project in the world of SQL-simulating fluent API’s. It’s called iciql and can be found here:

http://iciql.com/

iciql has been forked by James Moger who has recently contributed to H2’s JaQu library. JaQu is a side-product of the H2 database, which currently suffers from a low priority on the H2 roadmap (see the discussion about the status of JaQu here), so it’s a good move by James to keep his “contributing momentum” going and continue developing that library. Let’s wish him luck!

jOOQ and Java 7

There are more and more blog posts popping up on the internet about Java 7‘s bugs that crash Lucene and Solr, as well as other software. I just found this interesting post here, from a Lucene developer:

http://blog.thetaphi.de/2011/07/real-story-behind-java-7-ga-bugs.html

I wonder what the implications of using Java 7 will be for jOOQ users. So far, no reported issues :-) but that doesn’t have to mean anything. On the other hand, no one sane will immediately switch productive systems to the first new major release of a whole JDK platform.

The Avajé Ebean Framework and asynchronous query execution

Yesterday, I posted about the Ollin Framework, which implements fetching data into callback types, similar to Spring’s JdbcTemplate. Another idea I had recently discovered, is that of asynchronous query execution. Even if there are only few use cases for that in every day development life, sometimes it’s interesting to be able to load data in the background. An example is an accounting application that displays a pre-calculated dashboard with interesting information for the user to keep them busy and distracted, while the heavy load of accounting data is loaded in the background for the more sophisticated screens. Or maybe you just want to take advantage of your high-performant Oracle database and run several OLAP queries in parallel while you generate a neat report for your user.

This idea is implemented in the Avajé EBean Framework, which makes use of the java.util.concurrent.Future API. The example they provide looks like this:

Query<Order> query = Ebean.find(Order.class);
FutureList<Order> futureList = query.findFutureList();

// do something else ...

if (!futureList.isDone()) {
    futureList.cancel(true);
}

// wait for the query to finish...
List<Order> list = futureList.get();

This really looks appealing, I think! In the jOOQ world, this would map to something like this

FutureResult<BookRecord> result =
create.selectFrom(BOOK)
      .where(Book.AUTHOR_ID.in( /* expensive subquery */ ))
      .fetchLater();

… and the rest is pretty much the same, as FutureResult just extends both org.jooq.Result and java.util.concurrent.Future.

The Ollin Framework

I have recently discovered a simple Java database framework called “Ollin“. It can be found when searching jdbc fluent api on Google. It has a couple of transaction handling and ORM features, the way many other frameworks do this. But one specific functionality I found particularly interesting:

ValuedRowVisitor<Integer> rowCounter =
dbSession.createQuery("select * from app.employee")
         .forEachRow(new ValuedRowVisitor<Integer>() {
            private int counter;

            public Integer getValue() {
              return counter;
            }

            public void visit(ResultSetRow row) throws SQLException {
              counter++;
            }
         });
System.out.println("Count of rows: " + rowCounter.getValue());

In this example, you can pass an anonymous type implementing a RowVisitor base interface to a “closure-style” foreach method. Victor Herrera, the creator of Ollin designed this specifically for a use case he had where large amounts of rows (or records) needed to be processed and memory was getting low. This use case is already covered in jOOQ when using the ResultQuery.fetchLazy() method, and then iterate over the resulting Cursor. But the idea of “injecting” a custom handler seemed appealing to me, so with Victor’s permission, I have implemented a similar construct for jOOQ 1.6.4 with #728.

In jOOQ, the magic word is “fetch”, and as discussed recently, there is now the possibility of fetching things into custom types using ResultQuery.fetchInto(Class<?>). So why not also fetch results into custom “targets” like this:

create.selectFrom(T_BOOK)
      .orderBy(TBook.ID)
      .fetchInto(new RecordTarget<TBookRecord>() {
        @Override
        public void next(TBookRecord record) {
          // Do stuff
        }
      });

I’m thrilled to find good open source ideas on the web. I’m always open to new ideas and this Ollin Framework made my day, today :-)

See the framework here: http://code.google.com/p/ollin/

jOOQ makes a step forward towards JPA

With the upcoming release 1.6.4 and the implementation of #198, jOOQ will start to better integrate in “standard” J2EE architecture. While jOOQ is being developed as an alternative to JPA, it should not compete with it. This means that there are some parts in JPA which can easily co-exist with jOOQ in a J2EE application:

For this purpose, jOOQ will interface the fetching of org.jooq.Result with JPA-annotated entites. This interface can be accessed as of release 1.6.4 in any of these types:

public interface ResultQuery {
    // [...]

    // Fetch results directly into a list of your custom annotated entity
    <E> List<E> fetchInto(Class<? extends E> type) throws SQLException;
}

public interface Result {
    // [...]

    // Copy existing results into a list of your custom annotated entity
    <E> List<E> into(Class<? extends E> type);
}

public interface Record {
    // [...]

    // Transform a single record into your custom annotated entity
    <E> E into(Class<? extends E> type);
}

The above API extension shows how easily JPA-annotated types can be integrated in jOOQ. With any of these methods, you can use jOOQ’s fluent querying API to execute complex queries, and then further process your data using your own POJO‘s, which can be further modified and persisted using your favourite JPA implementation’s EntityManager. But most importantly, your POJO’s will have no dependency on jOOQ anymore, unlike today’s org.jooq.Record. Even better, this will also work with non-annotated types, where jOOQ will try to match Record fields against Class members and methods by a common naming convention.

A snapshot preview of version 1.6.4 can be seen on the Sonatype Maven repository:

https://oss.sonatype.org/content/repositories/snapshots/org/jooq/