make <<uncle-block rolling back>> strategy optional in v6
following #61 (closed)
In v5.1.0 and v4.0.4, the strategy to address rejected blocks (aka uncle blocks) is to delete all information posterior to the oldest detected uncle block, and reindex from there.
In v6, the SQL schema changes significantly (hence the major version bump) to address the issue of those uncle blocks. The same strategy as v5.1.0 and v4.0.4 was merged right before it was released. However in v6 the changes in the SQL schema make it non-mandatory to rollback.
That's not very good for real-time needs, even though reindexing deleted parts should be quite fast.
Therefore, the rolling back strategy should be made optional in future versions.
Edited by Philippe Wang