implement encode/decode from/to single object format

[jangalinski]

This implements SingleObject as AvroEncodeFormat and AvroDecodeFormat. The In/Out Streams are realized using avros BinaryMessage[De|En]coder which reads/writes a GenericRecord to singleObjectBytes and uses the existing toRecord/fromRecord functions to convert to instance of data class .

[jangalinski]

OK, I worked on all changes and refactored the test so it does encode/decode without using any specific Avro.default methods.

I kind of lost it during reformatting ... so this where more very small commits than I intended. Sorry for that. But I assume you will squash anyway, right?

[jangalinski]

BTW: We are starting to use and like avro4k ... but we have a lot of questions and ideas.

Would you be open to allowing discussions on this repo? I would like to avoid raising "Question: ..." issues en gros.

[Chuckame]

Let's squash them when going to merge.

Let's discuss! FYI, big refactoring are incoming, so for sure we'll be open to discuss!

[thake]

BTW: We are starting to use and like avro4k ... but we have a lot of questions and ideas.

Would you be open to allowing discussions on this repo? I would like to avoid raising "Question: ..." issues en gros.

Thanks for the feedback :) I hope we can improve our documentation so that fewer questions stay open.

I'll give the discussions section a try. I was hesitant to do so because now users have to choose whether Issues or Discussions is the right place for contact. But as I said, I'll give it a try ^^. Thanks for the suggestion.

[jangalinski]

Hi @Chuckame , I finally found the time to get back on this.

What I did now: there is a String Constant containing: "[C3 01 CD 1D 19 01 C3 39 C6 61 06 62 61 72]"

This represents FooString("bar") in single object encoding ... written with the Java generated encoder.

The tests I rewrote now make sure that:

• we can decode the java-bytes using avro4k - compatibility for reading
• we can can encode kotlin to the same byte-hex (with the exclusion of the schema-fingerprint bytes, as these differ - we had to use different naming for the java-schema) - compatibility with specification.
• we can encode kotlin and decode java. - compatibility for writing

I hope this is what you had in mind.

[Chuckame]

Hey @jangalinski thanks it was something like that !

We are planning a v2 that will change a lot the codebase, and will make breaking changes, to make some room for all the new features and improvements, so merging your PR will add more work of adaptation. We will at least permit extension, at most implement this feature directly.

We won't close this PR unless the v2 implement it.

We are not forgetting this feature 😄

Sorry for the very long delay.

[Chuckame]

I'm closing it as it's going to be included in the v2