[
https://issues.apache.org/jira/browse/IGNITE-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-17748:
-----------------------------------------
Assignee: Konstantin Orlov
> Enrich InternalTable.scan API in order to support index scans
> -------------------------------------------------------------
>
> Key: IGNITE-17748
> URL: https://issues.apache.org/jira/browse/IGNITE-17748
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Assignee: Konstantin Orlov
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> SQL engine might specify index to use for scanning data along with some
> additional parameters like lower/upper bounds, including/excluding such
> bounds, columns to include etc. All in all we should enrich InternalTable
> scan api and provide corresponding data propagation logic.
> h3. Definition of Done
> *1.* InternalTable scan API has following method for both hash and sorted
> indexes scanning
> {code:java}
> Publisher<BinaryTuple> scan(int partId, @Nullable InternalTransaction tx,
> @NotNull UUID indexId, BinaryTuple key, BitSet columnsToInclude){code}
> and following method for sorted index scanning
> {code:java}
> Publisher<BinaryTuple> scan(int partId, @Nullable InternalTransaction tx,
> @NotNull UUID indexId, @Nullable BinaryTuple leftBound, @Nullable BinaryTuple
> rightBound, int flags, BitSet columnsToInclude) {code}
> Please check org.apache.ignite.internal.storage.index.SortedIndexStorage#scan
> for flags explanation, briefly
> {code:java}
> flags Control flags. {@link #GREATER} | {@link #LESS} by default. Other
> available values are {@link #GREATER_OR_EQUAL}, {@link #LESS_OR_EQUAL}.{code}
> *2.* Besides API itself corresponding scan-meta should be propagated to
> PartitionReplicaListener, so that some changes are also expected within
> ScanRetrieveBatchReplicaRequest. Please, pay attention that, that there's,
> probably, no sense in propagation same scan-meta within every
> ScanRetrieveBatchReplicaRequest, we might do it only wihtin initial request.
> *3.* Proper index is chosen. See optional indexId param and proper method of
> either IndexStorage or specific SortedIndexStorage is used.
> h3. Implementation Notes
> Mainly it's all specified in the section above. Seems that there's only one
> caveat left, however, non trivial one - BinaryRow to Binary tuple convertion,
> schema involved.
> h3. UPD:
> As was discussed, indexId will be always specified so that tables internals
> will never select PK-index or any other by themselves, so that @Nullable UUID
> indexId is now @NotNull UUID indexId.
>
> Besides API extension itself, it's required to build a bridge between
> https://issues.apache.org/jira/browse/IGNITE-17655 and internalTable.scan
> API, meaaning that it's required to create implementations for sql index
> interfaces introduced in 17655 that will propagate index scans to
> corresponding internalTable.scan API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
