DataTypes - ODABA built-in data types
ODABA supports several built-in data types, which are listed below.
Enumarators overview
- ASCII
(17) - String values (ASCII 8 bit encoding)
- BIT
(11) - Bit strings
- BLOB
(15) - Binary large objects
- CCHAR
(14) - Coded character values
- CHAR
(1) - Character values
- DATE
(7) - Date values
- DATETIME
(13) - Timestamp
- INT
(3) - Signed integer or decimal number
- LATIN1
(19) - String values (latin1 8 bit encoding)
- LOCAL
(21) - String values (local 8 bit encoding)
- LOGICAL
(9) - Boolean values
- OGUID
(2) - Global unique identity
- REAL
(12) - Float point number
- STRING
(10) - String values (latin1 8 bit encoding)
- TIME
(8) - Time value
- UINT
(4) - Unsigned integer or decimal number
- UTF16
(16) - String value (UTF16 encoding)
- UTF32
(20) - String value (UTF32 encoding)
- UTF8
(18) - String value (UTF8 encoding)
- VOID
(6) - Unknown type
Enumerator details
-
CHAR - Character values
Character fields are defined with a maximum number of characters. Character fields are always padded with blanks. The maximum number of characters in a character field is limited to 2 GB. Character fields cannot be defined as reference type, but are valid for attributes, only.
Character values are supposed to be ASCII values, i.e. character values must not contain special national or UTF8 encoded characters.
Code: 1
to list -
OGUID - Global unique identity
Global unique identities are a system feature, which creates a world wide unique identity for an object when being created. Internally, GUIDs are represented in a 16 byte area. Externally, they are displayed as formatted string containing the id-version and the value displayed hexadecimal.
Code: 2
to list -
INT - Signed integer or decimal number
ODABA considers decimal values the same way as binary values by defining a size and a precision. The size for an integer value defines the number of significant digits. The precision defines the number of positions behind the decimal point. Negative precision allow defining a decimal factor. Both, precision and positions describe the decimal presentation of the value, i.e. int(6,2) defines decimal numbers between -9999.99 and +9999.99. Nevertheless, integer values are stored as binary numbers.
The storage size for integer numbers results from the defined size for the integer:
- 1 - 3: 1 byte
- 4 - 5: 2 byte
- 6 - 10: 4 byte
- 11 - 19: 8 byte
In ODL one may, however, also define the standard names for integer values, which is converted automatically into size and precision.
Code: 3INT(5,2) defines numbers with three digits before the decimal point and two digits after.
INT(5,-3) defines numbers with five digits that must be multiplied with 1000 (appending 3 zeros), i.e. you may store values between 1000 and 99999000 in the field.
to list -
UINT - Unsigned integer or decimal number
ODABA considers decimal values the same way as integer values by defining a precision. The size for an integer value defines the number of significant digits. The precision defines the number of positions behind the decimal point. Negative precision allows defining a decimal factor.
Unsigned values cannot store negative numbers. The storage size for integer numbers results from the defined size for the integer:
- 1-2: 1 byte
- 3-4: 2 byte
- 5-10: 4 byte
- 11-19: 8 byte
to list -
VOID - Unknown type
Unknown types can be defined for references or transient fields (pointers), only. VOID references may refer to a collection or a single object instance with unknown type. The database will determine the instance type at run-time in this case.
In OSI, VOID is considered as base class for any other type, i.e. each complex data type inherits from VOID . This allows defining generic expressions in the VOID class. You may also implement virtual expression in VOID , which can be overloaded in derived classes.
Code: 6
to list -
DATE - Date values
Date fields allow storing date values. The size for a date field influences only the standard presentation of the date, i.e. the date to string conversion. Following size definitions are possible:
8: "2002-09-14"
6,7: "02-09-14"
4,5: "02-09"
2,3: "02"
Independent on the size the date is stored always as 4 byte integer value containing the number of days since 1870-01-01.
ODABA supports different string representation for date:
Standard: yyyy-mm-dd or yyyymmdd
English: mm/dd/yyyy
German: dd.mm.yyyy
The type of date is determined from the separator used.
Code: 7
to list -
TIME - Time value
Time fields allow storing time values from 0:00:00,00 up to 23:59:59,99. The size for a time field influences only the standard presentation of the time, i.e. the time to string conversion. Following size definitions are possible:
8: "23:59:59,99"
6,7: "23:59:59"
4,5: "23:59"
2,3: "23"
Independent on the size the time is stored always with 4 byte.
Code: 8
to list -
LOGICAL - Boolean values
Boolean or LOGICAL values always have a fixed size 1, which relates to the binary value domain 0 for false or NO and 1 for true or YES .
Code: 9
to list -
STRING - String values (latin1 8 bit encoding)
STRING data type is a text type name for generic string encoding. By default, STRING values are supposed to be Latin1 encoded data fields. By setting the DefaultEncoding option for the application, one may change the default encoding type for STRING values.
Code: 10
to list -
BIT - Bit strings
Bit strings are supported for compatibility reasons. BIT types are supported within classes and transient fields. It is, however, not possible storing BIT type formats in the database.
Code: 11
to list -
REAL - Float point number
REAL allows defining float point numbers. In ODL one may define "float" or "double" types, which result in REAL(7) and REAL(17). For REAL fields the size defines the number of digits for representing the field. Values up to 8 define a 4 byte float point number; values up to 17 define an 8 byte float point number.
Code: 12
to list -
DATETIME - Timestamp
A date/time field (timestamp) is considered as basic data type even though it seems to be structured structured consisting of date and time. The size for the date time field will influence the presentation (to string conversion), but not the storage size. Timestamps with the maximum size of 22 are displayed as
2002/09/14 23:59:59:99
Lower size timestamps will cut the string at the end. Date and a time value can be accessed as structure members of the DATETIME structure.
Code: 13DATETIME last_update;
last_update.date = Date().now();
last_update.time = Time().now();
to list -
CCHAR - Coded character values
Coded character fields are used when data stored in the database must be encrypted (e.g. when storing passwords in the database). The number of characters in a coded character field is limited to 256 characters. Coded fields cannot be defined as reference type, but are valid for attributes, only.
Code: 14
to list -
BLOB - Binary large objects
Binary large objects are used to store complex data structures as pictures, videos or documents. Usually, BLOB s need special processes for interpreting the data within the BLOB . An extended feature in ODABA supports typed BLOB s and BLOB references, since it is often more convenient referring to BLOB s instead of storing them.
Code: 15
to list -
UTF16 - String value (UTF16 encoding)
UTF16 string properties are Unicode fields with 16 bit encoding. The end of the string is indicated by a 16 bit 0 (0-terminated string).
Defining variable string fields as attributes will always occupy storage with the defined size. In order to optimize storing large text instances, the property can be defined as reference. UTF16 type properties defined as reference are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.
UTF16 fields are an ODABA specific extension.
Code: 16
to list -
ASCII - String values (ASCII 8 bit encoding)
ASCII string properties are character fields with 8 bit encoding. The end of the string is indicated with a 0 -character (0-terminated string).
Defining variable string fields as attributes will always occupy storage with the defined size. In order to optimize storing large text instances, the property can be defined as reference. ASCII type properties defined as reference are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.
ASCII fields are an ODABA specific extension.
Code: 17
to list -
UTF8 - String value (UTF8 encoding)
UTF8 string properties are Unicode fields with 8 bit encoding. The end of the string is indicated with a 0 -character (0-terminated string).
Defining variable string fields as attributes will always occupy storage with the defined size. In order to optimize storing large text instances, the property can be defined as reference. UTF8 type properties defined as reference are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.
UTF8 fields are an ODABA specific extension.
Code: 18
to list -
LATIN1 - String values (latin1 8 bit encoding)
Latin1 string properties are Latin1 8 bit character fields with variable size. The end of the string is indicated with a 0 -character (0-terminated string).
Defining variable string fields as attributes will always occupy storage with the defined size. In order to optimize storing large text instances, the property can be defined as reference. LATIN1 or STRING type properties defined as reference (memo) are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.
LATIN1 fields are an ODABA specific extension.
Notes:Code: 19STRING is the old text type name for LATIN1. Both might be used, but comparing data types, STRING is different from LATIN1 . It is suggested using LATIN1 rather than STRING.
to list -
UTF32 - String value (UTF32 encoding)
UTF32 string properties are Unicode fields with 32 bit encoding. The end of the string is indicated by a 32 bit 0 (0-terminated string).
Defining variable string fields as attributes will always occupy storage with the defined size. In order to optimize storing large text instances, the property can be defined as reference. UTF32 type properties defined as reference are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.
UTF32 fields are an ODABA specific extension.
Code: 20
to list -
LOCAL - String values (local 8 bit encoding)
Local string properties are local 8 bit encoded character fields with variable size. The end of the string is indicated with a 0 -character (0-terminated string).
Defining variable string fields as attributes will always occupy storage of the defined size. In order to optimize storing large text instances, the property might be defined as reference. Base type properties defined as reference are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.
LOCAL fields are an ODABA specific extension.
Notes:Code: 21With supporting different encoding types, MEMO became obsolete.
to list