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

Description

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.

Environment

Windows XP with all service packs and patches.

Activity

Show:
Steve Ebersole
November 17, 2006, 7:09 AM

Not gonna do this.

Why does access="field" not suite your needs here?

Jim Showalter
November 17, 2006, 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.

Max Rydahl Andersen
November 17, 2006, 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.

Steve Ebersole
November 17, 2006, 9:28 PM

Sounds like a job for a Tuplizer to me then (read the docs)...

Jim Showalter
November 17, 2006, 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!

Rejected

Assignee

Unassigned

Reporter

Jim Showalter

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Affects versions

Priority

Major
Configure