-8

I used int as PK in Java application, now it has reached the max int value (2 billions), even in DB it can store the number more than it. but java int is only able to hold around 2 billions.

I am unable to change int to long to align to DB. because it's huge effort.

except this, anybody have any approach?

Harsh
  • 372
  • 2
  • 15
user2166163
  • 57
  • 1
  • 3
  • 7
    You've already answered your question. – Zutty Mar 14 '13 at 16:08
  • Last week, the very same question was asked. Let me see if I find it. – Ingo Mar 14 '13 at 16:09
  • Are you using every integer from 1 through to Integer.MAX? Can you reset your autoincrement to reuse numbers that you've used previously? – BunjiquoBianco Mar 14 '13 at 16:09
  • 1
    You have several options. 1. change to use long in java. This is the best option you have. 2. Change to use Sting as the pk value in java. 3. Find a new job and let somebody else change to use long in java. – DwB Mar 14 '13 at 16:10
  • Why don't you use the 2 billion values between 2 billion and 4 billion and int can represent? (Note that values >= 2^31 will be interpreted as negative ones in java, but this doesn't matter as long as you use them only as keys.) – Ingo Mar 14 '13 at 16:15
  • Rolled back as you have effectively deleted your original question, therefore making all answers here useless... – fireshadow52 Mar 15 '13 at 02:55

6 Answers6

6

The maximum value for an Integer in Java is 2,147,483,647. If you need a bigger number, you'll have to change to a long. You could also use the negative range of the Integer, but if you've already hit the maximum, the likelihood is that you'll run out of room pretty soon.

However, if you don't have 2 billion elements in the DB, you could reuse the unused primary keys. This would probably be inefficient, because you'd have to search for unused keys.

I'd suggest just going through the effort of changing the code. Putting in the effort now will pay off in the long run.

Alex
  • 349
  • 1
  • 10
2

I am unable to change int to long to align to DB. because it's huge effort.

You have no alternatives in the long term. Start coding.

Actually, if you are methodical about it, you will probably find that it is not a huge effort at all. Java IDEs are good for helping you with this sort of change.

@jjnguy suggested you let the keys wrap around to negative. That would give you 2 billion or so extra keys, but:

  • you will probably use the second 2 billion faster quicker than the first 2 billion, and
  • it is possible that your application (or the database) depends on keys always increasing.

So I would avoid that, unless roll-over was imminent.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • It's the interaction with other software components that could make this a hard thing, actually. – Ingo Mar 14 '13 at 16:16
  • Yes well ... the further these ids go, the worse it gets. But you would kind of hope that external components are not dependent on the representation of the database pks. The good thing is that it is unlikely is going to try to do anything other than pass pk values and compare them. Arithmetic, etc is unlikely ... – Stephen C Mar 14 '13 at 16:23
  • My application is unable to handle negative number. so can switch the negative part to the number bigger than 2 billion? as int can hold 4 billions number. – user2166163 Mar 14 '13 at 16:29
  • No you can't. The Java `int` type is signed, with 2,000,000,000 positive values and 2,000,000,000 negative values (roughly). You can't change magically make Java `int` unsigned. – Stephen C Mar 14 '13 at 16:49
  • @user2166163 It's not numbers, it's just bit patterns, and as such neither negative nor positive, despite what people tell you about signed vs. unsigned. The fact is that you can use int to make 2^32 different keys. But, to be sure, if you interpret it as *number*, and your program can't handle negative numbers, well, then you did it wrong. At least you can perhaps use long in the parts of your program that uses the keys as numbers? – Ingo Mar 14 '13 at 17:06
  • @StephenC `You can't change magically make Java int unsigned.` this is one of the biggest myths in the java community. Fact is, 32bits are just that - 32 bits. Another fact is that many Java operators *interpret* those bits as signed 2-complement number. (However, + is not one of them.) That doesn't mean that you cannot interpret the bits differently. – Ingo Mar 14 '13 at 17:09
  • @Ingo - I know you can interpret the bits differently. But if you are going to change your code to do that, you are better of changing your code to use long instead of int. And the point is that you HAVE to change your code ... rather doing some magic as the OP seems to think should be possible. – Stephen C Mar 15 '13 at 15:31
  • @Ingo - For example, if you want to compare two `int` values as if they were unsigned, you have to use more complicated code than the "natural" case. This is particularly apropos for the OP, he states that his application cannot cope with negative keys, and it is fair to assume that this is because he wants to use `<` and `>` on them ... among other things. – Stephen C Mar 15 '13 at 15:34
  • Yes, @StephenC, you're absolutely right with your last statement. The OP does have the *main* problem, that he is not treating his keys as keys, but something else. If this were not so, he could probably easily change to long most easily. – Ingo Mar 15 '13 at 16:05
0

I'm assuming you haven't used negative values for the IDs. If that's the case, you can let the value overflow to negative values. This will give you some time to refactor your code to use a long to store your data.

jjnguy
  • 136,852
  • 53
  • 295
  • 323
0

you need just to replace int with uint, long and etc. there is no other way

Garegin
  • 61
  • 1
  • 9
0

Everyone here suggests to change to long. This seems to me also the most straightforward approach. However, you ask for a different one.

You could also create another column, with long values, copy the value from the PK, and setting that henceforth as the PK. Although I would see this technically as more work, maybe for your situation it is better, and strictly it is an answer to your question of another approach.

(Maybe you have some sort of sharded situation with thousand shards which you can´t possibly all in the same time swap over). Either way be very careful! Run tests!

Frido Emans
  • 5,120
  • 2
  • 27
  • 42
-1

Use BigInteger class in Java. You can get large and by large i mean really very large values. Please refer to this link: How to use BigInteger?

Harsh
  • 372
  • 2
  • 15