Rocket Surgery

Well, this may turn a number of you off and make you think I’m some sort of Luddite or something, but I have come to a considered opinion:  I don’t really like Hibernate.

Before you consider me an ignorant fool, here are some of my reasons for you to consider (and I may add to this list over time): Read the rest of this entry »

At my workplace we’ve started writing JUnit tests to monitor our systems and the systems of the other departements. One unit test pings all the servers we talk to or administer; one does an HTTP get from all the web servers we run, as well as the servers whose web services we call; another test does a quick query against all the databases we hit. We’ve set these JUnit tests up in Hudson to run every ten minutes; one failed test makes the project go unstable, and we get notifications by email and get on top of problems before the other departments notice it. They have their own monitoring software, which is pretty good, but we aren’t given access to it, and this way we get independent confirmation of what they are checking on.

We got this idea from something similar we did at a client of mine in a previous gig. To do cascading delete referential integrity, the DBA’s needed^* to use a delete trigger. Well, any time they made a change to the underlying table, they had to take the trigger off, make the change, then put the trigger back. Guess how often they remembered to put the trigger back. Anyway, we got so tired of them forgetting this and having to fix stuff all the time, that we wrote a unit test to make sure that deletes always cascaded like they were supposed to. Anytime they didn’t, we knew they dropped the trigger, and we got on the phone and fussed at them.

So, on the agenda for our suite are other neat things, such as connecting to our Dev, QA, and Prod databases, grabbing the metadata, and looking for subtle differences like missing indexes from one environment or another. We plan to make sure that the JBoss configuration files (such as connection pool definitions, system properties, JVM memory settings, etc) match what we have saved a copy of so we can tell if someone changes the server’s configuration without telling us about it. We’ll check Java versions, OS versions, etc. Anything that is external to our apps that can affect the success of those apps, we’ll make tests for it. We’ll have executable documentation of our assumptions.

After all, the real purpose of a JUnit test is to assert that something is true; and if it’s not, you’ve got a problem. Nothing says that what you assert to be true has to be the behavior of code — it could be almost anything.

^*I seriously doubt that they had to do it that way, but that was the way they insisted on doing it.

Those of you who have used Hibernate probably know that the connection pooling solution c3p0 comes with it.

Pity.

C3p0 has a number of default settings that Hibernate does not allow you to control directly that are downright dangerous in a production environment: Read the rest of this entry »

One of the things I have always liked doing when working with Hibernate is to use a JUnit test to run SchemaValidator against the hibernate configuration. In case you aren’t familiar, the SchemaValidator that comes with Hibernate compares the beans, the database metadata, and the Hibernate configuration and throws an exception if any discrepancies are found. By calling it from a JUnit test, you can know immediately if someone has changed any of the three pieces and broke it.

Well, today I was trying to do just that with a Microsoft SQL Server database that had tables with uniqueidentifier columns. This is a MSSQL datatype for GUIDs of the form {12345678-9ABC-DEF0-1234-56789ABCDEF0}. There is no built-in Hibernate mapping specifically for this type, although using a String in the Java object works just fine–except when using the SchemaValidator. The SchemaValidator notices that the java field is mapped to “varchar” and the database field is of type “uniqueidentifier”, which of course doesn’t match. When I modified the .hbm.xml file to specify the types on both sides explicitly, the JDBC driver threw SQLExceptions that the types could not be converted.

Anyone have success with this?

I ran into a “gotcha” with Hibernate this past week.

I was working with an Oracle database where there are tables with synthetic (aka surrogate) keys that get their values from sequences — a fairly common thing, and a situation that Hibernate normally handles well with identity generator class of “sequence” or “native”.

But in this case, the Oracle database was using a before-insert trigger to get nextval from the sequence and stuff it into the primary key field before inserting the row into the table. The rationale for this was to ensure consistent management of the sequence for other code than the Hibernate/Java system that might hit the database.
Read the rest of this entry »