[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1169) HiLoGenerator uses ints even if the id is a long

[Tim Stavenger (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33433#action_33433 ] 

Tim Stavenger commented on HHH-1169:
------------------------------------

While it may be acceptable to use an integer for the high value in a hi/lo algorithm, I thought part of the purpose for the org.hibernate.id.TableGenerator and org.hibernate.id.enhanced.TableGenerator classes was to be a super class for other IdentifierGenerators?

If that is the case, I would expect that these classes should really return Long instead of Integer, and use the getLong()/setLong() methods as Rich posted. That way sub classes can work with a Long and cast down if they need to rather than attempting to cast up like they would have to now.

I've already run into the same problem. I was hoping to subclass one of these classes and specialize it for my ID generation needs. However, since both return Integer instead of Long, I've had to basically copy/paste them into my class and then modify the code to return Long so that I don't lose the full range of numbers available for my IDs.

> HiLoGenerator uses ints even if the id is a long
> ------------------------------------------------
>
>                 Key: HHH-1169
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1169
>             Project: Hibernate Core
>          Issue Type: Bug
>    Affects Versions: 3.1 rc2
>         Environment: rc2.
>            Reporter: Rich MacDonald
>
> Say you're using longs for your primary keys. Looking at the TableHiLoGenerator class, the generation goes through a step in which it is converted to an int. The particular method is:
> TableGenerator.doWorkInCurrentTransaction(Connection conn, String sql)
> Within this method, we perform the select query to get the next value, then perform the update to increment the counter. However, we extract the select query resultSet with:
> result = rs.getInt(1);
> And we update the query with:
> ups.setInt( 1, result + 1 );
> ups.setInt( 2, result );
> "Casting" longs though this int step is a bug. Instead, these get/set methods should be delegated to the IdentifierGeneratorFactory class (which has a get method but would need a set). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira