-
Task
-
Resolution: Done
-
Major
-
None
-
False
-
False
-
Undefined
-
For the OracleOffsetContext we should handle this seamlessly without needing to force the users to perform a re-snapshot. Simply add a new field that's meant to represent the SCN as a BigInteger and when loading the offsets, we check for the existence of the new field and if so, we use that value; if not we read the SCN from the legacy field. From here forward, only the new field will be written to.
For the SourceInfo block, there is no need to over-complicate this with a V1/V2 scheme like we've done in the past for connectors that weren't incubating. Here the suggestion would be to convert the field to a string and simply write the value as such.
The code contributed in DBZ-2855 used BigInteger to store the SCN in the logminer metadata queries; however it may be useful to use unsigned long from Java 8 instead, need to confirm with the team. If we go with the latter, it would make sense to synchronize this decision with the code changes included in the associated issue.
- relates to
-
DBZ-2855 Missing log file error when current SCN differs from snapshotted in Oracle connector and Logminer
- Closed