Oninit® Log Ripper — A Pluggable, Embeddable CDC Engine for Informix

Most CDC platforms expect you to bend your architecture around them — a managed service, a proprietary message bus, a heavyweight agent. Log Ripper is designed to drop into the architecture you already have.

Two delivery shapes, one engine

The same capture core ships as the standalone oni_ripper daemon and as a shared library, liboni_ripper.so, with a public C API. The daemon mode handles the standard "run it next to Informix and ship changes somewhere" pattern. The library mode lets you embed the same pipeline inside a long-running host application — a Java service via JNI, a Python pipeline, another C daemon — and receive captured changes synchronously through a per-transaction callback. No signal handlers installed, no hidden threads outside the engine, you stay in control of the process.

Output abstraction

A single capture path feeds multiple sinks: SQL files for replay-style integration, RFC 8259 JSON or RFC 4180 CSV for streaming and ETL, native PostgreSQL / MySQL / MariaDB / Db2 connectors via dlopen against the vendor client libraries, ODBC for any other target, and Kafka via librdkafka for event-driven architectures. You pick the integration pattern that fits the consumer; the source side doesn't change.

Cross-dialect SQL rewriter

Captured Informix-flavoured SQL is rewritten per target dialect at output time — INTERVAL syntax, BOOLEAN literals, DATETIME format, DECIMAL precision wrap, embedded NUL splice, BLOB hex form, identifier quoting, MDY / TODAY built-ins. The per-dialect rewrite forms are listed on the SQL Mapping page. New target dialects plug in as additional formatter functions; the walker generalises across them.

Operational primitives that match production reality

Per-table threading bounds blast radius — one slow target doesn't stall the rest. LSN checkpointing into a state file means recovery is deterministic. Schema drift is detected at three layers, with archive-layout swap available on drift events and synthetic ALTER TABLE emission so the migration replays at the target. A single table can be released for online ALTER without touching the rest of the pipeline. Lag is observable via the [LSN] log line; DISCARD events are exposed through a configurable shell hook so they can flow into whatever observability stack you already run. Target-offline buffering keeps captures flowing through brief destination outages.

No lock-in

Output is open formats (SQL, JSON, CSV) or open protocols (libpq, libmysqlclient, libmariadb, libdb2, ODBC, Kafka). The library exposes a documented C API. Configuration is file-based with a SIGHUP reload contract. RPM and DEB packaging integrates with standard Linux deployment tooling — systemd unit, sysusers, tmpfiles, EnvironmentFile — so it fits any reasonable platform standard without bespoke runbooks.

Where it fits in a target architecture

• Real-time outbound replication from a legacy Informix system of record to a modern data platform.
• Strangler-pattern migrations off Informix without freezing writes on the old system.
• Event-sourcing on top of an existing transactional Informix workload, no application rewrite required.
• Audit and compliance feeds that need durable, ordered, low-latency change records.

If you're designing the path off, around, or alongside an Informix database, Log Ripper is the component that turns the logical log into a first-class data source.

Next

The Embed Ripper / Library Overview covers the C API surface; the SQL Mapping page lists the per-target rewrite forms.