I'm investigating implementing an O/R tool, such as Hibernate or Castor, against a fixed, legacy, IBM AS400 schema. What are the database prerequisites when applying such an O/R tool (row Ids, etc)? Is an O/R tool a good decision, as opposed to straight JDBC, when I don't have much control over the schema? Any help is greatly appreciated.
Originally posted by Franco Finstad: What are the database prerequisites when applying such an O/R tool (row Ids, etc)?
Good tools have few prerequisites. There are four possible problem areas that I can think of. First, I don't know anything about AS400 and cannot comment on its compatibility with Castor, Hibernate or any other tool; I assume you already checked out whether it would work. Second, if your database has composite (multi-field) primary keys, the last time I tested Castor's support for this it was still a bit immature. That's a while ago though. Not sure about Hibernate. Third, if the database schema has a few odd corners it's possible that you will have to tune your object model a bit to fit the database schema and the O/R tool's restrictions. Finally, if the schema uses some oddball primary key generation scheme then you may have to write some code to plug that into your O/R tool. Other than that, I wouldn't expect too many problems.
Is an O/R tool a good decision, as opposed to straight JDBC, when I don't have much control over the schema?
Probably yes. One of the nice things of an O/R tool is that it forms an abstraction layer between yourself and the schema, and can to some extent isolate you from changes. This is probably not an issue as I suspect your schema is very stable. Another is that it can sometimes isolate you from oddities in the schema. This can be valuable. Finally, it allows you to think and develop in terms of an object model, which tends to come more naturally to Java programmers. I'd say it's worth testing out. Be sure to pilot it first in the weirdest corner of the schema you can find. - Peter