I'm working on a database that has DECIMAL fields as (currently manually assigned) primary keys. The manual assignment is done as a result of some SQL that just does something like this : SELECT MAX(ID)+1 FROM TABLENAME

I want to use hibernate to autogenerate these keys. In the short term I can't change the database to redefine these fields as IDENTITY fields.

Any ideas ? I'd use HILO but that is incapable of returning a DECIMAL, and also I am warned off it by the statement "Do not use this generator with connections enlisted with JTA or with a user-supplied connection." in the documentation.

In the long term I'll change the databse keys to be identity fields, but I still can't change the type from DECIMAL to something more sensible, and HIBERNATE only returns long, short or int for identity fields, so I am stuffed there as well.

In the short term all I can think of is to use "assigned", which is the worst case, most coding scenario.

"increment"

Thanks for the super speedy reply.

"increment - generates identifiers of type long, short or int that are unique only when no other process is inserting data into the same table. Do not use in a cluster. "

Our application is clustered......

As what I'm doing at the moment is R&D only, I'll give it a try as a stop gap solution to save me changing all the ID types to long.

Does the fact that increment returns long, int, or short matter when our keys are decimal ?

If everything else fails, coding your own Generator is always an option.

OK, I've tried the increment generator, and looking at the source code, its pretty much doing what we are currently doing manually in our EJB based, non-hibernate project.

However, after the increment generator has found out what the new key value should be, it calls IdentifierGeneratorFactory to create the ID object to return.

Unfortunately, and I think this can be perceived as shortcoming, the IdentifierGeneratorFactory is currently only coded as such "this id generator generates long, integer, short"

Shame really, I'll have to create a new generator, that is 99% the same as the increment one, apart from calling a modified version of IdentifierGeneratorFactory that is capable of returning a BigDecimal.

Who do I ask to get this changed in the next version of hibernate ?

PS Hibernate is fantastic. I reckon 60% of our application is just persistence code. After Hibernate is set up we can probably half our code base !

We won't change it: You have a special case. It is perfectly acceptable to write a patch/new class for this. Thats the whole point of open source software, giving you back control.

If you think others could use your patch, put it on JIRA and let them vote. (Note that the LGPL _requires_ that you do this if you rewrite parts of Hibernate, not if you subclass or implement an interface). However, I've never seen a similar case like yours before, so I doubt it will someday be in Hibernate.

[quote="christian"]We won't change it: You have a special case. It is perfectly acceptable to write a patch/new class for this. Thats the whole point of open source software, giving you back control.

I've got no problems in writing my own generator, but it does seem a bit pointless to have to basically copy all the increment generator code to do this, when all that actually needed adding was this:

else if (clazz == BigDecimal.class)
{
return new BigDecimal(value);
}

What does the increment generator do ? Finds out the largest value of a numeric field on a file, and adds 1 to it.

Add the end of the day, SQL supports a number of different field types that are capable of holding integers, and these include NUMERIC and DECIMAL. For historical reasons if nothing else a lot of people use NUMERIC and DECIMAL fields on databases (particularly in the IBM DB2 world), and are stuck with that

All I was wondering about was why the increment generator supported a subset of integral SQL types, rather than the whole lot.

I don't think my case is a special case at all by the way.

PS, my big_deciimal compatible version of increment does the trick, so thanks for the initial hint !

On a final note on the "yours is a special case" comment, please see

http://opensource.atlassian.com/project ... owse/HB-92

which is pretty similar, saying that hibernate only supports identity columns, of long short and int, when it should support whatever the idenity column type is.

I'll log something on JIRA about this issue.