This class represents a handle to a
and provides read and write access to
column values. This object has a number of different states and
provides several modes of access to
these are also described in this section.
Parent class. None
Child classes. None
An instance of
NdbBlob is created using the
method during the operation preparation phase. (See
Section 2.3.25, “The NdbOperation Class”.) This object acts as a handle
BLOB Data Storage.
BLOB data is stored in 2 locations:
The header and inline bytes are stored in the blob attribute.
The blob's data segments are stored in a separate table named
tidis the table ID, and
cidis the blob column ID.
Data Access Types.
NdbBlob supports 3 types of data access: These
data access types can be applied in combination, provided that
they are used in the order given above.
Also in the preparation phase,
setActiveHook()is used to define a routine which is invoked as soon as the handle becomes active.
BLOB operations take effect when the next
transaction is executed. In some cases,
is forced to perform implicit execution. To avoid this, you should
always operate on complete blob data segments.
to flush reads and writes, which avoids any execution penalty if no
operations are pending. This is not necessary following execution of
operations, or after the next scan result.
NdbBlob also supports reading post- or pre-blob
data from events. The handle can be read after the next event on the
main table has been retrieved. The data becomes available
immediately. (See Section 2.3.21, “The NdbEventOperation Class”, for more
BLOBs and NdbOperations.
NdbOperation methods acting on
NdbBlob objects have the following
NdbOperation::readTuple()used with any lock mode can read but not write blob values.
LM_CommittedReadlock mode is used with
readTuple(), the lock mode is automatically upgraded to
LM_Readwhenever blob attributes are accessed.
NdbOperation::deleteTuple()creates implicit, nonaccessible
A scan with any lock mode can use its blob handles to read blob values but not write them.
A scan using the
LM_Exclusivelock mode can update row and blob values using
updateCurrentTuple(); the operation returned must explicitly create its own blob handle.
A scan using the
LM_Exclusivelock mode can delete row values (and therefore blob values) using
deleteCurrentTuple(); this create implicit nonaccessible blob handles.
An operation which is returned by
lockCurrentTuple()cannot update blob values.
The following are known issues or limitations encountered when
Too many pending
BLOBoperations can overflow the I/O buffers.
The table and its
BLOBdata segment tables are not created atomically.
Methods. The following table lists the public methods of this class and the purpose or use of each method:
|Method||Purpose / Use|
||Gets the first blob in a list.|
||Gets the next blob in a list|
||Gets a blob event name|
||Gets a blob data segment's table name.|
||Gets a blob column.|
||Gets the length of a blob, in bytes|
||Gets an error (an
||Get a pointer to the operation
||Checks whether a blob value is
||Gets the current position for reading/writing|
||Gets the state of an
||Prepares to read a blob value|
||Checks whether a blob is statement-based or event-based|
||Reads data from a blob|
||Defines a callback for blob handle activation|
||Sets a blob to
||Sets the position at which to begin reading/writing|
||Prepares to insert or update a blob value|
||Truncates a blob to a given length|
||Writes blob data|
NdbBlob methods (nearly all of those whose
return type is
on success and
-1 in the event of failure.
For detailed descriptions, signatures, and examples of use for each of these methods, see Section 220.127.116.11, “NdbBlob Methods”.
The public types defined by
NdbBlob are shown here:
|Type||Purpose / Use|
||Represents the states that may be assumed by the
For a discussion of each of these types, along with its possible values, see Section 18.104.22.168, “NdbBlob Types”.
This diagram shows all the available methods and types of the