wangxianghu commented on a change in pull request #2963:
URL: https://github.com/apache/hudi/pull/2963#discussion_r645925416
##########
File path:
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/schema/SchemaProvider.java
##########
@@ -34,18 +32,9 @@
@PublicAPIClass(maturity = ApiMaturityLevel.STABLE)
public abstract class SchemaProvider implements Serializable {
- protected TypedProperties config;
+ protected Schema sourceSchema;
- protected JavaSparkContext jssc;
-
- public SchemaProvider(TypedProperties props) {
Review comment:
> Can we think about making this backwards compatible. If a user defined
their own schemaProvider, super(...) calls may start to fail if we remove these
2 constructors. If this was a private interface, we could evolve w/o much
consideration, but since this is a public api, we got to be careful.
@nsivabalan, Yes, we should be careful with an abstract class
in the current design, the user-defined schema provider does not need to
call the `super(...)`.since there are no confs used in abstract class.
maybe we can make the base `SchemaProvider` an interface by the way.
because its child classes have little in common
which one is better?
1. Make the `SchemaProvider` an interface
2. leave it it is now, `SchemaProvider` has no common conf and context
3. add common conf and context to `SchemaProvier` to make the schema
providers more organized
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
