Details
-
Task
-
Resolution: Done
-
Major
-
None
-
False
-
False
-
Undefined
Description
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.
Attachments
Issue Links
- relates to
-
DBZ-2855 Missing log file error when current SCN differs from snapshotted in Oracle connector and Logminer
- Closed