Before I start, a big thank you to Max over at the Hibernate User forum for helping me out. The quality of the code is only ever half the reason why open source tools are the best way to go. The other half of the reason is Max, and people like him, ready to help out a complete stranger. Thanks, Max. ;-)

Anyway, what I've been busy with over the last few days is building some mappings from Hibernate to an existing legacy, err, sorry, I mean a vintage database. Hibernate is lovely. Lovely lovely lovely. But I think it's fair to say that there's a lot more work involved in mapping to an existing database than there is if you are able to just let Hibernate get on with its thing and create its own schema.

The, err, vintage database is a quarter of a century old, most of it. It's not in bad shape - I've worked with a whole lot worse - but obviously it's not put together with modern best practices in mind. Loads of natural composite keys. Sigh. Also, the data types available at the time the system was first build were quite limited. There were no booleans or datetimes available, for instance, so these are stored as CHAR(1) and DECIMAL(7,0) columns respectively, so I've had to put together my own custom user types for these. Just to make life that little bit more painful, not are the only are the dates stored as seven digit numbers (in CYYMMDD format, where a C value of 0 is for last century, 1 for this - common practice on a '400), but they can also hold all zeros or all nines!

It's an iSeries (a.k.a AS/400) DB2 database, which Hibernate supports up to a point, but what I'm going to do when I come up against platform specific things like multi-member files I don't know. I'm sure I'll think of something.

There are also a few tables with no unique keys. That's really no unique keys - it's valid for there to be multiple identical records. I'm pretty sure I'll have to go back to plain old JDBC for those tables. Thankfully, this isn't common. Even twenty five years ago it was obvious that that was a bad idea!

I'm off to work out how to do a one-to-many relation where both sides have composite keys...