-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Refactor storage using triggers #174
Conversation
Codecov Report
@@ Coverage Diff @@
## main #174 +/- ##
===========================================
- Coverage 73.21% 60.37% -12.84%
===========================================
Files 83 81 -2
Lines 3338 3541 +203
===========================================
- Hits 2444 2138 -306
- Misses 713 1212 +499
- Partials 181 191 +10
Continue to review full report at Codecov.
|
Todo
|
sqlstorage.DB represents the entire set of ledgers. sqlstorage.Schema represents a specific ledger. In case of postgresql, sqlstorage.DB implement is a simple wrapper around *sql.DB struct, and Schema is a PostgresQL schema. In case of sqlite, sqlstorage.DB is the directory holdings all the underlygin db files, and the Schema is the concrete *sql.DB.
We already have an abstraction over storage.Driver. No need to have twice.
Add following tables : * log * account * volumes * balances Now, we only write on the "log" table. There is a set of triggers which are in charge of filling tables when a write is make on "log" table. Thus, the hash is now on logs instead of transactions. This way the hash take in account, metadata applied to transactions or accounts. The automatic migration fill this log table with the existing data. Since, the new code use some json function, the code must be compiled with "json1" build tag to enable support on sqlite.
Add following tables : * log * account * volumes * balances Now, we only write on the "log" table. There is a set of triggers which are in charge of filling tables when a write is make on "log" table. Thus, the hash is now on logs instead of transactions. This way the hash take in account, metadata applied to transactions or accounts. The automatic migration fill this log table with the existing data. Since, the new code use some json function, the code must be compiled with "json1" build tag to enable support on sqlite.
cf2a5f0
to
bb94821
Compare
425238d
to
c169c2e
Compare
15b695f
to
bc39b2e
Compare
Replace #168 Refactor storage.
This PR add triggers on "transactions" table to automatically compute balances and volumes of accounts in "balances" and "volumes" tables.
It also create entries in a new table called "accounts". This table will replace "addresses" table.
Now, transaction postings are directly persist as json in the transactions table, as well as metadata.
Account metadata are persisted in "accounts" table, also with json type.
Previously, the GET /accounts was not retrieving accounts which was not part of a transaction.
The new table "accounts" fix defacto this issue.
Also, there is another new table, called "log" which is designed to model an event based store. The code now always write to this table, then a set of triggers generates
entries in the transaction table, or updates metadata of either accounts or transactions following the log "type" column.
The hash on transactions was removed and add on "log" table. As a result we have a complete hash chain taking in account, metadata set on transactions or accounts.
To complete the modification on hash, the "id" property of transactions has been changed from id to a string, and is set to be a uuid by the code.
Old transactions will not have a uuid , just a int to string convert is done by the migration, but since the id is an opaque string, it should not cause any problem. A column named "ord" has been added to keep transactions ordering without the need to read all logs. It is generate by triggers, and not by the code.