ctubbsii commented on a change in pull request #2535: URL: https://github.com/apache/accumulo/pull/2535#discussion_r818966979
########## File path: core/src/main/java/org/apache/accumulo/core/client/lexicoder/BigDecimalLexicoder.java ########## @@ -0,0 +1,88 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.accumulo.core.client.lexicoder; + +import java.io.ByteArrayInputStream; +import java.io.DataInputStream; +import java.io.DataOutputStream; +import java.io.IOException; +import java.io.UncheckedIOException; +import java.math.BigDecimal; +import java.math.BigInteger; + +import org.apache.accumulo.core.clientImpl.lexicoder.FixedByteArrayOutputStream; + +/** + * A lexicoder to encode/decode a BigDecimal to/from bytes that maintain its native Java sort order. + * Review comment: I think the biggest problem with the native Java sort order, is that it's non-deterministic (for items that differ only in scale). Lexicoder orderings should be deterministic. So, we'd need to use a comparator that produces the same output, no matter the order of the input, and have the lexicoder be implemented to preserve that ordering. Otherwise, the user experience could be very confusing. For example, the string lexical ordering of "2.0" and "2.00" would place "2.0" before "2.00". However, the comparator for BigDecimal is perfectly happy to order "2.00" before "2.0", because their `compareTo` value is `0`, even though their `equals` value is `false`. ########## File path: core/src/main/java/org/apache/accumulo/core/client/lexicoder/BigDecimalLexicoder.java ########## @@ -0,0 +1,88 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.accumulo.core.client.lexicoder; + +import java.io.ByteArrayInputStream; +import java.io.DataInputStream; +import java.io.DataOutputStream; +import java.io.IOException; +import java.io.UncheckedIOException; +import java.math.BigDecimal; +import java.math.BigInteger; + +import org.apache.accumulo.core.clientImpl.lexicoder.FixedByteArrayOutputStream; + +/** + * A lexicoder to encode/decode a BigDecimal to/from bytes that maintain its native Java sort order. + * + * @since 2.1.0 + */ +public class BigDecimalLexicoder extends AbstractLexicoder<BigDecimal> { + + private final BigIntegerLexicoder bigIntegerLexicoder = new BigIntegerLexicoder(); + + @Override + public BigDecimal decode(byte[] b) { + // This concrete implementation is provided for binary compatibility, since the corresponding + // superclass method has type-erased return type Object. See ACCUMULO-3789 and #1285. + return super.decode(b); + } + + @Override + public byte[] encode(BigDecimal bd) { + // To encode we separate out the scale and the unscaled value + // serialize each value individually and store them + int scale = bd.scale(); + BigInteger bigInt = bd.unscaledValue(); + byte[] encodedbigInt = bigIntegerLexicoder.encode(bigInt); + // Length is set to size of encoded BigInteger + length of the scale value + byte[] ret = new byte[4 + encodedbigInt.length]; + try (DataOutputStream dos = new DataOutputStream(new FixedByteArrayOutputStream(ret))) { + scale = scale ^ 0x80000000; + dos.write(encodedbigInt); + dos.writeInt(scale); Review comment: This seems very dependent on DataOutputStream not introducing any additional bytes into the output stream. Since that's an implementation detail, I don't think we should rely on that fact. Why not just use `System.arraycopy` to guarantee you don't overflow the `ret` buffer? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
