- All Superinterfaces:
- MethodFactory, org.apache.derby.iapi.services.monitor.ModuleSupportable
- public interface ConglomerateFactory
- extends MethodFactory
The factory interface for all conglomerate access methods.
| Fields inherited from interface org.apache.derby.iapi.store.access.conglomerate.MethodFactory |
MODULE |
HEAP_FACTORY_ID
public static final int HEAP_FACTORY_ID
- See Also:
- Constant Field Values
BTREE_FACTORY_ID
public static final int BTREE_FACTORY_ID
- See Also:
- Constant Field Values
getConglomerateFactoryId
public int getConglomerateFactoryId()
- Return the conglomerate factory id.
Return a number in the range of 0-15 which identifies this factory.
Code which names conglomerates depends on this range currently, but
could be easily changed to handle larger ranges. One hex digit seemed
reasonable for the number of conglomerate types currently implemented
(heap, btree) and those that might be implmented in the future: gist,
gist btree, gist rtree, hash, others? ).
createConglomerate
public Conglomerate createConglomerate(TransactionManager xact_mgr,
int segment,
long input_containerid,
org.apache.derby.iapi.types.DataValueDescriptor[] template,
org.apache.derby.iapi.store.access.ColumnOrdering[] columnOrder,
java.util.Properties properties,
int temporaryFlag)
throws org.apache.derby.iapi.error.StandardException
- Create the conglomerate and return a conglomerate object
for it. It is expected that the caller of this method will place the
the resulting object in the conglomerate directory.
readConglomerate
public Conglomerate readConglomerate(TransactionManager xact_mgr,
org.apache.derby.iapi.store.raw.ContainerKey container_key)
throws org.apache.derby.iapi.error.StandardException
- Return Conglomerate object for conglomerate with container_key.
Return the Conglomerate Object. This is implementation specific.
Examples of what will be done is using the key to find the file where
the conglomerate is located, and then executing implementation specific
code to instantiate an object from reading a "special" row from a
known location in the file. In the btree case the btree conglomerate
is stored as a column in the control row on the root page.
This operation is costly so it is likely an implementation using this
will cache the conglomerate row in memory so that subsequent accesses
need not perform this operation.