Howdy folks,

I've a bit of a problem with the TableHiLo generator. It seems to go back to the DB for every new identifier, instead of only going to the DB every MAX_LO identifiers.

I'm certain it's going to the DB because I use P6Spy to view the SQL being issued and it shows up there, also the hibernate debug logs have a line saying "new hi value: X" for every identifier.

I'm pretty sure this used to work, (in fact I'm sure it probably works for everyone else). Unfortunately we're still running 2.0 beta6. We've plans to change that, but we're stuck on it for the moment.

I looked for an issue in JIRA, but no luck. Anyone know what's happening with this, or is it obvious I've done something braindead?
There aren't any properties to set or something that I've missed?

Cheers,
Shorn.

Details:
An abstract id getter method is defined on our root persistent entity and it's mapped with the following details.

The XDoclet mapping looks like this:

And every object has a concreted getter implementation with doco like this:


The generated hbm.xml looks like this:

Ok, so.... no replies.

I went and looked at the code for TableHiLoGenerator and the code looks a bit suspect, but I thought I'd post here before opening an issue in JIRA.
The code appears to be the same in the latest 20031013 nightly tarball by the way.

TableHiLoGenerator:


Given that lo is an integer and will be set to the max short, then isn't the comment 'so we "clock over" on the first invocation' wrong (in that it'll just go to Short.MAX_VALUE+1, since that's a valid integer)?
Then, since lo is maxLo + 1 (and not clocked over) then the condition "if (lo>maxLo)" is going to be true for a good long while - resulting in the super.generate() method being called.

Am I missing something obvious?

Cheers,
Shorn.

looks just perfect to me.

notice that we set lo=1 after generating the hi value, thus avoiding the possibility that lo>maxLo on the next call.

Ok.
Any ideas what I've done wrong to have the generator go back to the DB each time?