[ https://issues.apache.org/jira/browse/IGNITE-17308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ivan Bessonov updated IGNITE-17308: ----------------------------------- Description: 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. was: 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. 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. > Revisit SortedIndexMvStorage interface > -------------------------------------- > > Key: IGNITE-17308 > URL: https://issues.apache.org/jira/browse/IGNITE-17308 > Project: Ignite > Issue Type: Improvement > Reporter: Ivan Bessonov > 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)