-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Make defaults for optional SchemaTransformProvider methods #30560
Make defaults for optional SchemaTransformProvider methods #30560
Conversation
@ahmedabu98 I assigned myself as reviewer. I'll review after checks run. |
Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment |
Failing test is a flake in SpannerChangeStreamErrorTest. @damondouglas it's ready for a review |
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.
LGTM <3
R: @robertwb |
Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control |
@@ -58,10 +59,14 @@ default String description() { | |||
SchemaTransform from(Row configuration); | |||
|
|||
/** Returns the input collection names of this transform. */ | |||
List<String> inputCollectionNames(); | |||
default List<String> inputCollectionNames() { |
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.
intellij thinks these methods are unused - is intellij wrong? or could they be removed?
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.
In reality, developers make their providers by extending TypedSchemaTransformProvider, which implements SchemaTransformProvider. I guess intellij might grey it out because they're not directly used from SchemaTransformProvider
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.
So if they override these methods but we never call them, does it matter?
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.
Ahh these methods are eventually called by the expansion service to create the discover response. Reference here:
Lines 733 to 734 in fedca3c
schemaTransformConfigBuilder.addAllInputPcollectionNames(provider.inputCollectionNames()); | |
schemaTransformConfigBuilder.addAllOutputPcollectionNames(provider.outputCollectionNames()); |
protected abstract Class<ConfigT> configurationClass(); | ||
@SuppressWarnings("unchecked") | ||
protected Class<ConfigT> configurationClass() { | ||
Optional<ParameterizedType> parameterizedType = |
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.
Since you just put it in an Optional
and then take it out again, might be simpler to go ahead like
@Nullable ParameterizedType parameterizedType = (ParameterizedType) getClass().getGenericSuperclass();
checkStateNotNull(superClass, "Could not ...");
return (Class<ConfigT>) parameterizedType.getActualTypeArguments[0];
FWIW I am not sure if getActualTypeArguments[0]
could still be a type variable in some cases. You might want to check that it is a usefully defined type in some more ways... but also this is probably just always going to work, because of how these things are authored. Very nice!
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.
Thanks, applied the suggestion.
@@ -58,10 +59,14 @@ default String description() { | |||
SchemaTransform from(Row configuration); | |||
|
|||
/** Returns the input collection names of this transform. */ | |||
List<String> inputCollectionNames(); | |||
default List<String> inputCollectionNames() { |
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.
So if they override these methods but we never call them, does it matter?
@@ -61,7 +61,7 @@ | |||
import org.junit.runners.JUnit4; | |||
|
|||
@RunWith(JUnit4.class) | |||
public class BigQueryStorageWriteApiSchemaTransformProviderTest { |
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.
This breaks DataflowV1 and V2 tests. Any reason moving them from unit test to integration test?
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.
CC: @ahmedabu98 @kennknowles @damondouglas
They use fake BigQuery service so has to be executed locally. Either exclude them from Dataflow test suites or move back to unit test?
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.
Ahh no reason, bad mistake. I'll open a PR to revert this part
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.
Thanks for catching this, pls take a look at #30623
Making some changes to reduce the necessary boilerplate when creating schema-aware transforms.
Some methods (
inputCollectionNames
,outputCollectionNames
) are not required to implement to use as a cross-language transform. These methods just provide information that may be helpful (e.g. to a remote SDK), but don't have any real functional use.Another method for TypedSchemaTransformProvider (
configurationClass
) can have a default implementation via reflection.Of course, implementations can continue implementing these methods as they see fit, but it probably shouldn't be required to do so.