Tell me where I'm wrong in this line of reasoning:
Calling save doesn't actually save right away. Instead, the object is just put into the Hibernate Session and scheduled for a save. So, you could still change properties of that object, and Hibernate won't save until you're done. Or, you could just delete the object before the transaction is committed, and Hibernate can just never add it at all, avoiding a needless database interaction. So, the id doesn't actually get set in the object until the transaction is committed. I'm not sure if the API promises to initialize the id before the commit.
Here's what the JavaDoc for the Hibernate Session says:
Persist the given transient instance, first assigning a generated identifier. (Or using the current value of the identifier property if the assigned generator is used.)
apparently, this has nothing to do with my hbm file, flushing/saving or postgresql. I created a test project with spring and hibernate, and tested on the same hbm file object and table/sequence. the id gets set after
So only one route left: It must have something to do with Jboss and ejbs. I don't know exactly what is not permitting the id's to get set, but the version field (which is used by hibernate) does get set on object with a version.
I am still investigating
posted 11 years ago
Well finally, I figured out what is happening,
I perform the save from inside an ejb, and the id is set as soon as the save call is made.
however as soon as I leave the ejb (back to the client ), the id disappears!!
Here is the scenario:
unit test calls ejb to save an object.
id is set inside ejb.
unit test checks if the id is null or not.
id is null.
...i guess it has to do with how RMI works, but don't have a clue how to get the id to persist in the unit test.
incandescent light gives off an efficient form of heat. You must be THIS smart to ride this ride. Tiny ad:
Devious Experiments for a Truly Passive Greenhouse!