Resetting of properties after initial set violates constraints we want to protect
Description
Activity

Jim ShowalterNovember 17, 2006 at 9:30 PM
We need merge because we're using disconnected objects because we have a distributed deployment. Which of course also breaks lazy load, but that's another problem.
Merge == init + changes == set more than once, but we handle that by allowing setting to the same value as many times as necessary.
We'll look at Tuplizer. Thanks for the lead!
Steve EbersoleNovember 17, 2006 at 9:28 PM
Sounds like a job for a Tuplizer to me then (read the docs)...

Max Rydahl AndersenNovember 17, 2006 at 9:25 PM
so use access="YourTopSecureSettingAccessor" that only set things once...but then you of course can't use merge() which by its nature requires init + changes.

Jim ShowalterNovember 17, 2006 at 9:18 PM
If hibernate can access fields directly, then so can anyone/anything else. If they can do that, then the constraints aren't protected. So field access is deliberately shut off in the security manager. So access="field" doesn't work.
Think of hibernate in the context of a high-security application. For example, a banking application. We don't want malicious code to be able to call a method to change a person's account balance. But we have to allow hibernate to set that balance when it reads an object back from the database. So we have to allow the balance to be set once by hibernate. But we don't want anything that isn't authorized to do so to set that balance again.
Steve EbersoleNovember 17, 2006 at 7:09 AM
Not gonna do this.
Why does access="field" not suite your needs here?
Details
Assignee
UnassignedUnassignedReporter
Jim ShowalterJim ShowalterPriority
Major
Details
Details
Assignee
Reporter

We have properties on objects that are supposed to be set only once, when first reading an object back from the database. Once in memory, they are not supposed to be set again, and attempting to do so is supposed to throw an exception. Unfortunately, hibernate's behavior appears to be less predictable than we had thought. It assigns properties more than once. For example, when merging a disconnected object, it loads one from the database (thus setting the properties), and then sets them again from the other object, thus violating the set-once rule. There are other cases similar to this. We modified our rule to allow setting to null (or some other value indicating not-yet-set) as many times as desired, then setting to some actual value, and allowing setting to that same value as many times as desired. Setting to a different value once set throws an exception. This seems to pacify hibernate, but we're not certain that it will work in all cases, and the behavior of hibernate as far as resetting properties is concerned is undefined. Our request is for hibernate to be enhanced to have a notion of set-once, which would be stated in the HBM file. This would make a property immutable, with the sole setting of that property to be done on reading in from the database. On save, a set-once property would be assumed to have already been set--hibernate would not set it itself when saving, only when reading.