That’s probably the wrong metaphor. Since it’s Hibernate, something bear related would probably be more appropriate…
I’m wandering through the Hibernate forest, trying to avoid what a bear does in the woods.
Blech. Okay, I’ll work on it.
At any rate, after spending a fair amount of time on the Generic DAO pattern as implemented in Hibernate’s Caveat Emptor application, I see much more clearly now how all of that is supposed to work. I still need to play with the automatic code generation tools, because while I was able to adapt the pattern for my own, four-table sample application, it’s hard to imagine going through all that for 150 tables or more. I have to say, though, that I’m not wild about the tools that generate code from an existing database schema. Databases may be powerful and all, but they just don’t have the semantic information needed to make a good object model.
For example, databases don’t understand the different between a one-to-one relationship through a foreign key and a one-to-many relationship. If the two can be combined (as they are when you save address data in an employee table, even though they’re likely to be separate classes), there’s no real problem. But if each side can exist independently, you’ve got a relationship whose multiplicity can’t be easily inferred.
In my sample schema, we’ve got tables called EMPLOYEES and DEPARTMENTS (and a few others, of course). There actually are two relationships between these tables. One is that a department holds many employees but each Employee belongs to only one Department. That’s clearly a one-to-many relationship, or many-to-one depending on how you look at it.
(I’m not considered the “matrix management” system that was adopted during my last couple of years at UTRC. I went from having one boss to having seven. That was fun.)
The other relationship is that each Department is managed by a single Employee. That’s effectively a one-to-one relationship between two separate entities.
Hibernate can model that, of course. Actually, it’s pretty easy to do. The thing is, though, how does the database tell Hibernate that one of those relationships is one-to-many while the other is one-to-one? I used the good old unique=”true” attribute, but the database doesn’t know by itself. It’s not like it checks all the values of the foreign keys looking for a duplicate. That’s part of the metadata (ack, I used a meta word in a sentence) associated with the schema, not the schema itself.
Another issue that came up is directionality. A department knows who its employees are, right? Does an employee also know which department she belongs to? Probably, but you can go either way on that (yes, I know, bad directionality pun — Sorry). Again, it’s not terribly tough to model, but I have a hard time believing an automatic code generator will guess correctly the first time.
Incidentally, in my case it wasn’t as easy to model as I thought. I’m doing the old “meet in the middle” use case, where I have existing classes and an existing schema and am trying to make them match. That’s been a bit of an adventure, but it’s starting to make sense. My employee class had an attribute called managedDepartment, but the EMPLOYEES table didn’t have a column for that. Instead I used
<one-to-one name="department" property-ref="manager" />
to make it all come out right. I hadn’t used property-ref before and wasn’t sure what it did. Now I know.
I’m still learning tons. I’m fond of the Criteria query capabilities, because even though they get pretty sophisticated (read “complicated”), it still beats intimate knowledge of SQL. I think.
Leave a Reply