Thursday, April 30, 2009

Handing over the keys...

I'm generally not a fan of systems where the computer tries to figure out what you 'really want to do'.

But, I have gotten to a point in my life where I might be open to the idea that it is possible for a development environment to guess correctly.

And so, I am beginning to try out Drupal.

If things work out, then it will make my development of sites easier (I'll still hand code my web -apps- at least for the time being).

Taking a deep breath....

And off we go.

Doc, it hurts when I...

Normally, I would say that if something hurts - you should stop doing it.

But, I didn't know how badly I was hurting myself when I created multiple versions of all of my JPA entities depending on the depth of data that I wanted to have fetched.

So, fixing my app to use FetchGroups (an OpenJPA feature) to do what I had hacked together has been (and still) is a fairly painful process.

I first have to find each place that needs to have a custom fetch group defined and then add to the fetch group until it contains everything that I need.

Once I have it set up correctly though...It is a beautiful thing.

Fast, clean, and obvious what is going on.

Thursday, April 2, 2009

That was painful, but worth it...

Last week I found out about a feature that the OpenJPA folks put into their implementation of JPA. But, it is not part of the standard.

That feature is custom fetch plans - And, I think I can safely say that they are my newest favorite thing.

The reason that these are exciting for me personally is that I use JPA to pull data from my back end database that is then converted to XML using JAXB and sent to a browser for processing/display. If I were to transform a completely populated 'top-level' entity, then I would be creating an XML document that could be several Mb.

Over the past year, JavaScript engines have gotten faster - and continue to do so. But, trying to make JavaScript parse and manipulate blocks of XML data that are that big is not a nice thing to do to the browser (or the user).

Until this past week, I thought that I would need to create tailored versions of my JPA entities in order to send back just the part of the XML that I actually needed. Then, I found out about (Cue choir of angels) dynamic fetch plans.

What dynamic fetch plans do is allow you to specify which fields and relations are eagerly fetched at the time that you execute the query. That may not sound particularly earth shattering - but give it time to sink in.

You are able to specify down to the individual database column level exactly what will be pulled from the database (and/or specify the fetch depth). When doing JAXB processing, this allows me (and you if you need it) to tailor the exact data that will be turned into XML.

One poignant example of how this can clean up the XML sent to the browser is to send a list of top level entities for listing in a drop down. The only data that really needs to be sent back is the entity key and description. Without custom fetch groups, JAXB would try to build the entire fully populated entity tree for each entity. The amount of data being sent back to the browser would be insane! My previous solution of creating an array of JPA entity beans in order to define every possible grouping of desired fields was also insane. I picked a middle ground of an overly populous graph that small enough/big enough for most uses and a sparse graph that would be super quick but only useful in one or two cases.

Now, I have been able to remove all of the extra Entity beans. I have simplified the definition of my entity relationships and removed the possibility of missing changes if I change the actual table structures. Plus, I am able to exactly specify what I want to send back in each situation (anywhere from fully populated entities to single fields).

I just wish I had known about them two years ago when I first started using OpenJPA. It would have saved me a lot of refactoring and testing (at a time that I really can't afford to spend the time). But I am glad that I managed to 'stumble onto' them. I didn't really go looking for an EJB 3 entity manager - I just used the one that came with Geronimo. If I had shopped around, I might not have given this the weight it deserves.

And it is -huge-. Not only can you pare down an overly generous eager fetch - you can also expand an excessively lazy fetch - at runtime with very little programming cost.

By the way, the painful part is trying to undo two years worth of hacks to accomplish something that was included in OpenJPA - in five days.

I think I used to sleep - didn't I?