The OpenLogic Technical Support Team fields lots of questions on Hibernate and over 500 other open source packages. They’ve distilled decades of experience and hundreds of Hibernate support issues down to the most common questions.
| General Questions | |
|---|---|
| We just upgraded to Hibernate 3.2.5 and we’re suddenly exceeding available cursors. We presume this is what is happening because we’re encountering a “max cursors open” issue in some areas of our system. | This is a known issue and is fixed in version 3.2.6. OpenLogic recommends that you upgrade to the newer version, which is available for download in OLEX.
If you are unable to move to a newer version, the code can be patched using code from the 3.2.6 release. Several patches are needed to update your instance of 3.2.5 code to function like version 3.2.6 code. The following links provide access to the relevant code fixes necessary to resolve this issue.
|
| I am having an issue with the way Hibernate is translating my HQL into SQL. This issue seems to be a bug in Hibernate. | This issue has been reviewed by the Hibernate community and is not considered a bug. Rather, it’s a misunderstanding of how HQL should be written to work with SQL. Hibernate has, however, provided some information on how to work around the issue. Check out the workaround information available from Atlassian. |
| We have a question regarding Hibernate mapping for composite keys. Whenever we try to map composite keys, we get exceptions. Is there a way to map the tables using Hibernate and avoid mapping exceptions? | When defining a composite-id for a persistence-capable Hibernate object, your goal is to identify all the columns of a table (attributes of the object) that are necessary to uniquely identify the thing the object/table represents.
So, when you define a composite-id element of the “someclass” class as follows <COMPOSITE-ID> <KEY-PROPERTY name="column1" column="column1"> <KEY-PROPERTY name="column2" column="column2"> <KEY-PROPERTY name="column3" column="column3"> <KEY-PROPERTY name="column4" column="column4"> <KEY-PROPERTY name="column5" column="column5"> <COMPOSITE-ID> what you are saying is that a ’someclass’ object is always and forever uniquely identified by examining the contents of the following columns: column1, column2, column3, column4, column5. In other words, if all the values of those 5 columns appended together turns out to be ‘ABCDE’ (column1 = ‘A’, column2 = ‘B’ and so on), we ought not to have another row in that table in the database that would result in ‘ABCDE’ if appended together. Since you’ve defined the composite-id for the ’someclass’ object in this way, Hibernate expects any other class that maps to this one (in other words, creates an association of some kind) to declare those exact same columns in its mapping. Here are two examples: A “many-to-one” example: <many-to-one name="many_name"> <column name="column1" /> <column name="column2" /> <column name="column3" /> <column name="column5" /> </many-to-one> A “collection” example: <set name="collection_name" inverse="true">
<key>
<column name="column1" />
<column name="column2" />
<column name="column3" />
<column name="column4" />
<column name="column5" />
</key>
<one-to-many class="someclass" />
</set>
The Hibernate documentation warns that you ‘must override equals() and hashCode() to implement composite identifier equality. It must also implement Serializable.’ Trying to define multiple composite-id’s for the same object simply doesn’t work, in that it would be akin to defining the ‘equals()’ method in two completely separate and distinct ways for one class, which is not even possible. Once you define a composite-id for a particular class, the exact columns used in this definition must be those used when mapping other objects to the original object you defined the composite-id. |
