Using Hibernate 2.1.7...

I'm porting a legacy persistence framework to hibernate. We have a lot entities with natural keys and to-one relationships to these tables from other entities. If I want to create an many-to-one association to this table and also be able to access the foreign key value without fetching the related entity, the only resolution I can find is to have one of the two mapped as insert=false update=false. I currently have the association mapped as insert=false, update=false, which seems to work better than doing it vice-versa.

The problem is that it's causing me a great deal of grief trying to manage two different ways to set what amounts to the same value. For example, if they call setFoo( Foo value ) and then call getFooId(), the getFooId() method will return an old value or null unless the setFoo() method is written to keep the other value in synch.

FYI, we are using hbm2java to generate the code, but I have a custom renderer to try and fixup some of these issues. However, generating code to keep the foreign key value in synch when they set the association property seems tedious and messy.

Am I totally off-base here with what I want to do? Anyone else with a similar situation?

~Aaron

Do you know you can access the foreign key value without loading up the associated entity? Just map it as lazy and call .getId() on it - getId() does not break Hibernate proxies ...

Yeah, that's something I looked at doing. One of my problems (which is obviously not hibernate's fault) is that I have an existing 500,000 line codebase and the code breakage is fairly heavy. I was just looking for the easy way out :)

Another issue is that we want to use the persistent entities as DTO's on the web tier. Many times the natural foreign key needs to be set on the DTO and it's not an option to do a session.load() to fetch a proxy. I suppose in those cases, it might be possible to just create a new instance of the foreign entity, set the key directly, and then associate it. As long as no cascading is enabled, that might work AFAIK.

Thanks for the input.

~Aaron