Docjar: A Java Source and Docuemnt Enginecom.*    java.*    javax.*    org.*    all    new    plug-in

Quick Search    Search Deep
Home >> All >> org >> apache >> derby >> iapi >> [ types Javadoc ]

• org.apache.derby.iapi.types: Javadoc index of package org.apache.derby.iapi.types.


Package Samples:

• org.apache.derby.iapi.types

Classes:

• DataValueDescriptor: The DataValueDescriptor interface provides methods to get the data from a column returned by a statement. This interface has the same methods as NoCastDataValueDescriptor - the only reason it exists is for purposes of internal documentation, to make it clear when the different getXXX methods throw exceptions for illegal conversions. This interface matches the getXXX methods on java.sql.ResultSet. This means everyone satisfies getString and getObject; all of the numeric types, within the limits of representation, satisfy all of the numeric getXXX methods; all of the character types satisfy all of ...
• SQLBinary: SQLBinary satisfies the DataValueDescriptor interfaces (i.e., DataType). It implements a String holder, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction. Because DataType is a subclass of DataType, SQLBit can play a role in either a DataType/Value or a DataType/KeyRow, interchangeably. Format : Length is encoded to support 5.x databases where the length was stored as the number of bits. The first bit of the first byte indicates if the format is an old (5.x) style or a new 8.1 style. 8.1 then uses the next ...
• SQLBit: SQLBit satisfies the DataValueDescriptor interfaces (i.e., DataType). It implements a String holder, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction. Because DataType is a subclass of DataType, SQLBit can play a role in either a DataType/Value or a DataType/KeyRow, interchangeably. Format : Length is encoded to support 5.x databases where the length was stored as the number of bits. The first bit of the first byte indicates if the format is an old (5.x) style or a new 8.1 style. 8.1 then uses the next two ...
• SQLDouble: SQLDouble satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a double column, e.g. for * storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction, as it affects the storage size and mechanism. Because OrderableDataType is a subtype of DataType, SQLDouble can play a role in either a DataType/Row or a OrderableDataType/Row, interchangeably. We assume the store has a flag for nullness of the value, and simply return a 0-length array for the stored form when the value is null. PERFORMANCE: There ...
• SQLReal: SQLReal satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a real column, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction, as it affects the storage size and mechanism. Because OrderableDataType is a subtype of ValueColumn, SQLReal can play a role in either a ValueColumn/Row or a OrderableDataType/Row, interchangeably. We assume the store has a flag for nullness of the value, and simply return a 0-length array for the stored form when the value is null. PERFORMANCE: There ...
• SQLTime: This contains an instance of a SQL Time Our current implementation doesn't implement time precision so the fractional seconds portion of the time is always 0. The default when no time precision is specified is 0 fractional seconds. A SQL Time without timezone information is assumed to be in the local time zone. The local time is stored as is and doesn't change if the timezone changes. This is in conformance with the SQL99 standard. The SQL92 standard indicates that the time is in GMT and changes with the timezone. The SQL99 standard clarifies this to allow time without timezoned to be stored as ...
• XML: This type implements the XMLDataValue interface and thus is the type on which all XML related operations are executed. The first and simplest XML store implementation is a UTF-8 based one--all XML data is stored on disk as a UTF-8 string, just like the other Derby string types. In order to make it possible for smarter XML implementations to exist in the future, this class always writes an "XML implementation id" to disk before writing the rest of its data. When reading the data, the impl id is read first and serves as an indicator of how the rest of the data should be read. So long as there's only ...
• SQLSmallint: SQLSmallint satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a smallint column, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction, as it affects the storage size and mechanism. Because OrderableDataType is a subtype of ValueColumn, SQLSmallint can play a role in either a ValueColumn/Row or a OrderableDataType/Row, interchangeably. We assume the store has a flag for nullness of the value, and simply return a 0-length array for the stored form when the value is null. PERFORMANCE: ...
• SQLInteger: SQLInteger satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements an integer column, e.g. for * storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction, as it affects the storage size and mechanism. Because OrderableDataType is a subtype of DataType, SQLInteger can play a role in either a DataType/Row or a OrderableDataType/Row, interchangeably. We assume the store has a flag for nullness of the value, and simply return a 0-length array for the stored form when the value is null. PERFORMANCE: ...
• SQLLongint: SQLLongint satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a bigint column, e.g. for * storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction, as it affects the storage size and mechanism. Because OrderableDataType is a subtype of DataType, SQLLongint can play a role in either a DataType/Row or a OrderableDataType/Row, interchangeably. We assume the store has a flag for nullness of the value, and simply return a 0-length array for the stored form when the value is null. PERFORMANCE: ...
• SQLBoolean: SQLBoolean satisfies the DataValueDescriptor interfaces (i.e., DataType). It implements a boolean column, e.g. for * storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction, as it affects the storage size and mechanism. Because DataType is a subtype of DataType, SQLBoolean can play a role in either a DataType/Row or a DataType/Row, interchangeably. We assume the store has a flag for nullness of the value, and simply return a 0-length array for the stored form when the value is null. PERFORMANCE: There are likely alot of performance ...
• SQLNClob: SQLNClob satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a String holder, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction. ----- TODO: fix for NCLOB Because OrderableDataType is a subclass of DataType, SQLNationalLongvarchar can play a role in either a DataType/ValueRow or a OrderableDataType/KeyRow, interchangeably. ----- TODO: fix for NCLOB SQLNationalLongvarchar is mostly the same as SQLLongvarchar, so it is implemented as a subclass of SQLLongvarchar. Only those methods ...
• SQLNationalLongvarchar: SQLNationalLongvarchar satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a String holder, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction. Because OrderableDataType is a subclass of DataType, SQLNationalLongvarchar can play a role in either a DataType/ValueRow or a OrderableDataType/KeyRow, interchangeably. SQLNationalLongvarchar is mostly the same as SQLLongvarchar, so it is implemented as a subclass of SQLLongvarchar. Only those methods with different behavior are implemented ...
• SQLDecimal: SQLDecimal satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a numeric/decimal column, e.g. for * storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction, as it affects the storage size and mechanism. Because OrderableDataType is a subtype of DataType, SQLDecimal can play a role in either a DataType/Row or a OrderableDataType/Row, interchangeably. We assume the store has a flag for nullness of the value, and simply return a 0-length array for the stored form when the value is null.
• SQLNationalVarchar: SQLNationalVarchar satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a String holder, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction. Because OrderableDataType is a subclass of DataType, SQLNationalVarchar can play a role in either a DataType/ValueRow or a OrderableDataType/KeyRow, interchangeably. SQLNationalVarchar is mostly the same as SQLVarchar, so it is implemented as a subclass of SQLVarchar. Only those methods with different behavior are implemented here.
• SQLTinyint: SQLTinyint satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a tinyint column, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction, as it affects the storage size and mechanism. Because OrderableDataType is a subtype of ValueColumn, SQLTinyint can play a role in either a ValueColumn/Row or a OrderableDataType/Row, interchangeably. We assume the store has a flag for nullness of the value, and simply return a 0-length array for the stored form when the value is null.
• BinaryDecimal: SQL DECIMAL using raw data. Provides the basis for the CDCDecimal implementation. The on-disk format must match the SQLDecimal format so that databases are portable across J2ME and J2SE environments. The format of the byte array is defined by the return of the java.math.BigInteger.toByteArray:, extracted here. Returns a byte array containing the two's-complement representation of this BigInteger. The byte array will be in big-endian byte-order: the most significant byte is in the zeroth element. This is the format for DECIMAL even if BigINteger is not available, e.g. OSGi ee.minimum.
• SQLLongvarchar: SQLLongvarchar satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a String holder, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction. Because OrderableDataType is a subclass of DataType, SQLLongvarchar can play a role in either a DataType/ValueRow or a OrderableDataType/KeyRow, interchangeably. SQLLongvarchar is mostly the same as SQLVarchar, so it is implemented as a subclass of SQLVarchar. Only those methods with different behavior are implemented here.
• SQLVarchar: SQLVarchar satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a String holder, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction. Because OrderableDataType is a subclass of DataType, SQLVarchar can play a role in either a DataType/ValueRow or a OrderableDataType/KeyRow, interchangeably. SQLVarchar is mostly the same as SQLChar, so it is implemented as a subclass of SQLChar. Only those methods with different behavior are implemented here.
• SQLTimestamp: This contains an instance of a SQL Timestamp object. SQLTimestamp is stored in 3 ints - an encoded date, an encoded time and nanoseconds encodedDate = 0 indicates a null WSCTimestamp SQLTimestamp is similar to SQLTimestamp, but it does conserves space by not keeping a GregorianCalendar object PERFORMANCE OPTIMIZATION: We only instantiate the value field when required due to the overhead of the Date methods. Thus, use isNull() instead of "value == null" and getTimestamp() instead of using value directly.
• Orderable: The Orderable interface represents a value that can be linearly ordered. Currently only supports linear ( The implementation must handle the comparison of null values. This may require some changes to the interface, since (at least in some contexts) comparing a value with null should return unknown instead of true or false.
• SQLLongVarbit: SQLLongVarbit satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a String holder, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction. Because OrderableDataType is a subclass of DataType, SQLLongVarbit can play a role in either a DataType/Value or a OrderableDataType/KeyRow, interchangeably. It is an extension of SQLVarbit and is virtually indistinguishable other than normalization.
• BigIntegerDecimal: DECIMAL support using the immutable java.math.BigInteger to perform arithmetic and conversions. Extends BinaryDecimal to use the base support of that class. J2ME/CDC/Foundation includes BigInteger. A BigInteger is used in calculations etc. to represent the integral unscaled value. It is simply created from new BigInteger(data2c). No additional instance fields are used by this class, a possible enhancement would be to keep the BigInteger around but would require calls from the parent class to reset state etc.
• SQLVarbit: SQLVarbit satisfies the DataValueDescriptor interfaces (i.e., OrderableDataType). It implements a String holder, e.g. for storing a column value; it can be specified when constructed to not allow nulls. Nullability cannot be changed after construction. Because OrderableDataType is a subclass of DataType, SQLVarbit can play a role in either a DataType/Value or a OrderableDataType/KeyRow, interchangeably. It is an extension of SQLVarbit and is virtually indistinguishable other than normalization.
• DataType: DataType is the superclass for all data types. It provides common behavior for datavalue descriptors -- it throws exceptions for all of the get* and setvalue(*) methods of DataValueDescriptor; the subtypes need only override the one for the type they represent and all types it can also be returned as, and the methods dealing with nulls. Since all types satisfy getString DataType does not define that interfaces of DataValueDescriptor. DataType is a little glue for columns to hold values with.

Home | Contact Us | Privacy Policy | Terms of Service