orbit-db-store- I don't see any use of refs. Any downsides to using refs along with nexts here: https://github.com/orbitdb/orbit-db-store/blob/master/src/Replicator.js#L181
@mistakia I believe that has been an oversight and we didn't add the usage of
refs when we added those to ipfs-log. I've found some problems with that recently and it looks to me we should do a proper refactoring of Replicator (as ipfs-log and Replicator do same/similar things), as well as fix that lack of
refs as it directly effects the replication throughput/performance (quite heavily based on my tests).
@haadcode what's this for? is it redundant? https://github.com/orbitdb/orbit-db-docstore/blob/master/src/DocumentStore.js#L6 I get
'Readable' is assigned a value but never used
@phillmac I have no idea where that comes from or why it's there. sounds like we should remove it?
@haadcode I am just trying to understand OrbitDB and its limits right now. Is it true that the time to load OrbitDB is therefore proportional to the number of changes (inserts/updates/deletes) made to it? Or is there some kind of checkpoint where the whole db is flushed to avoid having to read the entire log to determine the current state?
@chafey there's currently no functionality for "just give me the state of the DB" without reading the log. such state snapshotting would need to be implemented on the store level, prolly specific to each store. in addition, verifying that the state is correct, in multi-user/collaborative/trustless setting, would still prolly require to load the log (at least partially). one possible workaround would be to somehow save the DB state, say as a JSON object to IPFS, add the hash of the state to another log/feed db and upon loading the original db, load the state snapshot first from the db it was saved to. that said, I'm unsure if all that would be supported out of the box.