It's in the title :)

There is a lot of code duplication across all schemata coming from the common fields. Since we don't have inheritance in AVRO their code is currently duplicated across all other schemata.

• Question 1: Do we want to fix this?
• Question 2: If yes, what kind of fix do we want?
  • I see two possible approaches here:
    • If we want to keep the 1:1 correspondence between JSON and AVRO field hierarchy, then we could try to generate the AVRO sources before actually compiling them with the AVRO compiler. Concretely, we could have a placeholder {{common_fields}} or so that we can put in an avsc file and have Maven replace it with the common field code before compilation.
    • Better option: If we can live with having the AVRO and JSON hierarchy no correspond 1:1 then we could simply create a record schema CommonFields that has all the common fields in it and put it at the top level of all the other schemata under a key common_fields or so.

As discussed in #4 , mobile events still need to be adjusted for this plan.

Avor can't handle spaces in field names, JSON can.
So far i have only found one example of this being a problem in the Group example that contains a field "total billed" which is a valid JSON but not a valid Avro field name.

I handled this by encoding any space as __escape_space__ in AVRO for now to make tests pass.
The other approach would be to keep a dictionary of these fields instead and replace from that (the upside of this is nicer AVRO field names, the downside is that it's not entirely trivial as that dictionary would have to be path aware, taking away a lot of the simple logic that Jackson gives us for converting JSON to Avro).

There is a bit of a difference between VideoPlaybackEvent and e.g. the various mobile events work.

While the mobile events had different properties, the VideoPlaybackEvents have all the same properties across their various event types.
This initially prompted me to just implement a single event for all of them with an enum to describe the different kinds:

    {
      "name": "event",
      "type": {
        "type": "enum",
        "name": "PlaybackEventType",
        "symbols": [
          "VIDEO_PLAYBACK_STARTED",
          "VIDEO_PLAYBACK_PAUSED",
          "VIDEO_PLAYBACK_INTERRUPTED",
          "VIDEO_PLAYBACK_BUFFER_COMPLETED",
          "VIDEO_PLAYBACK_SEEK_STARTED",
          "VIDEO_PLAYBACK_SEEK_COMPLETED",
          "VIDEO_PLAYBACK_RESUMED",
          "VIDEO_PLAYBACK_COMPLETED"
        ]
      }
    }

Question here:

Is this a desired solution or should I split this up into different classes for each event type?

• I think it's the driest we can do here, but it also requires custom logic for translating the JSON into Avro here in tests as well as in future production code.