jDBI has been getting some love here and there, and a recent feature request has lead to a great design change.
The first thing is that the upcoming 2.0 release is going to require JDK 1.5. Why? Because I was beaten with a stick at ApacheCon for not doing something that made total sense to do, but was not very aesthetic in the current codebase. What this really means is that you can do stuff like this in the upcoming release:
public void testDemo() throws Exception
{
Handle h = DBI.open(Tools.getDataSource());
h.createStatement("insert into something (id, name) values (:id, :name)")
.setInteger("id", 1)
.setString("name", "Brian")
.execute();
h.insert("insert into something (id, name) values (?, ?)", 2, "Eric");
h.insert("insert into something (id, name) values (?, ?)", 3, "Erin");
List<Something> r = h.createQuery("select id, name from something " +
"where name like :name " +
"order by id")
.setString("name", "Eri%")
.map(Something.class)
.list();
assertEquals(2, r.size());
assertEquals(2, r.get(0).getId());
assertEquals(3, r.get(1).getId());
h.close();
}
This illustrates a couple of the biggest changes -- there are statement and query abstractions which allow for much more fine tuning of what happens. This opens the door for lazy iteration, setting of isolation levels, etc. All the nice stuff which you need sometimes in JDBC.
The map(Something.class) in there is a fun one -- by
default queries still do lists of maps (of String => Object) but
bean mapping, custom mapping, etc are much more easily done with the
ability to specify a mapper in the query, rather than as an
interceptor on the handle. The API is much nicer there.
FInally, what isn't shown above because I haven't finished it, is the statement rewriting system. It is designed to pretty much support first-class macros, with access to the parameters at the time of macro expansion. This allows for some really interesting dynamic SQL scenarios done very cleanly.
I also thought up a byline for jDBI =) "Because SQL shouldn't be such a pain the ass in Java." Not very catchy, but it certainly sums up my thoughts.
0 writebacks [/src/java/jdbi] permanent link
Whee, now that I am awake again I can can shout about it =) Massive overhaul of Ning went out the door Thursday morning at about 7am. When I woke up again Friday morning it was fiddling the bits that always go funny with a major release. Now that my soul has returned to my body from major-release induced jet-lag like sleep oddities (thank you for the analogy, Mr. Gibson, it is the best way to describe the feeling I have come across) I want to shout about it =)
The first thing I think folks notice is that Ning is now gorgeous =) It isn't only skin deep, though, we worked up some fantastic stuff under the covers. I could try to enumerate a lot of it, but well, take the most productive people I have ever worked with and put them in overdrive for two months on a feature driven release. Use your imagination.
Anyway, that is out. Woot! As exciting as this is, the more exciting is the foundational work that has been laid for what is coming. Open source work has been being short-shrifted for me lately because, well, my day job is too fun =)
0 writebacks [/work] permanent link
AspectJ resurged over on TSS and one comment reminded me of the singly most useful thing I've done with it for production purposes: used it to augment a very large third party library. This, of course, is a taboo thing to do, but if the library you are mucking around with is, er, the AspectJ compiler... maybe it is okay?
At the time, anyway, the AspectJ compiler had a useful incremental compilation mode where it would keep metadata in memory and basically have a server compiler process. This is fine and dandy if you don't mind hitting the space bar to do an incremental compile. It turned out to be far easier to instrument the compiler to have it take input from a tcp socket so that an ant task could kick off the incremental compile from IDEA =)
Probably not what people would consider good but it reduced compile time from minutes to seconds =)