oneOf) will be converted to type unions. The corresponding Avro schema can be less stringent. For example, the following Json schema
notis not supported, as there is no equivalent validation mechanism in Avro schema.
/a-zA-Z0-9_/) are allowed in a stream or field name. Any special character will be converted to an alphabet or underscore. For example,
special_character_names. The original names will be stored in the
docproperty in this format:
stringJson field will be typed as
["null", "string"]in Avro. This is necessary because the incoming data stream may have optional fields.
itemsproperty is an array, it means that each element in the array should follow its own schema sequentially. For example, the following specification means the first item in the array should be a string, and the second a number.
["null", "string", "number"], which is less stringent:
idfield, and second has an
idfields have slightly different types.
id_part_2, will also be merged. In this way, all possible valid elements from the Json array can be converted to Avro records.
id_part_1is a union of
string, which comes from the first and second
iddefinitions, respectively, in the original Json
array_fieldoriginally does not have a
messagefield. However, because its schema is merged with the second object definition, it has a null
messagefield in the Avro record.
items, the element in that array field may have any type. However, Avro requires that each array has a clear type specification. To solve this problem, the elements in the array are forced to be
identifierarray field is converted to string.
_airbyte_additional_propertiestyped as a nullable
usernameis moved under
_ab_additional_propertiesas serialized strings, including the original object
objectfield has no
propertiesspecification, all fields within this
objectwill be put into the aforementioned
stringfield, and its value will be serialized to string.