SQL Data Types

6.0-SNAPSHOT 5.5 5.4 5.3 5.2 5.1 5.0

Hazelcast supports a subset of SQL data types. Each data type is mapped to a Java class, which represents the type’s value in Hazelcast.

Type Name Supported Casting Types Java Class

BOOLEAN

VARCHAR, BOOLEAN, OBJECT

java.lang.Boolean

VARCHAR

All types

java.lang.String

TINYINT

VARCHAR, BOOLEAN, SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE, OBJECT

java.lang.Byte

SMALLINT

VARCHAR, SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE, OBJECT

java.lang.Short

INTERVAL

N/A

Custom

JSON

VARCHAR

HazelcastJsonValue

INTEGER

VARCHAR, SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE, OBJECT

java.lang.Integer

BIGINT

VARCHAR, SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE, OBJECT

java.lang.Long

DECIMAL

VARCHAR, SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE, OBJECT

java.math.BigDecimal

REAL

VARCHAR, SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE, OBJECT

java.lang.Float

DOUBLE

VARCHAR, SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE, OBJECT

java.lang.Double

DATE

VARCHAR, DATE, TIME, TIMESTAMP, TIMESTAMP WITH TIME ZONE, OBJECT

java.time.LocalDate

TIME

VARCHAR, DATE, TIME, TIMESTAMP, TIMESTAMP WITH TIME ZONE, OBJECT

java.time.LocalTime

TIMESTAMP

VARCHAR, DATE, TIME, TIMESTAMP, TIMESTAMP WITH TIME ZONE, OBJECT

java.time.LocalDateTime

TIMESTAMP WITH TIME ZONE

VARCHAR, DATE, TIME, TIMESTAMP, TIMESTAMP WITH TIME ZONE, OBJECT

java.time.OffsetDateTime

OBJECT

All types

Any Java class

Casting and Data Type Conversion

To convert one data type to another (also known as casting), you can use the CAST(expression AS type_name) function.

Numeric Literals

When numeric literals are assigned SQL types:

  1. Integers, e.g., 1 and 42, receive the narrowest possible among TINYINT, SMALLINT, INTEGER, BIGINT and DECIMAL.

  2. Floating-point numbers, e.g., 1.2 and 4.2, receive DECIMAL.

  3. Scientific notation (exponential form), e.g., 1e1 or 4.2e2, receives DOUBLE.

As you realized, integers are optimized for storage, whereas floating-point numbers are not subject to such optimization. This is because REAL and DOUBLE cannot exactly represent all decimal numbers (see IEEE 754), and exactness cannot be compromised for financial applications. Finally, because of its rare usage, scientific notation is not optimized for storage, i.e., not tried to narrow to REAL.

Numbers that are represented in scientific notation and out of range for DOUBLE will cause overflow and be interpreted as ∞ or -∞. For example, 1.8e+308 is greater than the largest possible finite value of DOUBLE, which is 1.7976931348623157e+308, and so it is only valid in the form 18000…​0.

lifebuoy

Help and support