1

I found a partial answer here, but I knew this already. So I decided to post a new question.

I am trying to convert a HTTP request parameter string to a 15 precision Java BigDecimal number (with scaling of 2). For example, 

String x = request.getParameter("seqNo"); /* e.g. 12345678910111213141516.17181920 whatever */
// I want to convert x so that it has a precision of 15 and scale of 2 i.e. 111213141516.17.

I don't care about rounding. It's a form of reference number, so irrelevant of rounding. I know that scaling can be set by using overloaded setScale(int) method that will return a scaled(Truncated?) BigDecimal. But how to make sure that the precision is set properly?

Community
  • 1
  • 1
ha9u63a7
  • 6,233
  • 16
  • 73
  • 108
  • 2
    So you want to not just round the trailing digits, but also ignore the *leading* digits? This doesn't sound like you should be treating it as a *number* at all, to be honest... can you tell us more about what the input is meant to represent? – Jon Skeet Apr 30 '15 at 15:17
  • @JonSkeet as mentioned in the question, a reference number, for internal reference for the developers – ha9u63a7 Apr 30 '15 at 15:22
  • "A reference number" is far from a detailed description. Why are the digits before the "111" in your example irrelevant? As per the answer from Anony-Mousse, this really shouldn't be thought of as a number, IMO. – Jon Skeet Apr 30 '15 at 15:24
  • What if they decide to add another component next week? Say they use multiple servers now, and next week their ids are `1234567.89012345.5` where the last component is the server number, and they really need this one... **treat it as string, and you are safe**, anything else will drive you crazy eventually. – Has QUIT--Anony-Mousse Apr 30 '15 at 15:30

1 Answers1

1

How about using substring instead? It's not really a number anyway.

int pos = x.indexOf('.');
String y = x.substring(pos - 12, pos + 3);

If you are really crazy enough to try processing this as numbers (collissions and differences in rounding are going to break your neck sooner or later!), you could do this.

double v = Double.parseDouble(y); // REALLY REALLY REALLY NOT RECOMMENDED.

But this is a very very bad idea. Don't squeeze something into a number column that is not a number. Next week, you'll get numbers with two dots, and it will break in every possible way.

If you do not need to do mathematical computations, treating such a field as VARCHAR or TEXT is perfectly acceptable. Because that is what it is: a sequence of characters. Not a number.

In fact, I would strongly advise to store the whole number, as VARCHAR. It is a unique identifier, not a mathematical number to do computations with.

Has QUIT--Anony-Mousse
  • 76,138
  • 12
  • 138
  • 194
  • well, i am trying to pesist it to SQL server and the recommended DECIMAL(p,s) type equivalent in java is BigDecimal. But yes, it seems like one of the ways. – ha9u63a7 Apr 30 '15 at 15:18
  • 1
    Why don't you use `TEXT` or `VARCHAR`? Hacking this ID - which supposedly is not a number - into a numeric column type by truncation just sounds like the worst possible solution. – Has QUIT--Anony-Mousse Apr 30 '15 at 15:19
  • 1
    Fix the requirement, instead of breaking the data. It isn't the first time the requirements turn out to be flawed. And this sounds like the requirement is just BROKEN! – Has QUIT--Anony-Mousse Apr 30 '15 at 15:21
  • 2
    @ha9u63ar What kind of requirement is there that forces you to treat something that is not a decimal number as a decimal number? – Cubic Apr 30 '15 at 15:22