Skip to content

Add method to get the schema (version) used for serialization of a message #362

Description

@acromarco

There are client libraries for other languages (e.g. java) that support automatic (de)serialization of message data based on a schema (https://pulsar.apache.org/docs/3.1.x/schema-overview/).
The node client does not have this feature yet (#242).

In theory it should be possible to deserialize the message data manually, BUT...
Some serialization formats like Avro require to know the exact schema that was used for serialization (mtth/avsc#447). In order to deal with schema evolution the client needs to know it's own compatible schema AND the schema used for serialization.
As far I understand, the automatic (de)serialization feature of Pulsar solves this problem by keeping a schema registry and tagging the messages with the used schema version.
If I understand right, the node client does not provide a method to get the schema used for serialization and not even a method to get the schema version of a message.
Assuming the need for schema evolution, this makes it impossible to deserialize reliably messages written by a java client library using an Avro schema,

I'm new to Pulsar and Avro, so please forgive (and correct) me if my understanding is wrong.

If my understanding is right, I wonder how difficult it would be to add a method to lookup the serialization schema on an message.

Activity

  1. changed the title [-]Add method to get the schema (version) used for serialization of an message[/-] [+]Add method to get the schema (version) used for serialization of a message[/+] on Jan 28, 2024
  2. dev-ankit commented on Oct 4, 2026

    @dev-ankit

    I opened #509, which adds Message.getSchemaVersion() (the writer schema version as a number, or null when the message has none). It wraps the C++ client's Message::getLongSchemaVersion().

    That covers the first half of this issue. The second half, looking up the schema for a given version, needs a Client.getSchemaInfo(topic, version) binding over the C++ Client::getSchemaInfoAsync. I plan to send that as a follow-up PR once #509 has been reviewed, so it can follow whatever conventions come out of that review. With both, Avro consumers can resolve schema evolution the way the Java and Python clients do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions