Replace AVRO Enums with Strings?

[slominskir]

Making changes to an AVRO Schema is more cumbersome than simply storing the possible String choices in a Kafka topic. However, without a Validation Gateway the constraint is not enforced. We may ultimately have a validation gateway, and even if not, a casual enforcement (at the application level) may be sufficient. One big advantage of storing choices in Kafka topics is admins could use the admin GUI to add/remove options at runtime easily. The fields that have options include:

• Location
• Priority
• Category

The trade off here may be analogous to a rational database DDL "in" Check Constraint vs Foreign Key Constraint.

[slominskir]

Using Strings stored in a Kakfa topic instead of an AVRO Enum also side-steps the naming limitations of enums:

https://github.com/JeffersonLab/jaws/wiki/AVRO-Schema-Peculiarities#naming-limitations

[slominskir]

Resolving locations to facilities could be accomplished by storing locations as records with two fields: a location name plus a facility name. Alternatively, a facilities topic keyed by facility name could contain an array value of locations. It may be possible to allow recursive declaration to allow arbitrary nesting / granularity (though applications should probably have recursion limit checks to avoid infinite recursion). In this case the facility name may be referred to more generically as "parent location".

[slominskir]

Left Priority as AVRO Enum for now.