Skip to content
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

KAFKA-10675: Add schema name to ConnectSchema.validateValue() error message #9541

Merged
merged 4 commits into from
Jul 10, 2021

Conversation

Iskuskov
Copy link
Contributor

@Iskuskov Iskuskov commented Nov 2, 2020

https://issues.apache.org/jira/browse/KAFKA-10675

The following error message

org.apache.kafka.connect.errors.DataException: Invalid Java object for schema type INT64: class java.lang.Long for field: "moderate_time"

can be confusing because java.lang.Long is acceptable type for schema INT64.

In fact, in this case org.apache.kafka.connect.data.Timestamp is used but this info is not logged.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@Iskuskov Iskuskov force-pushed the KAFKA-10675 branch 2 times, most recently from b6912b9 to 12ddffd Compare February 20, 2021 22:45
@Iskuskov
Copy link
Contributor Author

@C0urante, @gharris1727, could you take a look at this please?

Comment on lines 268 to 275
private static String buildSchemaInfo(Schema schema) {
StringBuilder schemaInfo = new StringBuilder("schema");
if (schema.name() != null) {
schemaInfo.append(" \"").append(schema.name()).append("\"");
}
schemaInfo.append(" with type ").append(schema.type());
return schemaInfo.toString();
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that this is only used in one place, and the string that it creates is itself added to a formatted string, I think it'd be a bit more readable if we removed this method and inlined all the logic where it's being invoked right now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for reviewing! Fixes were pushed

Copy link
Contributor

@C0urante C0urante left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, one comment about readability but you can take it or leave it.

I'm also wondering if we might consider dropping the " for field ..." part from the exception message if field is null (which occurs with the two-argument variant of ConnectSchema::validateValue), but that can be left as follow-up work if you'd prefer.

@Iskuskov Iskuskov force-pushed the KAFKA-10675 branch 2 times, most recently from 9cfcb66 to c8a361c Compare March 4, 2021 20:53
@Iskuskov
Copy link
Contributor Author

Iskuskov commented Mar 5, 2021

@kkonstantine, could you take a look at this please?

@Iskuskov
Copy link
Contributor Author

@rhauch, could you take a look at this please?

@Iskuskov
Copy link
Contributor Author

@chia7712, @ijuma, could you take a look at this please?

Copy link
Contributor

@rhauch rhauch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @Iskuskov. LGTM.

We're technically still frozen on the 2.6 and 2.8 branches, but both have RCs that passed their PMC votes and should be unblocked soon. I'll hopefully be able to merge and backport soon.

@@ -266,7 +267,7 @@ public static void validateValue(String name, Schema schema, Object value) {
private static List<Class> expectedClassesFor(Schema schema) {
List<Class> expectedClasses = LOGICAL_TYPE_CLASSES.get(schema.name());
if (expectedClasses == null)
expectedClasses = SCHEMA_TYPE_CLASSES.get(schema.type());
expectedClasses = SCHEMA_TYPE_CLASSES.getOrDefault(schema.type(), Collections.emptyList());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strictly speaking, this shouldn't be necessary as SCHEMA_TYPE_CLASSES should have a Schema instance for all Schema.Type literals. And with SchemaBuilder a connector or converter cannot create a schema instance with a null Schema.Type.

However, it is possible to construct a ConnectSchema instance with a null Type reference (like what FakeSchema essentially does in the existing test), which of course without this change would result in this method returning a null list.

So +1 for this line change since it simplifies the error handling in the calling code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Highly appreciate your comment

@kkonstantine
Copy link
Contributor

@rhauch seems that this fix was approved but we were blocked on release candidates of previous releases. To include to 3.0 (as well as previous releases) and avoid entering a new code freeze phase we'd need to merge asap. Please take another look if possible.

@Iskuskov in the meantime a merge conflict has been introduced. Would you mind rebasing on top of the latest changes on trunk?

@Iskuskov
Copy link
Contributor Author

Iskuskov commented Jul 9, 2021

@Iskuskov in the meantime a merge conflict has been introduced. Would you mind rebasing on top of the latest changes on trunk?

@kkonstantine thank you! Rebased

Copy link
Contributor

@kkonstantine kkonstantine left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We recently enabled warnings on the use of raw types. That's why the build failed after the rebase.
Adding a suggestion and merging to the PR to allow the tests to run.

Copy link
Contributor

@kkonstantine kkonstantine left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test failures are not relevant.
LGTM

@kkonstantine kkonstantine merged commit efe6029 into apache:trunk Jul 10, 2021
kkonstantine pushed a commit that referenced this pull request Jul 10, 2021
…essage (#9541)

The following error message
`org.apache.kafka.connect.errors.DataException: Invalid Java object for schema type INT64: class java.lang.Long for field: "moderate_time"`
can be confusing because java.lang.Long is acceptable type for schema INT64.

In fact, in this case `org.apache.kafka.connect.data.Timestamp` is used but this info is not logged.

Reviewers: Randall Hauch <[email protected]>, Chris Egerton <[email protected]>, Konstantine Karantasis <[email protected]>
kkonstantine pushed a commit that referenced this pull request Jul 10, 2021
…essage (#9541)

The following error message
`org.apache.kafka.connect.errors.DataException: Invalid Java object for schema type INT64: class java.lang.Long for field: "moderate_time"`
can be confusing because java.lang.Long is acceptable type for schema INT64.

In fact, in this case `org.apache.kafka.connect.data.Timestamp` is used but this info is not logged.

Reviewers: Randall Hauch <[email protected]>, Chris Egerton <[email protected]>, Konstantine Karantasis <[email protected]>
kkonstantine pushed a commit that referenced this pull request Jul 10, 2021
…essage (#9541)

The following error message
`org.apache.kafka.connect.errors.DataException: Invalid Java object for schema type INT64: class java.lang.Long for field: "moderate_time"`
can be confusing because java.lang.Long is acceptable type for schema INT64.

In fact, in this case `org.apache.kafka.connect.data.Timestamp` is used but this info is not logged.

Reviewers: Randall Hauch <[email protected]>, Chris Egerton <[email protected]>, Konstantine Karantasis <[email protected]>
kkonstantine pushed a commit that referenced this pull request Jul 10, 2021
…essage (#9541)

The following error message
`org.apache.kafka.connect.errors.DataException: Invalid Java object for schema type INT64: class java.lang.Long for field: "moderate_time"`
can be confusing because java.lang.Long is acceptable type for schema INT64.

In fact, in this case `org.apache.kafka.connect.data.Timestamp` is used but this info is not logged.

Reviewers: Randall Hauch <[email protected]>, Chris Egerton <[email protected]>, Konstantine Karantasis <[email protected]>
xdgrulez pushed a commit to xdgrulez/kafka that referenced this pull request Dec 22, 2021
…essage (apache#9541)

The following error message
`org.apache.kafka.connect.errors.DataException: Invalid Java object for schema type INT64: class java.lang.Long for field: "moderate_time"`
can be confusing because java.lang.Long is acceptable type for schema INT64.

In fact, in this case `org.apache.kafka.connect.data.Timestamp` is used but this info is not logged.

Reviewers: Randall Hauch <[email protected]>, Chris Egerton <[email protected]>, Konstantine Karantasis <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants