Storage and retrieval for the {@link com.sleepycat.db.Database Database} and {@link com.sleepycat.db.Cursor Cursor} methodsare based on key/data pairs. Both key and data items are represented by DatabaseEntry objects. Key and data byte arrays may refer to arrays of zero length up to arrays of essentially unlimited length.
The DatabaseEntry class provides simple access to an underlying object whose elements can be examined or changed. DatabaseEntry objects can be subclassed, providing a way to associate with it additional data or references to other structures.
Access to DatabaseEntry objects is not re-entrant. In particular, if multiple threads simultaneously access the same DatabaseEntry object using {@link com.sleepycat.db.Database Database} or {@link com.sleepycat.db.Cursor Cursor} methods, the results are undefined.
DatabaseEntry objects may be used in conjunction with the object mapping support provided in the {@link com.sleepycat.bind} package.
DatabaseEntry objects are used for both input data (when writing to a database or specifying a search parameter) and output data (when reading from a database). For certain methods, one parameter may be an input parameter and another may be an output parameter. For example, the {@link Database#get} method has an input key parameter and an outputdata parameter. The documentation for each method describes whether its parameters are input or output parameters.
For DatabaseEntry input parameters, the caller is responsible for initializing the data array of the DatabaseEntry. For DatabaseEntry output parameters, the method called will initialize the data array.
For DatabaseEntry output parameters, by default the method called will reuse the byte array in the DatabaseEntry, if the data returned fits in the byte array. This behavior can be configured with {@link #setReuseBuffer} or {@link #setUserBuffer}. If an entry is configured to reuse the byte array (the default behavior), the length of the underlying byte array should not be used to determine the amount of data returned each time the entry is used as an output parameter, rather the {@link #getSize}call should be used. If an entry is configured to not reuse the byte array, a new array is allocated each time the entry is used as an output parameter, so the application can safely keep a reference to the byte array returned by {@link #getData} without danger that the array will be overwritten ina subsequent call.
By default the Offset property is zero and the Size property is the length of the byte array. However, to allow for optimizations involving the partial use of a byte array, the Offset and Size may be set to non-default values.
For DatabaseEntry output parameters, the Size will always be set to the length of the returned data and the Offset will always be set to zero.
However, for DatabaseEntry input parameters the Offset and Size are set to non-default values by the built-in tuple and serial bindings. For example, with a tuple or serial binding the byte array is grown dynamically as data is output, and the Size is set to the number of bytes actually used. For a serial binding, the Offset is set to a non-zero value in order to implement an optimization having to do with the serialization stream header.
Therefore, for output DatabaseEntry parameters the application can assume that the Offset is zero and the Size is the length of the byte array. However, for input DatabaseEntry parameters the application should not make this assumption. In general, it is safest for the application to always honor the Size and Offset properties, rather than assuming they have default values.
By default the specified data (byte array, offset and size) corresponds to the full stored key or data item. Optionally, the Partial property can be set to true, and the PartialOffset and PartialLength properties are used to specify the portion of the key or data item to be read or written. For details, see the {@link #setPartial(int,int,boolean)} method.
Note that the Partial properties are set only by the caller. They will never be set by a Database or Cursor method, nor will they every be set by bindings. Therefore, the application can assume that the Partial properties are not set, unless the application itself sets them explicitly.
Storage and retrieval for the {@link com.sleepycat.je.Database Database}and {@link com.sleepycat.je.Cursor Cursor} methods are based on key/datapairs. Both key and data items are represented by DatabaseEntry objects. Key and data byte arrays may refer to arrays of zero length up to arrays of essentially unlimited length.
The DatabaseEntry class provides simple access to an underlying object whose elements can be examined or changed. DatabaseEntry objects can be subclassed, providing a way to associate with it additional data or references to other structures.
Access to DatabaseEntry objects is not re-entrant. In particular, if multiple threads simultaneously access the same DatabaseEntry object using {@link com.sleepycat.je.Database Database} or {@link com.sleepycat.je.Cursor Cursor} methods, the results are undefined.
DatabaseEntry objects may be used in conjunction with the object mapping support provided in the {@link com.sleepycat.bind} package.
DatabaseEntry objects are used for both input data (when writing to a database or specifying a search parameter) and output data (when reading from a database). For certain methods, one parameter may be an input parameter and another may be an output parameter. For example, the {@link Database#get} method has an input key parameter and an output dataparameter. The documentation for each method describes whether its parameters are input or output parameters.
For DatabaseEntry input parameters, the caller is responsible for initializing the data array of the DatabaseEntry. For DatabaseEntry output parameters, the method called will initialize the data array.
Also note that for DatabaseEntry output parameters, the method called will always allocate a new byte array. The byte array specified by the caller will not be used. Therefore, after calling a method that returns output parameters, the application can safely keep a reference to the byte array returned by {@link #getData} without danger that the array will beoverwritten in a subsequent call.
By default the Offset property is zero and the Size property is the length of the byte array. However, to allow for optimizations involving the partial use of a byte array, the Offset and Size may be set to non-default values.
For DatabaseEntry output parameters, the Size will always be set to the length of the byte array and the Offset will always be set to zero.
However, for DatabaseEntry input parameters the Offset and Size are set to non-default values by the built-in tuple and serial bindings. For example, with a tuple or serial binding the byte array is grown dynamically as data is output, and the Size is set to the number of bytes actually used. For a serial binding, the Offset is set to a non-zero value in order to implement an optimization having to do with the serialization stream header.
Therefore, for output DatabaseEntry parameters the application can assume that the Offset is zero and the Size is the length of the byte array. However, for input DatabaseEntry parameters the application should not make this assumption. In general, it is safest for the application to always honor the Size and Offset properties, rather than assuming they have default values.
By default the specified data (byte array, offset and size) corresponds to the full stored key or data item. Optionally, the Partial property can be set to true, and the PartialOffset and PartialLength properties are used to specify the portion of the key or data item to be read or written. For details, see the {@link #setPartial(int,int,boolean)} method.
Note that the Partial properties are set only by the caller. They will never be set by a Database or Cursor method, nor will they every be set by bindings. Therefore, the application can assume that the Partial properties are not set, unless the application itself sets them explicitly.
See Using Partial DatabaseEntry Parameters for more information.
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |