I am helping to architect a new application that uses a somewhat legacy RDBMS (as well as some existing legacy databases). The current databases often use special values (generally zero or an empty string) to represent what would normally be considered a null to us Java folk. The DBA wishes to continue this practice for performance reasons as well.

We are considering a number of persistence frameworks to use for this project, and I have spent considerable time researching hibernate (one of the front-runners in my mind). However, I have not been able to find any information relative to this topic. Obviously, I could simply map the said field directly into the java class and "know" what the value means, but I would much prefer to represent it as a null.

This is further complicated when a field is a reference to a row (or rows) another table (note, these would not be references in the relational sense, as the table being referred to would not contain a corresponding row with the special value and thus no referential integrity constraint could exist). If I want to simply map the property (using a component property, perhaps), I can't use the 0 as it would be the wrong type (Integer vs. PhoneNumber, for example).

Is there any way to "translate" a special value to a null in hibernate?

(side note: I don't intend for this to be a thread on programmatic best practices. I have recognized that this is the use of "magic numbers", and I hate it, but I have little control over that side of things.)

Thanks in advanced!

-Aaron

A clarification from my DBA:

Nulls associated with foreign key relations will be allowed. But a value (for example a customer's middle name or medicaid number) will be decaled NOT NULL with a declared DEFAULT (i.e. an empty string or a zero).

This takes care of the issue where one table is related to another (one-to-one, one-to-many, etc..), but the other question still remains: if I want to transparently make my customer's middle name null in Java but an empty string in the database, can hibernate support this?

You should look into using Hibernate UserType's. See section 6.2.3 in the Hibernate Reference documentation.

Sanjiv

Ick... okay, that answers my question, I suppose, though I wish there was a simpler way to handle it.