...
In Ignite 3 we want to provide more flexibility for end users to choose the best storage implementation for their use cases. To achieve this we need to define a minimal API and hide all implementation details about particular storage implementations behind it.
As a starting point I suggest to define the following interfaces (of course they'll evolve when other components start integrating them):
...
Code Block | ||||
---|---|---|---|---|
| ||||
/** Interface enabling obtaining locks on Keys in Storage. */
public interface LockManager {
/** Locks given Key. */
public void lock(Key key);
/** Unlocks given Key. */
public void unlock(Key key);
} |
Code Block | ||||
---|---|---|---|---|
| ||||
public interface SortedInternalStore { /** Put row to index. */ void put(Row r); /** Remove row from index. */ void remove(Row r); /** * Return rows between lower and upper bounds. * Fill results rows by fields specified at the projection set. * * @param low Lower bound of the scan. * @param up Lower bound of the scan. * @param opts Scan bound option. * @param proj Set of the columns IDs to fill results rows. */ Cursor<Row> scan(Row low, Row up, ScanBoundOption opts, BitSet proj); enum ScanBoundOption { /** Include to results rows that equal all bounds. */ INCLUDE_INCLUDE, /** Include to results rows that are equal lower bound and exclude from results rows that are equal upper bounds. */ INCLUDE_EXCLUDE, /** Exclude from results rows that are equal lower bound and include to results rows that are equal upper bounds. */ EXCLUDE_INCLUDE, /** Include from results rows that equal all bounds. */ EXCLUDE_EXCLUDE } } |
As we aim to have more than one option of storage we need to keep storage api separated from implementation, so we'll have one module containing api and a separate module for each specific implementation.
...