This message was deleted.
# general
s
This message was deleted.
l
It doesn’t need an
avroBytesDecoder
(or
protoBytesDecoder
), it just needs to ignore the first byte!
b
l
Hey @Bibek Sahoo, sadly it doesn’t.
(You can also use JSON or Protobuf with Schema Registry, but that’s a story for another time.)
@Hellmar Becker mentions it, but I can’t find any example on his blog (or anywhere else) how to ingest JSON with Schema Registry.
h
@Luiz Augusto my bad, I actually never tested JSON-SR. I’ll find out
l
Thanks @Hellmar Becker!
h
it’s actually not supported now, I corrected the blogpost
😐 1
c
no one has been super motivated to implement it because we can’t really ship the jar to make it work out of the box (like protobuf + schema-registry actually, though someone was motivated to implement that one)
it probably wouldn’t be terribly hard, just make an extension that uses the json-schema-provider library and probably looks pretty similar to avro and protobuf implementations
i assume could re-use a bunch of stuff from standard json input format
the avro implementation is apache licensed and part of regular schema-registry client, but protobuf and json are confluent license
if anyone is interested in implementing it i’d be happy to guide and review (assuming implement it for real and deserialize json per the schema rather than just ignoring the schema part)
and https://github.com/apache/druid/pull/10839 has discussion about license stuff, though it implements older parseSpec stuff that isn’t necessary for new stuff, but https://github.com/apache/druid/pull/11018 would be the main thing to model after i think in order to actually implement
l
What would be the real advantage of using the JSON schema here? For Avro and Proto it makes sense as it requires deserialization, and It’s not like they are actually building up the full ingest schema from the SR output. I still need to manually (or programmatically) fill the
flattenSpec
and
dimensionsSpec
for everything not in the root level, or they will be inside json types.