VoltDB supports eleven datatypes. When invoking stored procedures from different programming languages or queuing SQL statements within a Java stored procedure, you must use an appropriate language-specific value and datatype for arguments corresponding to placeholders in the query. This appendix provides the mapping of language-specific datatypes to the corresponding VoltDB datatype.
In several cases, there are multiple possible language-specific datatypes that can be used. The following tables highlight the best possible matches in bold.
Table F.1, “Java and VoltDB Datatype Compatibility” shows the compatible Java datatypes for each VoltDB datatype when:
Calling simple stored procedures defined using the CREATE PROCEDURE AS statement
Calling default stored procedures created for each table in the schema
Note that when calling user-defined stored procedures written in Java, you can use additional datatypes, including arrays and the VoltTable object, as arguments to the stored procedure, as long as the actual query invocations within the stored procedure use the following datatypes. Within the stored procedure, when queuing SQL statements using the voltdbQueueSql method, implicit type casting is not guaranteed so using the highlighted Java type is recommended.
Note that VoltDB accepts both primitive numeric types (byte, short, int, and so on) and their reference type equivalents (Byte, Short, Integer, etc.). The reference types can be useful, especially when passing null values, where you can send a Java null. In most cases when using the primitive types, you must pass the largest possible negative value for the type in place of null.
Table F.1. Java and VoltDB Datatype Compatibility
SQL Datatype | Compatible Java Datatypes | Notes |
---|---|---|
TINYINT | byte/Byte | Larger datatypes (short, int, long, and BigDecimal) are valid input types. However, VoltDB throws a runtime error if the value exceeds the allowable range of a TINYINT. String input must be a properly formatted text representation of an integer value in the correct range. |
SMALLINT | byte/Byte | Larger datatypes (int, long, and BigDecimal) are valid input types. However, VoltDB throws a runtime error if the value exceeds the allowable range of a SMALLINT. String input must be a properly formatted text representation of an integer value in the correct range. |
INTEGER | byte/Byte | Larger datatypes (long and BigDecimal) are valid input type. However, VoltDB throws a runtime error if the value exceeds the allowable range of an INTEGER. String input must be a properly formatted text representation of an integer value in the correct range. |
BIGINT | byte/Byte | String input must be a properly formatted text representation of an integer value in the correct range. |
FLOAT | double/Double | Because of the difference in how numbers are represented in the two types, there can be a loss of precision when using BigDecimal as input to a FLOAT value. String input must be a properly formatted text representation of a floating point value. |
DECIMAL | BigDecimal | String input must be a properly formatted text representation of a decimal number. |
GEOGRAPHY | (none) | Geospatial input should be converted from Well Known Text (WKT) to a VoltDB native format either using the GeographyValue.fromWKT() method or by passing a String and using the POLYGONFROMTEXT function within the SQL statement. |
GEOGRAPHY_POINT | (none) | Geospatial input should be converted from Well Known Text (WKT) to a VoltDB native format either using the GeographyPointValue.fromWKT() method or by passing a String and using the POINTFROMTEXT function within the SQL statement. |
VARCHAR() | String | Byte arrays are interpreted as UTF-8 encoded string values. String objects can use other encodings. Numeric and timestamp values are converted to their string representation. For example, the double value 13.25 is interpreted as "13.25" when converted to a VARCHAR. |
VARBINARY() | String | String input is interpreted as a hex-encoded binary value. |
TIMESTAMP | VoltDB TimestampType | For String variables, the text must be formatted as either YYYY-MM-DD hh.mm.ss.nnnnnn or
just the date portion YYYY-MM-DD . |