[
https://issues.apache.org/jira/browse/IGNITE-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17748:
-------------------------------------
Description:
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.
was:
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.
> 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
> 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)
