[
https://issues.apache.org/jira/browse/IGNITE-17720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608576#comment-17608576
]
Ivan Bessonov commented on IGNITE-17720:
----------------------------------------
My humble opinion - we probably shouldn't. I don't really understand the way we
could use it. Let me tell you why.
Public SQL API expects tuples as a part of result set. They are not expected to
have RowId in them. I guess SQL just doesn't need it.
The only use for the full scan is a situation where good index just doesn't
exist. On top of everything, there's a chance that it will be implemented using
PK and explicit scan method is not required at all. I'm not sure.
I heard index rebuild being mentioned. Partition scan of this design is
inapplicable for such operations. It returns only a single version for each
row. Index rebuild requires all version for each rows. These two approaches are
incompatible.
Let's wait for [~Sergey Uttsel]'s reply though.
> Extend MvPartitionStorage scan API with write intent resolution capabilities
> ----------------------------------------------------------------------------
>
> Key: IGNITE-17720
> URL: https://issues.apache.org/jira/browse/IGNITE-17720
> Project: Ignite
> Issue Type: Bug
> Reporter: Semyon Danilov
> Priority: Major
> Labels: ignite-3
>
> Commit of RW transaction is not instantaneous. RO transaction might require
> reads of data that's in the process of being committed. Current API doesn't
> support such scenario.
> RO API in partition storage has only two methods: read and scan.
> For read see https://issues.apache.org/jira/browse/IGNITE-17627
> h3. Scan
> This one is tricky, we can't just return a cursor. Special type of cursor is
> required, and it must allow same read capabilities on each individual element.
> API is to be defined.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
