-
Notifications
You must be signed in to change notification settings - Fork 1
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
A question regarding parsing algorithm #8
Comments
It seems that it can detect changed schema. does not work for you? If not, it is helpful showing the reproducible steps about issue. |
First of all a small disclaimer - I'm just trying to figure out how it works, so maybe I totally misunderstand that. So sorry for talking nonsense in advance :) It seems to be able to detect changed schema, but only if schemas are incompatible. But take a look on this example:
It is able to parse |
Hmm, something weird. $ bundle exec ruby -Ilib -Itest test/plugin/test_parser_avro.rb -v -n /test_confluent_registry$/
Failure: test_confluent_registry(AvroParserTest::SchemaURLTest)
test/plugin/test_parser_avro.rb:480:in `block in test_confluent_registry'
477:
478: # case 2
479: d.instance.parse(encoded2) do |_time, record|
=> 480: assert_equal datum2, record
481: end
482: end
483: end
/work/fluentd/plugins/fluent-plugin-parser-avro/lib/fluent/plugin/parser_avro.rb:125:in `parse'
test/plugin/test_parser_avro.rb:479:in `test_confluent_registry'
<{"birthDate"=>166666666666,
"firstName"=>"Aleen",
"lastName"=>"Terry",
"verified"=>true}> expected but was
<{"birthDate"=>166666666666, "firstName"=>"Aleen", "lastName"=>"Terry"}>
diff:
? {"birthDate"=>166666666666, "firstName"=>"Aleen", "lastName"=>"Terry"}
- "firstName"=>"Aleen",
- "lastName"=>"Terry",
- "verified"=>true} |
yes, exactly, record in the second case doesn't contain |
Hello,
I have one question regarding the implementation of parser when schema registry is being used. If I understand correctly on a first message parsing you query for schema and use that schema for parsing all further messages unless there was a parsing error, correct me if I'm wrong. If so, wouldn't it make sense to parse messages with particular schema corresponding to message's schemaId? Because currently, if schema got evolved, let's say a new optional field's been added, it won't appear in the output because message is parseable with old schema.
Thank you!
The text was updated successfully, but these errors were encountered: