# Change data capture

**URL:** <https://forums.foundationdb.org/t/change-data-capture/1259>\
**Category:** Using FoundationDB\
**Created:** [March 25, 2019, 7:00pm UTC](https://forums.foundationdb.org/t/change-data-capture/1259 "2019-03-25T19:00:14Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![nitins64](https://avatars.discourse-cdn.com/v4/letter/n/7993a0/32.png) [@nitins64](https://forums.foundationdb.org/u/nitins64)\
**Post date:** [March 25, 2019, 7:00pm UTC](https://forums.foundationdb.org/t/change-data-capture/1259/1 "2019-03-25T19:00:14Z")

</div>

Hi there,

I am new to FoundationDB. We are evaluating foundionDb as our core transactional store.  
And then using change log to build near-realtime read optimized view of our data. I am sure this topic is covered somewhere but i couldn’t find documentation on recommended way to capture the mutations.

Could someone point me to relevant documentation?

Thanks!

---

<div class="post-metadata">

**Author:** ![ryanworl](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/ryanworl/32/440_2.png) [@ryanworl](https://forums.foundationdb.org/u/ryanworl)\
**Post date:** [March 25, 2019, 7:44pm UTC](https://forums.foundationdb.org/t/change-data-capture/1259/2 "2019-03-25T19:44:34Z")

</div>

You can build that into your layer yourself. The basic idea is you perform whatever operations within your transactions you’d like, but also store the before and after values of each logical entity and write them out into a log structure using set\_versionedstamped\_key.

---

<div class="post-metadata">

**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\
**Post date:** [March 25, 2019, 8:45pm UTC](https://forums.foundationdb.org/t/change-data-capture/1259/3 "2019-03-25T20:45:06Z")

</div>

@alloc gave a talk on building an efficient index for clients to sync changes to data in [Avoiding Conflicts in Highly-Concurrent Applications](https://www.youtube.com/watch?v=2HiIgbxtx0c), which might be interesting for you?

---

<div class="post-metadata">

**Author:** ![nitins64](https://avatars.discourse-cdn.com/v4/letter/n/7993a0/32.png) [@nitins64](https://forums.foundationdb.org/u/nitins64)\
**Post date:** [March 26, 2019, 3:47pm UTC](https://forums.foundationdb.org/t/change-data-capture/1259/4 "2019-03-26T15:47:36Z")

</div>

thanks a lot ryanworl!!

Any reference implementation for adding capabilities to layer?

---

<div class="post-metadata">

**Author:** ![ryanworl](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/ryanworl/32/440_2.png) [@ryanworl](https://forums.foundationdb.org/u/ryanworl)\
**Post date:** [March 26, 2019, 3:51pm UTC](https://forums.foundationdb.org/t/change-data-capture/1259/5 "2019-03-26T15:51:40Z")

</div>

I think the record layer has the ability to do this. Here is the relevant core of the code:

> <https://github.com/FoundationDB/fdb-record-layer/blob/master/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/provider/foundationdb/indexes/VersionIndexMaintainer.java>

But this is a part of a much larger and more complicated system, so it may not be the best example. Other than this I don’t know of anything publicly available.

---

<div class="post-metadata">

**Author:** ![alloc](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alloc/32/9_2.png) [@alloc](https://forums.foundationdb.org/u/alloc)\
**Post date:** [March 26, 2019, 6:34pm UTC](https://forums.foundationdb.org/t/change-data-capture/1259/6 "2019-03-26T18:34:07Z")

</div>

We also have docs on how to use the version index: [https://foundationdb.github.io/fdb-record-layer/Overview.html#indexing-by-version](https://foundationdb.github.io/fdb-record-layer/Overview.html#indexing-by-version)

One perhaps non-obvious thing about the semantics of this index is that if a record is updated multiple times, only its most recent update will be included in the version index. This is fine for some applications (like sync–except that you also need to include tombstones to sync deletes), but not others.

It _sounds_ like the index included in the record layer would work for you, but it depends.