Quote:
Thank you for your reply: it lets me understand why hibernate behaves this way. It is to comply with EJB specs.
Huh? Hibernate != EJB. It doesn't conform at all to EJB specs... it is an entirely different framework (unless you consider the relationship between hibernate and EJB3 :-) )
Quote:
The problem arises with some lookup-table. Something like Currencies, in example, which is made of a 3-char id (EUR, USD, AUD, ecc.) and some other infos. Or even Languages, identified by a 2-char id. This kind of ids may be seen as quasi-immutable, but sometimes (probably as a consequence of a previous user error), they may need to be changed. It is not really a change in business semantic of the persisted object, it is just a fix.
To me this is a very different problem. I would suggest that if these are truly "quasi-immutable" -- meaning you almost never change them -- that you simply perform the necessary updates using a generic database/SQL program and then, if you use the second level cache for these objects, simply restart it to avoid any cache-concurrency issues. Of course, this assumes that you have the CASCADE UPDATEs you mentioned. (The database I work with most (DB2/390) doesn't offer this :( ).
Quote:
I see now that Hibernate is more close to the ejb layer than to the jdbc one
If you are saying that hibernate is more similar to EJB CMP entity beans than to JDBC, then yes, I agree. Both are ORM solutions, whereas JDBC is a data access API for SQL databases. The two are not exactly mutually exclusive: both EJB CMP beans and Hibernate use JDBC for data access.
Quote:
On the contrary, EJB didn't approach the "immutability problem", leaving its solution to the developer. The fact that Hibernate follows the EJB trail in this enforces a pattern even when it would be less than an issue (ie.: when ejb technology isn't involved at all).
Aside from the OID solution (which is implemented differently/not at all in different RDBMSs), it is worth arguing that this
is an issue, even when we don't use an ORM layer. Consider a concurrent system (i.e. web app) where two users are working with the same row in the database:
- We have a table containing key/value pairs, where the key is a mutable two-char code, and the value is a string description.
- User1 requests an update page for the row identified by "AB".
- User2 requests the same page for the same row.
- User2 changes the key of the row from "AB" to "AC" and submits his changes. The database is changed with:
Code:
UPDATE VALUES_TABLE SET KEY = "AC" WHERE KEY = "AB"
1 row is updated.
- User1 changes the description of the row from "A bird" to "A cat" (stupid example, but you get the idea). Remember, he still has a "reference to the "AB" row. An update is attempted with:
Code:
UPDATE VALUES_TABLE SET DESCRIPTION = "A cat" WHERE KEY = "AB"
0 rows are updated.
We are working without an ORM layer, but we still face a problem with mutable IDs. ORM simply forces you to face the problem during design.