Clojurians Log v2

I might try to implement that soon, but I'll admit most of the terms are new to me / I don't understand how they relate.

Actually I'm not exactly trying to evict. Ideally I can have an operation that takes a txId and toggle it (either retract or reassert based on its current status). I'm trying to implement a multiplayer undo redo mechanism: You make a series of changes and you can undo/redo them. At the same time another user makes a series of changes and they can undo/redo theirs. The two undo/redos shouldn't affect each other unless the data is actually conflicting (for example: I created an entity and you changed it, then I retracted the creation, your edit should drop as well).

can you do it on an entity level? this is much easier than on a transaction level, you can create a dedicated "transaction entity" that has refs to your other data that needs to be retracted and then you can retract also in these places; as a side note, to combine replikativ with datahike i used an OR-map CRDT and every entry in the map was an entity that gets added or retracted depending on the state of the CRDT, this allows you to have multiple concurrent writers on the db and still converge;

Thank you for the pointers! I asked claude to help understand your suggestions concretely. If you skim the code snippets, does this seem to match what you had in mind?

yes, that matches fairly closely; the details will be up to your needs; in the simplest case you can just use an OR-map on a per entity basis, and the conflict resolution will make sure that entities are added or removed atomically, the undo group design looks reasonable to me, but how to map this exactly onto the or-map would need to be thought through

cool; feel free to ask questions or ask for pointers; i hope claude can also answer questions well given the code base, for me the LLMs are pretty good at explaining

if you happen to build a nice prototype example and put it onto github i am very happy to point to it in the replikativ README

also lmk how it goes

one thing that replikativ does not have yet is GC, but konserve has GC support; if you need it we can calculate the reachable set of values for the OR-Map and remove all values that have been removed (while keeping the tombstones in the metadata)

The transaction history is not mutable in this way, i.e. the history index will retain the transactions and be append-only. You can evict though https://github.com/replikativ/datahike/blob/main/doc/time_variance.md#data-purging

What are you exactly trying to do?