NUMBER(1) in Oracle connector in version debezium 3.1.*

42 views
Skip to first unread message

Restwin E

unread,
Jul 16, 2025, 10:27:47 AMJul 16
to debezium
Hello everyone!
We decided to upgrade Debezium from version 2.6 to 3.1.1. We use Oracle connector for task. We have quite a lot of fields with the type NUMBER(1) and in the new version instead of the type int8 they come with the type string.

We have in the parameters set
"decimal.handling.mode": "string"
At the same time, if we set it to
"decimal.handling.mode": "precise"
then the connector does not allow records in Kafka at all. I did not find any problems in the logs. The connector starts normally, it seems that it does not see the records in Kafka. As soon as I change it to the old value - everything is ok, but NUMBER(1) = string :). 

We know about converter to BOOLEAN - io.debezium.connector.oracle.converters.NumberOneToBooleanConverter, but with it you also get a different type boolean...
We want to return with minimal changes to the state when int8 will be transformed for NUMBER(1). Otherwise, we will have to change the data model of all tables.

Chris Cranford

unread,
Jul 16, 2025, 10:54:56 PMJul 16
to debe...@googlegroups.com
Hi -

What you're facing is a breaking change introduced in Debezium as part of DBZ-7882.

The reported issue described how it was confusing that the Oracle connector behaved differently when setting `decimal.handling.mode` to `string` or `double` and it was not being applied consistently to numeric columns like it was for other connectors like PostgreSQL or SQL Server. So the behavior was adjusted so that the `decimal.handling.mode` is properly applied consistently across Oracle's types, just like other connectors.

If you would like to instead retain the old behavior and not change your data models, you could implement a `CustomConverter` that inspects the Column metadata and based on the length/scale, you could emit the value as an int8. The behavior you ideally would want to implement would look something like this (taken from OracleValueConverters)

    if (column.scale().isPresent()) {
        Integer scale = column.scale().get();
        if (scale <= 0) {
            int width = column.length() - scale;
            if (width < 3) {
                // Uses SchemaBuilder.int8();
            }
        }
    }

You can find all the breakpoints of width for 3, 5, 10, and 19 inside the OracleValueConverters method `getNumericConverter`.

Let us know if you have any questions.

Thanks,
-cc
--
You received this message because you are subscribed to the Google Groups "debezium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debezium+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/debezium/6a7e6f85-b28c-495d-85f5-27dcd74d0211n%40googlegroups.com.

Restwin E

unread,
Jul 17, 2025, 10:09:08 AMJul 17
to debezium
Hi

Thank you for your reply! We will think about possible solutions.

четверг, 17 июля 2025 г. в 05:54:56 UTC+3, Chris Cranford:

Chris Cranford

unread,
Jul 17, 2025, 11:22:16 AMJul 17
to debe...@googlegroups.com
Hi Restwin -

Given that this has come up multiple times from the community, it makes sense for us to introduce something for this sooner, rather than later. I can't say that what I am suggesting will be merged as-is, but at the very least there is an upstream PR [1] that introduces a toggle to restore the legacy 2.7 behavior from before we merged DBZ-7882. Let's see how this progresses in the coming days.

Thanks,
-cc

[1]: https://github.com/debezium/debezium/pull/6568

Restwin E

unread,
Jul 21, 2025, 10:36:02 AMJul 21
to debezium
Hi, Chris

I see that PR is merged and will be in the 3.3.0 alpha. That's good news!
Thank you for listening to the community.

четверг, 17 июля 2025 г. в 18:22:16 UTC+3, Chris Cranford:
Reply all
Reply to author
Forward
0 new messages