[
https://issues.apache.org/jira/browse/IGNITE-17308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev reassigned IGNITE-17308:
--------------------------------------------
Assignee: Aleksandr Polovtcev
> Revisit SortedIndexMvStorage interface
> --------------------------------------
>
> Key: IGNITE-17308
> URL: https://issues.apache.org/jira/browse/IGNITE-17308
> Project: Ignite
> Issue Type: Improvement
> Reporter: Ivan Bessonov
> Assignee: Aleksandr Polovtcev
> Priority: Major
> Labels: ignite-3
>
> Currently, SortedIndexMvStorage is a very weird mixture of many things. Its
> contract is far from obvious and it's only used in tests as a part of
> "reference implementation".
> Originally, it was implemented when the vision of MV store wasn't fully
> solidified.
> h3. API changes
> * {{IndexRowEx}} should disappear. It was a quick and dirty solution. It
> should be replaced with {{{}InternalTuple{}}}, with the requirement that
> every internal tuple can be converted into a IEP-92 format.
> * {{scan}} should not return rows, but only indexed rows and RowId
> instances. Index scan should NOT by itself filter-out invalid rows, this will
> be performed outside of scan.
> * TxId / Timestamp parameters are no longer applicable, given that index
> does not perform rows validation.
> * Partition filter should be removed as well. To simplify things, every
> partition will be indexed {+}independently{+}.
> * {{supportsBackwardsScan}} and {{supportsIndexOnlyScan}} can be removed for
> now. Former can be brought back in the future, while latter makes no sense
> considering that indexes are not multiversioned.
> * new methods, like {{update}} and {{remove}} should be added to API.
> h3. New API for removed functions
> * There should be a new entity on top of partition and index store. It
> updates indexes and filters scan queries. There's no point in fully designing
> it right now, all we need is working tests for now. Porting current tests to
> new API is up to a developer.
> h3. Other
> I would say that effective InternalTuple comparison is out of scope. We could
> just adapt current test code somehow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
