I have been in an email debate about this, but have got no where, so I'm raising this in the forum, so that others can contribute.

Here are the facts:

Regardless of whether this is a sensible situation or not, all the ID fields on a database I am dealing with are defined as DECIMAL (11,0). Now you can debate the rights and wrongs of this, but to me there are two things of note:

1) I cannot change this situation, its a database I am stuck with, however stupid people may think it is to use DECIMALs as id fields

2) Obviously the designers of DB2 acknowledge the situation, as they support the use of DECIMAL as an identity field.

We do not use hibernate at the moment, so we determine the next key by ading one to the maximum key value on the file. This is the same concept for generating keys as the hibernate increment generator.

All our business objects hold the equivalent ID fields as BigDecimal. At the moment we manually map between these and the databse, which is why we want to use hibernate.

In the short term as part of an R&D project I decided to use the increment generator. In the long term I'll get the database changed to make all ID fields identity fields and then use the native generator.

Anyway I found out that the increment generator only supports ID fields of short, int and long. This is down to the IdentifierGeneratorFactory class only supporting the aforementioned field types.

I raised an ISSUE on JIRA to change this so that it supported BigDecimal as well. After all, the increment generator is supposed to just return the current maximum key field plus one, who cares what format the number is in as long as its an integer, and that includes DECIMAL or NUMERIC database fields with a scale of 0.

As a stop gap solution I wrote my own custom generator that effectively just adds BigDeicmal to the list of allowed return types. I'd far rather see the increment generator support NUMERIC and DECIMAL properly, and indeed an as yet unactioned patch, http://opensource.atlassian.com/projects/hibernate/browse/HB-92
does the job a lot more elegantly than my bodge.

Do people think my suggestion is a reasonable one ? I was pretty unimpressed that my JIRA issue http://opensource.atlassian.com/projects/hibernate/browse/HB-1138was closed with the one liner : using a non-integer type for a surrogate key makes no sense

Wait a second: You have a special case (easy to see, no one else ever asked for this). You implemented your special case using one of Hibernates extension interfaces, 10 lines of code, no problems. Thats what is was made for.

And now you make a lot of noise because your special case will not make it into the Hibernate distribution?

No Christian, it is not a special case that's the whole point.

The point is that the increment generator doesn't support all valid SQL types that support integers.

Did you know how many potential users of hibernate had files with primary keys of type short ? Did you think it was more or less than int or long ? Of course not, support for it is there because it was a valid possibility.

In the IBM mainframe and AS/400 iSeries world, PACKED aka DECIMAL aka BigDecimal field are EXTREMELY common, and I'm afraid you are really taking a holier than thou attitude to this.

If you don't want to support it fine, but please at least acknowledge the situation is not a special case, and whilst you are at it, please have the decency to at least add some comments to the submitted patch http://opensource.atlassian.com/projects/hibernate/browse/HB-92 which would have fixed the problem over a year ago.

Quit frankly I'm amazed that a positive, constructive suggestion for an improvement to hibernate has been met with negativity.

Oh, honestly. Having an object model with BigDecimal as the surrogate identifier type is ABSOLUTELY a bizzarre special case! It makes no sense at all to represent surrogate keys using a floating point type.

This is a wrinkle in your object model, not a problem with Hibernate.

And it is *so* trivial to write your own IdentifierGenerator....

[quote="gavin"]Oh, honestly. Having an object model with BigDecimal as the surrogate identifier type is ABSOLUTELY a bizzarre special case! It makes no sense at all to represent surrogate keys using a floating point type.

Oh honestly indeed, please re-read my post. A field defined as DECIMAL 11,0 can only hold an integer value. Such a field is not, repeat not, a floating point field.

I have worked in the iSeries IBM DB2 area for 15 years. For a long time (before the iSeries database was rebadged as DB2), there were no database field types of INT, SMALLINT and MEDIUMINT. The native numeric field type on the AS400 was a packed decimal field, which, when written to a file, is the exact equivalent of the SQL DECIMAL field type.

For this reason (mainly historical) many if not most iSeries DB2 databases tend to use DECIMAL fields for holding numeric values, rather than ints for integers or floats for floating points. It's not an ideal situation, and nowadays born through a result of ignorance, but nevertheless, the situation exists: many DB2 UDB for iSeries database files have DECIMAL fields, with no decimal points, i.e. integers as their primary keys.

So it is absolutley NOT a bizarre special case, it is pretty much normality in the iSeries world. As such its frustrating to say the least to be continually slammed by the hibernate team on the use of DECIMALs as surrogate keys. If it was a bizarre special case, then someone, please answer the question (because no one has so far), why does DB2 support DECIMAL and NUMERIC as an IDENTITY field type ?

Do I know it's not the ideal situation ? YES
Is it the normal situation in iSeries DB2 databases ? PROBABLY YES
Would it be easy for hibernate to support ? YES

Come on guys, this is the real world, we are stuck with what some people would be called legacy databases. Its all very well sitting in ivory towers poo pooing database designs that they don't agree with, but something like hibernate is going to be a lot better product if it supports such things.

This is as has been said already easy to handle with a custom generator. Unless this is not a much requested feature it won't be added, especially since it can be so easily done by using a custom generator.

You have always the options to vote for the JIRA issues you mentioned, and get others needing the same thing to vote for this. Bullying around in the forum is not the way to get features into Hibernate.

There are also issues which you are probably not aware of:

Does it bloat Hibernate a little bit: YES
Could the new feature confuse beginners: YES
Would it be bad if everyone would accidentially use this: YES
and so on...

You see, decisions for or against features are not only based on "hey, it's trivial, let's do it", but also other factors you as a Hibernate user don't care about. We as maintainers _do_ care. Rule of thumb: If a case is easily solved by implementing one of the extension points, we don't need it, because we already have it (the extension point to implement exactly this). Unless: 10 other users also need it in the next 4 weeks.

Nothing personal, we do that all the time. However, usually its easier to communicate.

Incidently, you have still not understood your problem properly. Your problem is NOT the use of DECIMAL in the database, it is use of BigDecimal in your object model.

Now, I already explained this to you, but I will explain it again:

You can declare your Java-level properties as Integer or Long, and your JDBC driver will safely map that to a DECIMAL column type.

Using BigDecimal at the Java level, to represent an integer value is absurd.

Really, you are completely off the planet on this one, end of conversation.

Gavin, there is no need to resort to insults, nor is there a need to attempt to curtail threads with an "end of conversation" suffix.

You did not explain this at all clearly, if you remember you closed the JIRA entry with as single line "using a non-integer type for a surrogate key makes no sense".

I suggest you treat people with more respect, and you might get some back.

OK thanks for that Christian.

All fair points.

It looks like I'll just have to end up changing all our objects to contain Long instead of BigDecimals, or just stick with a stop gap generator until the DB gets changed to use identity fields.

I explained it to you in private email.



You don't think we deserve a teensy bit of respect just for the fact we are giving you something for free? (Free for you, not for us.)

Anyway, I'm not sure if we'll continue giving free support, it doesn't seem to work, very few people appreciate it.