"pluggable" data structure/object/interface/abstraction for DAG/unit (especially re: SQL/storage) about ocore

[Pascal-J]

One big benefit of this approach is that an SQL database is overkill for an append-only data structure. Decoupling would allow a change in backend. Lengthy syncing time is likely related to SQL inserts/appends of one transaction at a time.

[thedavidmeister]

@Pascal-J check out #42 for a discussion on validation (and hence sync times), specifically re: avoiding multiple serial round trips through SQL for every single unit being validated/synced :)

[maxmetagravity]

good advise， the SQL way is a fast implementation， "pluggable" backend will
force abstract the logic from the SQL ， it make it better scaleable， but this is a big job ：）， Hope do it earler

[thedavidmeister]

@iamliqiang a big job indeed, i think the current approach is to get more unit tests in place for existing functionality, then see what can be proposed

[tarmo888]

Obyte database is not strictly with "append-only" structure. It kind of is append-only if you take account only everything that is stable already, but all the data that is not stable gets updated a lot to figure out the next stability point.

Data feeds are append only, but Autonomous Agent state is not. Both of these are now moved to RocksDB because it makes more sense for key/value data.

Address definitions are not strictly append-only either, these are appended to separate table when they become public (when it is spent from them). Address definitions can be changed to different public key too.

Obyte full nodes have state and history of UTXOs (outputs table), which get updated with the is_spent=1 when they are spent. Archival nodes would be more strictly "append-only", but Obyte full nodes are not archival nodes because they have current state, not all history states.