Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Namespaced Schema Field for fixed logical type Decimal Fails #2926

Open
LucasGithubAcc opened this issue Jan 12, 2024 · 0 comments
Open

Namespaced Schema Field for fixed logical type Decimal Fails #2926

LucasGithubAcc opened this issue Jan 12, 2024 · 0 comments

Comments

@LucasGithubAcc
Copy link

After upgrading from v6.2.1 to v7.5.2 confluent-community edition Kafka Connect, I encountered the error: “Mismatched names: name already added to SchemaBuilder (org.apache.kafka.connect.data.Decimal) differs from name in source schema (avro.customnamespace.BP)” . This occurred when testing JDBC and s3 sink connectors reading from a Kafka topic, which reads avro Schemas stored in Schema Registry.

An example of the failing schema:

{
	"name": "bP",
	"type": [
		"null",
		{
			"type": "fixed",
			"name": "BP",
			"namespace": "avro.customnamespace",
			"size": 8,
			"logicalType": "decimal",
			"precision": 18,
			"scale": 6
		}
	]
},

The solutions I have tested to work are:

  1. Add field “connect.name”: “org.apache.kafka.connect.data.Decimal” → This does not affect the Kafka Topic message, but does require changing schema in Schema Registry
  2. Remove name & namespace for field schema → No error but changes the field name in the Kafka topic message
  3. Downgrading kafka-connect-avro-data jar to 6.2.6 or below → Do not need to change anything else for this fix, but unsure if there are other side effects of downgrading one specific jar and also just a bad practice, but does not require changing the Schema or affect the data

My question is:
a. Are there any other better approaches/solutions to the above?
b. Are having named fields for decimal logical type fields intended to be allowed, or is it more correct to remove that (ie option 1 or 3?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant