docs: clarify custom destination/store tutorial (#474) #485
Conversation
| Event::Delete(delete) => { | ||
| // Handle delete: delete.old_table_row identifies row to remove | ||
| } | ||
| Event::Commit(_) => { |
There was a problem hiding this comment.
For Begin and Commit messages, it's a bit of a tricky discussion since those are delivered but they can be duplicate since we don't have the rel_ids on those.
We are currently sending them just to make it clear when transactions start and end, but the destination will have to do some lsn checks to make sure that they are not re-processed.
Maybe we should mention this.
There was a problem hiding this comment.
Okay ,I’ll add a note explaining that Begin and Commit events can be duplicated
SumitKumar-17
force-pushed
the
docs/custom-destination-clarity
branch
from
a1aec74 to
4eda055
Compare
| /// | ||
| /// This method handles real-time changes from the Postgres replication stream. | ||
| /// Events include inserts, updates, deletes, and transaction boundaries. The | ||
| /// destination should process events in order, this is required to maintain data consistency. |
There was a problem hiding this comment.
Another detail, the events from write_events can belong to different tables, the consistency must be maintained within events of the same table but events on separate tables can be applied in any order.
SumitKumar-17
force-pushed
the
docs/custom-destination-clarity
branch
from
4eda055 to
b6c4b47
Compare
2 participants
Updated the custom destination tutorial to clearly explain the roles of write_table_rows and write_events, and added examples showing how different Event types are handled.