Interface ReadableTransaction

  • All Known Subinterfaces:
    WriteableTransaction

    public interface ReadableTransaction
    Represents a readable transaction on a storage engine.
    • Method Detail

      • read

        ByteString read​(TreeName treeName,
                        ByteSequence key)
        Reads the record's value associated to the provided key, in the tree whose name is provided.
        Parameters:
        treeName - the tree name
        key - the record's key
        Returns:
        the record's value, or null if none exists
      • openCursor

        Cursor<ByteString,​ByteString> openCursor​(TreeName treeName)
        Opens a cursor on the tree whose name is provided.
        Parameters:
        treeName - the tree name
        Returns:
        a new cursor
      • openBulkCursor

        default Cursor<ByteString,​ByteString> openBulkCursor​(TreeName treeName)
        Opens a cursor on the tree whose name is provided, for a walk of that whole tree with no client operation waiting on it: an export, a verify, a rebuild, or the load of a tree while the backend opens.

        A storage engine that bounds how long a statement may take must not bound such a walk as it bounds the work of a client operation: what this legitimately takes follows the size of the tree, and cutting it short fails an administrative task that would otherwise have run to the end. An engine with no such bound - every one but the JDBC backend - answers this exactly as openCursor(TreeName) does.

        Parameters:
        treeName - the tree name
        Returns:
        a new cursor
      • getRecordCount

        long getRecordCount​(TreeName treeName)
        Returns the number of key/value pairs in the provided tree.
        Parameters:
        treeName - the tree name
        Returns:
        the number of key/value pairs in the provided tree.
      • treeExists

        boolean treeExists​(TreeName treeName)
        Returns whether the tree whose name is provided is present in the storage.

        This is not the same question as whether the tree is empty, and it cannot be answered by reading from the tree: a storage is free to materialize a tree on first access - the JE backend opens its databases with setAllowCreate(true) - or to reject the access outright, as the JDBC backend does when no table of that name exists. Callers that must distinguish "never written" from "written and since emptied", such as the compressed schema deciding whether it has anything to migrate, need this instead.

        A storage whose trees have no existence of their own cannot keep that distinction: the Cassandra backend holds every tree of a backend as a partition of the one table named after the backend id, so it answers whether the partition holds a record and a tree that was emptied reports itself absent. Nothing may be inferred from a false beyond "there is nothing to read here".

        Parameters:
        treeName - the tree name
        Returns:
        true if the tree exists, false otherwise