-
Notifications
You must be signed in to change notification settings - Fork 112
Allow index maintainer implementors to specify their own index match candidate #3640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
6f1e073
0abc66f
1d15cea
422a5f2
75e06d6
dc8e851
7719731
2e086db
6e04ce1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,10 +21,13 @@ | |
package com.apple.foundationdb.record.provider.foundationdb; | ||
|
||
import com.apple.foundationdb.annotation.API; | ||
import com.apple.foundationdb.record.RecordMetaData; | ||
import com.apple.foundationdb.record.metadata.Index; | ||
import com.apple.foundationdb.record.metadata.IndexValidator; | ||
import com.apple.foundationdb.record.query.plan.cascades.MatchCandidate; | ||
|
||
import javax.annotation.Nonnull; | ||
import java.util.Collections; | ||
|
||
/** | ||
* A factory for {@link IndexMaintainer}. | ||
|
@@ -68,4 +71,49 @@ public interface IndexMaintainerFactory { | |
*/ | ||
@Nonnull | ||
IndexMaintainer getIndexMaintainer(@Nonnull IndexMaintainerState state); | ||
|
||
/** | ||
* Create {@link MatchCandidate}s to use for the given {@link Index}. | ||
* Implementors can assume that the index is one of this factory's | ||
* {@linkplain #getIndexTypes() supported types}. Note that this is | ||
* structured as a method on the maintainer factory so that indexes | ||
* defined outside the core repository can define the structure | ||
* used by the planner to match them. However, use cases should be | ||
* aware that the planner does not provide a stable API (yet) for | ||
* what these match candidates should contain, and so outside | ||
* implementors should be mindful that it is on them to keep up | ||
* with the planner as it changes. For that reason, this should only | ||
* be overridden by users who know what they are doing. | ||
* | ||
* <p> | ||
* By default, this returns an empty collection. This means that the | ||
* index will not be matchable by the {@link com.apple.foundationdb.record.query.plan.cascades.CascadesPlanner}. | ||
* Index types that want to be used in plans should implement this | ||
* method. Utility methods in {@link MatchCandidate} can be used to | ||
* create, for example, canonical expansions of indexes that behave like | ||
* indexes defined in the core repository (e.g., {@link com.apple.foundationdb.record.metadata.IndexTypes#VALUE} | ||
* indexes). | ||
* </p> | ||
* | ||
* <p> | ||
* Indexes may return more than one {@link MatchCandidate}. This can be | ||
* useful for index types that have more than one way of being scanned. | ||
* For example, the {@link com.apple.foundationdb.record.metadata.IndexTypes#RANK} | ||
* index can be scanned {@link com.apple.foundationdb.record.IndexScanType#BY_VALUE}, | ||
* at which point it behaves just like a {@link com.apple.foundationdb.record.metadata.IndexTypes#VALUE} | ||
* index, or it can be scanned {@link com.apple.foundationdb.record.IndexScanType#BY_RANK}, | ||
* at which point it behaves very differently. The different scan types are reflected | ||
* in different {@link MatchCandidate} which encode different information about | ||
* the index and how it should be scanned. | ||
* </p> | ||
* | ||
normen662 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
* @param metaData the meta-data in which the index is defined | ||
* @param index the index to expend | ||
* @param reverse whether the index is to be scanned in reverse | ||
* @return a collection of {@link MatchCandidate}s to match the index against | ||
*/ | ||
@Nonnull | ||
default Iterable<MatchCandidate> createMatchCandidates(@Nonnull RecordMetaData metaData, @Nonnull Index index, boolean reverse) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I cannot remember the specifics but the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I looked it up and it's only the planning of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I did notice that, but I didn't look too deeply into it. I'm not actually sure why we can't rely on the sort order on the sort descriptor. If we could, I'd be happy to remove this parameter |
||
return Collections.emptyList(); | ||
} | ||
} |
Uh oh!
There was an error while loading. Please reload this page.