Allow required indexes to be specified using IndexStore settings #458
Conversation
…Cache where the base classes use IBlockRepository and IBlockStoreCache.
| this.session.Transaction.Insert<string, string>("Common", index.Table, index.ToString()); | ||
| this.session.Transaction.Commit(); | ||
| var transactions = new List<(Transaction, Block)>(); | ||
| foreach (var row in transaction.SelectForward<byte[], Block>("Block")) |
There was a problem hiding this comment.
Ah you have to reindex the entire store, this might be a very long operation no?
There was a problem hiding this comment.
It can be a very long operation on the first run, for a new index, unless the block table is empty at the time... On subsequent runs the index will already exist and will keep pace with changes. Nevertheless it may be possible to improve on this despite the single-threaded requirements. Such an approach would involve building the new index in the background and only committing it once it had been fully built.
There was a problem hiding this comment.
The above "improvement" must be weighed against the fact that we don't really want to start the "block explorer" node, including the block explorer, before all indexes are aligned with the tip... Also, given a hypothetical StratisExplorerD with fixed indexes via feature options, this situation can only arise during development anyway OR if the index folder is deleted without also deleting the blocks folder.
There was a problem hiding this comment.
That's fine its a long operation there is no escaping that we just need to make sure the node is displaying progress some how.
| { | ||
| FullNode node; | ||
|
|
||
| if (options != null && options.Contains("IndexStore")) | ||
| if (callback != null) |
…a-thumbprints Private data allowing individual thumbprints
This allows the IndexStore indexes to be configured using the feature options mechanism.
See PR #329