I have a transaction in my XTDB database from three months ago that is incorrect and I essentially need to pretend like it never happened. I know the tx-log is immutable and all of that so it seems like I can’t just remove the transaction. What other options do I have?
Hey @enragedginger in extreme cases it is always possible poke at the underlying transaction log manually and perform some surgical change (though it’s definitely easier via JDBC than Rocks/Kafka).
What did the transaction contain? Basic operations, or transaction functions? Do you know for sure whether there was anything else that might be referencing the data from that transaction which might stop the app working?
Ideally you could just logically undo any changes (/ rely on the temporal mechanics to keep things hidden) and then evict anything you really don’t want to see again. Manually editing the log is not something I would recommend in the first instance 
…sometimes it can be necessary though, especially if the contents are somehow corrupted and actively breaking the production app.
Another option is to decant everything to a fresh instance but filter out the offending tx / data.
Thanks for the quick response. In this particular instance, I believe I can just do something like so for each document impacted:
- Search the entity history for the entry from the offending transaction (tx1) as well as the one immediately preceding it (tx0)
- Submit a put transaction for the entity with the document at tx0 but with the valid-time of tx1
It seems like that should correct the issue, no?
Also, I’ve seen “decant” mentioned in a couple of different posts on this forum, but see no references to it in the docs? What does it refer to? Based on context, it seems like I’d be replaying the transaction log, but skip over certain transactions? Is that right? How much of this would I have to build myself and which functions from the XTDB API would I end up using?
1 Like
Submit a put transaction for the entity with the document at tx0 but with the valid-time of tx1
Depending on the exact semantics you need, you may also want to add an end-valid-time parameter to your put ops also, especially if there are later entries in the history that have been affected too.
The strategy sounds about right though 
I’ve seen “decant” mentioned in a couple of different posts on this forum, but see no references to it in the docs
My fault, sorry, the term has been picked up by osmosis from the Datomic community (e.g. here) but it has a fairly casual meaning as far as I’m aware. Probably is something writing up formally somewhere though 
In any case, the description I gave previously (for v1) stands: Shrinking the Database.
Cool. Thank you! In my case, an end-valid-time isn’t necessary (thankfully). I’ll take a look at those decant resources.
1 Like
hey, unless you export/import, do very carefuly think of what tx and valid timestamps to use, in order to shadow the wrong transaction. And make sure no normal user can revisit that wrong time-patch accidentally (the db is bitemporal so one can move anywhere in 2d time “space” - if you let them to)
have fun