Known Issues in Schema Registry
Learn about the known issues in Schema Registry, the impact or changes to the functionality, and the workaround.
- CDPD-40380: Authorization checking issue when Kerberos is disabled
-
Due to an issue in Ranger, when Kerberos is disabled then it is not possible to check authorization.
- CDPD-49304: AvroConverter does not support composite default values
- AvroConverter cannot handle schemas containing a
STRUCT
type default value. - CDPD-60160: Schema Registry Atlas integration does not work with Oracle databases
-
Schema Registry is unable to create entities in Atlas if Schema Registry uses an Oracle database. The following will be present in the Schema Registry log if you are affected by this issue:
ERROR com.cloudera.dim.atlas.events.AtlasEventsProcessor: An error occurred while processing Atlas events. java.lang.IllegalArgumentException: Cannot invoke com.hortonworks.registries.schemaregistry.AtlasEventStorable.setType on bean class 'class com.hortonworks.registries.schemaregistry.AtlasEventStorable' - argument type mismatch - had objects of type "java.lang.Long" but expected signature "java.lang.Integer"
This issue causes the loss of audit data on Oracle environments.
- CDPD-59015: Schema Registry does not create new versions of schemas even if the schema is changed
- Schema Registry uses a schema fingerprinting mechanism to
differentiate between schemas. However, fingerprinting does not take into consideration the
schema attributes of the field type. As a result, if you have two schemas where the only
difference is that one has type attributes defined and the other does not, they will be
considered identical by Schema Registry. For example, the following schemas are considered
identical:
#Schema V1 {"type":"record","name":"schema_name","namespace":"ns","fields":[{"name":"local_timestamp_micros_long","type":"long"}]} #Schema V2 {"type":"record","name":"schema_name","namespace":"ns","fields":[{"name":"local_timestamp_micros_long","type":{"type":"long","logicalType":"local-timestamp-micros"}}]}
Notice that the only difference is that in the second schema, the
local_timestamp_micros_long
field has a logical type specified. In cases like this, the new version of the schema is not created, the initial version is used. This is true even if the data that is being produced has a new schema version. The ID of the first schema version is used and is put in the serialized record. The new schema version is not created.This issue is common when using change data capture (CDC) connectors like the Debezium connectors. This is because CDC connectors create schemas with the logical typedecimal
based on the column type in the database schema. For example:
If the database schema changes (for example, the column type), it is possible that only{"type":"record","name":"schema_name","namespace":"ns","fields":[{"name":"database_column","type":{"type":"bytes","logicalType":"decimal","precision":64,"scale":0}}]}
scale
changes, which is a schema attribute.
In this case, even though{"type":"record","name":"schema_name","namespace":"ns","fields":[{"name":"database_column","type":{"type":"bytes","logicalType":"decimal","precision":64,"scale":1}}]}
scale
changed to 1, the first version of the schema is used wherescale
is 0. As a result, the data is consumed with the wrong scale. - OPSAPS-68708: Schema Registry might fail to start if a load balancer address is specified in Ranger
- Schema Registry does not start if the address specified in the Load Balancer Address Ranger property does not end with a trailing slash (/).
- OPSAPS-70971: Schema Registry does not have permissions to use Atlas after an upgrade
- Following an upgrade, Schema Registry might not have the required permissions in Ranger to access Atlas. As a result, Schema Registry's integration with Atlas might not function in secure clusters where Ranger authorization is enabled.