-
Notifications
You must be signed in to change notification settings - Fork 60
Refactor relationship table operations to be functional index compatible #590
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cannot mock at this level, everything is just passing new args in anyway so the testing is deferred to the callees :)
| @Nullable | ||
| public static String getIndexedExpressionOrColumn(@Nonnull String assetType, @Nonnull String aspect, @Nonnull String path, | ||
| boolean nonDollarVirtualColumnsEnabled, @Nonnull String tableName, @Nonnull SchemaValidatorUtil schemaValidator) { | ||
| final String expectedLegacyColumnName = getGeneratedColumnName(assetType, aspect, path, nonDollarVirtualColumnsEnabled); | ||
| return getIndexedExpressionOrColumnGeneric(expectedLegacyColumnName, getExpressionIndexName(assetType, aspect, path), tableName, schemaValidator); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not tested directly in unit testing since the "inferred table variant" is tested thoroughly.
Summary
BUG=META-23290
This PR refactors relationship table operations to be aware of functional indexes (expression indexes) and will leverage them for queries if they exist, taking priority over any (virtual) column indexes.
Testing Done
unit testing thoroughly updated, will test this in EI as well
Checklist