# Transaction Log **URL:** \ **Category:** Using FoundationDB\ **Created:** [October 19, 2018, 9:53am UTC](https://forums.foundationdb.org/t/transaction-log/785 "2018-10-19T09:53:24Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![dave](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/dave/32/89_2.png) [@dave](https://forums.foundationdb.org/u/dave)\ **Post date:** [October 19, 2018, 9:27pm UTC](https://forums.foundationdb.org/t/transaction-log/785/3 "2018-10-19T21:27:17Z")
Actually, FoundationDB _does_ have a mechanism to automatically log all mutations to a range of keys, used to implement the backup and DR tools. However it is generally not recommended for applications to use it for change monitoring, since new versions of FoundationDB will generally change the format, so such applications won’t enjoy FoundationDB’s otherwise excellent backward API compatibility. I and others discussed some similar questions about applications interested in history in this thread: > [@Changefeeds (watching and getting updates on ranges of keys)](https://forums.foundationdb.org/t/changefeeds-watching-and-getting-updates-on-ranges-of-keys/511/5): > > I’m afraid that this thread, like the previous one about watches, might leave the reader with an impression that they are a lot harder to use correctly than (I think) they actually are. The basic idea of a watch is that you have something that you could monitor with a polling loop: @fdb.transactional def get\_light\_switch\_state(tr): return tr["light\_switch"] == "on" while True: state = get\_light\_switch\_state(db) set\_lamp\_state( state ) time.sleep(1) But this will either be slow… --- _[View the full topic](https://forums.foundationdb.org/t/transaction-log/785)._