Open etspaceman opened 1 year ago
Hi @etspaceman - thanks for this issue. I've locally produced a test that reproduces this issue.
What do you want to see as a solution? Is a suitable MVP: do not fail if there stream schema and table schema only differ by schema comments?
I think that would suffice for the comments portion. But we should be able to also support compatible differences between the schemas. E.g. if an optional field is present on the spark schema, but not the flink one, we should still be able to continue the job without failing
Bug
Describe the problem
The Flink adapter today attempts to compare schemas and see if they are compatible. It does this by:
StructType
for the object being produced, as well as the underlying schematoJson
outputsThe primary issue here is that the
Json
outputs of the underlying schema could containcomment
metadata, but the one generated by the produced object has no understanding of these comments. If the underlying schema has some descriptive comments, the Json representations will not match, even though the schemas are indeed compatible.Using
mergeSchema
would fix this issue, but it is not desirable as it would remove all of the comment metadata from the schema.On top of this however, this logic is concerning in that any change to the underlying schema could result in a Flink application failure. This includes backwards compatible changes, like adding an optional field, or updating a field to optional from required. The compatibility layer should accept these scenarios and continue to allow writes.
Steps to reproduce
Observed results
An unrecoverable error is produced, rendering the Flink application blocked in progress.
Expected results
Flink is able to write to the underlying schema
Further details
Full stack trace, but without the schema (as it is internal). Can share the schema output to a DBX representative on a private channel.
Environment information
Willingness to contribute
The Delta Lake Community encourages bug fix contributions. Would you or another member of your organization be willing to contribute a fix for this bug to the Delta Lake code base?