Is there an easy way to get the historical state of a map, tree, text, etc. structure inside a loroDoc?

[zxhd863943427]

我正在尝试基于sqlite实现一个带crdt同步功能的数据库，我希望能使用loro，假如能单独回溯一个record的历史会很有帮助，但我发现目前似乎只能使用loroDoc的整体回溯。我想知道是否有单独回溯一个子结构如map, tree, text的方法。如果没有，我该进行什么努力以增加它。

I'm trying to implement a database with crdt synchronization based on sqlite, and I'd like to use loro, it would be helpful to be able to backtrack a record separately, but I've found that at the moment it seems like to only be able to use loroDoc as a whole. I wonder if there is a way to backtrack a substructure like map, tree, text separately. If not, what can I do to increase it.

[zxch3n]

It's not supported at the moment. However, you can fork the doc and use doc.checkout() on the new doc. Though it's much slower than the best solution, it may still be fast enough for your use case. You/we can implement the dedicated optimal solution when it's really needed.

[zxhd863943427]

那这样主要的问题是似乎没有足够方便的方法获取counter变动过的Frontiers，目前的对外接口里看上去只有with_oplog有这个可能了。我先进行下尝试，看看在我的测试样例中是否足够快。

The main issue here seems to be the lack of a convenient way to access the Frontiers that have been changed in the counter. It appears that the only possibility for this is with_oplog in the current external interface. I will first attempt to see if it is fast enough in my test case.

另外我想先问一下，在有百万级记录的loroDoc里，fork并checkout会产生两倍的内存占用吗？

I would like to ask, in the loroDoc with millions of records, does forking and checking out double the memory usage?

[zxhd863943427]

因为看上去loro进行操作主要还是使用内存进行的，100w条、10属性级别的sqlite数据库已经有3g的大小了，假如内存占用翻倍那会导致这种操作看上去在普通设备上并不实际，甚至可能超出wasm支持的范围。

Because it seems that loro mainly operates using memory, a SQLite database with 1 million rows and 10 attributes has already reached a size of 3GB. If the memory usage doubles, this operation may appear impractical on regular devices and could even exceed the range supported by WebAssembly.

[zxch3n]

Ah, sorry, Loro is not designed for syncing an entire database with millions of records in a single LoroDoc. I thought you stored each document inside a LoroDoc and put one LoroDoc in a row of SQLite, which is more feasible.