BigDecimal to SQL NUMBER: проверьте значение больше точности

следующий regexp тоже сделает трюк:

public class Big {
    private static final Pattern p = Pattern.compile("[0-9]{0,10}(\.[0-9]{0,5}){0,1}");

    public static void main(String[] args) {
        BigDecimal b = new BigDecimal("123123.12321");
        Matcher m = p.matcher(b.toString());
        System.out.println(b.toString() + " is valid = " + m.matches());
    }
}

это может быть другой способ проверить ваш код, или он может быть код. Регулярное выражение требует от 0 до 10 цифр, за которыми может следовать десятичная точка и от 0 до 5 цифр. Я не знал, нужен ли знак или нет, когда я думаю об этом. Лавировать что-то вроде [+-]{0,1} на фронт пойдет.

вот лучший класс, возможно, и тестовый класс с частичным набором тесты.

public class Big {
    private static final Pattern p = Pattern.compile("[0-9]{0,10}(\.[0-9]{0,5}){0,1}");

public static boolean isValid(String s) {
    BigDecimal b = new BigDecimal(s);
    Matcher m = p.matcher(b.toPlainString());
    return m.matches();
    }
}

package thop;

import junit.framework.TestCase;

/**
 * Created by IntelliJ IDEA.
 * User: tonyennis
 * Date: Sep 22, 2010
 * Time: 6:01:15 PM
 * To change this template use File | Settings | File Templates.
 */
public class BigTest extends TestCase {

    public void testZero1() {
        assertTrue(Big.isValid("0"));
    }

    public void testZero2() {
        assertTrue(Big.isValid("0."));
    }

    public void testZero3() {
        assertTrue(Big.isValid("0.0"));
    }

    public void testZero4() {
        assertTrue(Big.isValid(".0"));
    }

    public void testTooMuchLeftSide() {
        assertFalse(Big.isValid("12345678901.0"));
    }

    public void testMaxLeftSide() {
        assertTrue(Big.isValid("1234567890.0"));
    }

    public void testMaxLeftSide2() {
        assertTrue(Big.isValid("000001234567890.0"));
    }

    public void testTooMuchScale() {
        assertFalse(Big.isValid("0.123456"));
    }

    public void testScientificNotation1() {
        assertTrue(Big.isValid("123.45e-1"));
    }

    public void testScientificNotation2() {
        assertTrue(Big.isValid("12e4"));
    }
}

одна из проблем с вашей функцией заключается в том, что в некоторых случаях она может быть слишком ограничительной, рассмотрим:

BigDecimal a = new BigDecimal("0.000005"); /* scale 6 */
a = a.multiply(new BigDecimal("2")); /* 0.000010 */
return testBigDecimal(a); /* returns false */

Как видите, масштаб не регулируется. Я не могу проверить прямо сейчас, происходит ли что-то подобное с высокой точностью (1e11/2).

Я бы предложил более прямой путь:

public boolean testBigDecimal(BigDecimal value) {
    BigDecimal sqlScale = new BigDecimal(100000);
    BigDecimal sqlPrecision = new BigDecimal("10000000000");
    /* check that value * 1e5 is an integer */
    if (value.multiply(sqlScale)
          .compareTo(value.multiply(sqlScale)
              .setScale(0,BigDecimal.ROUND_UP)) != 0)
        return false;
    /* check that |value| < 1e10 */
    else if (value.abs().compareTo(sqlPrecision) >= 0)
        return false;
    else
        return true;
}

обновление

вы спросили в комментарии, если база данных будет выдавать ошибку, если мы попытаемся вставить 0.000010. Фактически база данных никогда не выдаст ошибку, если вы попытаетесь вставить значение с слишком большой точностью, он будет молча вокруг вставленного значения.

поэтому первая проверка не нужна, чтобы избежать ошибки Oracle, я предполагал, что вы выполняете этот тест, чтобы убедиться, что значение, которое вы хотите вставить, равно значению, которое вы фактически вставили. Так как 0.000010 и 0.00001 равны (с BigDecimal.compareTo) не должны ли они оба возвращать один и тот же результат?

вместо этого, если цикл более тысячи случайных чисел, вы можете написать тестовые случаи, которые подчеркивают "ребра" - максимальное значение +.00001, максимальное значение, максимальное значение - .00001, 0, null, минимальное значение -.00001, минимальное значение, минимальное значение + .00001, и значения со значениями 4, 5 и 6 справа от десятичной запятой. Вероятно, их гораздо больше.

Если у вас есть такие в JUnit, вы хорошо.