Thursday, February 05, 2009
How to get Hibernate parameter bindings and ONLY parameter bindings
With that out of the way, if you search around with Google and look for information on how to get the parameter bindings for SQL statements executed by Hibernate (which brilliantly are not given if you turn on SQL logging; see also: "mule shit"), you'll see a lot of smartass answers like setting
org.hibernate.types=debugin your log4j configuration.
While that configuration change does include the parameter bindings, it also includes a giant shit-pile (mule) of extra data that you probably couldn't possibly care less about, including every time Hibernate binds a return value to a type. These different messages cannot be immediately differentiated by severity or by type (see also: "gimpy").
There is a mostly-workable solution, provided Hibernate has implemented/continues to implement their debugging messages in a consistent fashion:
<appender name="SQLparams" class="org.apache.log4j.ConsoleAppender">
<param name="Target" value="System.out"/>
<param name="Threshold" value="TRACE"/>
<param name="ConversionPattern" value="%d %-5p [%c] - %m%n"/>
<param name="StringToMatch" value=" to parameter: " />
<param name="AcceptOnMatch" value="true" />
<filter class="org.apache.log4j.varia.DenyAllFilter" />
<appender-ref ref="SQLparams" />
This filters the log4j output of org.hibernate.type.*, including only the lines that contain the text " to parameter: ". This will of course also include constants coming back from your database that include the phrase " to parameter: ", but chances are this will usually be good enough, unless or until Hibernate pries its overinflated head out of its ass.
Sunday, November 04, 2007
Time for a Divorce
That got me to thinking: a lot of us developers use a lot of open source software. How do we choose which packages we want to use? Obviously whatever we choose has to be a good technical fit for our needs... what's the point if it doesn't do the job we're after? But now it occurs to me that open source software has to meet a particular social need as well. One way we can gauge a project's health is by how strong it is socially. How interested are people? Is the project active? Are people excited about the project? Excited enough to fix bugs?
It's a little hard to compare apples to apples in this case, but let's look at a couple things and try to relate them as best we can. Toplink Essentials is maintained as part of the Glassfish project.
In the last 30 days at the time of this writing, the folks working on it have fixed 10 bugs. In that same amount of time, 15 bugs were opened (or changed and left in an opened state). About 53 messages have been posted on the discussion forum. The oldest unresolved bug has been open for about a year and 10 months.
In that same amount of time, the OpenJPA folks have resolved 19 bugs while 20 have been opened. The mailing list has had about 215 posts. The oldest unresolved bug is a year and 4 months old (though it was touched 3 months ago). OpenJPA is using Jira which makes it a bit easier to produce meaningful metrics such that we can find that the average unresolved age of a bug in the last month is about 3 months, which has been fairly consistent.
(I gave up trying to compute the average unresolved age of bugs for Toplink Essentials. It's just too annoying to figure out if the bug tracking tool doesn't do it for you.)
It is probably the case that most open source projects (and probably closed ones too) have a few ancient bugs gathering dust. I think that it's more interesting to look at what a project has been doing recently, like in the last 30-180 days. Are they keeping up with their bug backlog? Is there an active community? Are you likely to get help if you ask for it? Of the bugs that come in, what percentage get fixed and what percentage get dumped in the attic?
And perhaps the most important criteria of all: are they fixing MY bug?
While I wasn't watching, OpenJPA reached a 1.0.0 release. It's available under the Apache 2 license from a Maven 2 repository. They fixed the bug I opened earlier this year (within a day even). It is full-featured and even has an extensive manual. Though, like Toplink, their ant task doesn't work very well.
I used to be concerned about the large number of dependencies that OpenJPA has, but now that the project is building with Maven 2, it's much less of a concern for me. It isn't necessary to go manually fetch anything to build the project, since Maven 2 takes care of all the direct and transitive dependencies. One thing I did have to manually tweak was to force inclusion of commons-collections 3.2 in my pom.xml, because something else in my project depends on an earlier version of commons-collections, and OpenJPA needs a later version.
So it's time to give Toplink one final heave-ho. My reasons for sticking with it have now been outweighed by my need of having compile-time weaving that works and a project where problems are likely to be fixed within my lifetime. It's time for Toplink and I to start seeing other people.
New releases of Tally-Ho will be using OpenJPA as the persistence provider... just as soon as I get all the unit tests passing.
Subscribe to Posts [Atom]