You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the utxo table has columns for storing the transaction ID, and the mined block height. These are almost always duplicative of entries in the transaction table, and having them stored separately inhibits other possible relational queries.
We should implement a migration to:
Add a tx foreign key column.
Migrate existing utxo entries to reference matching transactions entries.
For those utxo entries that do not have matches, fetch the corresponding transactions from lightwalletd to populate the remaining transactions entries that the wallet assumes are populated during scanning.
The division of this work between the database migration and the network fetching might affect internals, but at a high level the migration API provided to zcash_client_sqlite users should hopefully be straightforward in the instructions it gives them.
The text was updated successfully, but these errors were encountered:
We discovered that is more challenging than we thought, because if we set the block height of the transactions entry, this requires an entry in the blocks table and we'd need at least the block hash to create such an entry; in addition, we now have the property "every entry in the blocks table corresponds to a block that we have scanned" so supporting this database refactoring will likely require other kinds of changes.
Currently the
utxo
table has columns for storing the transaction ID, and the mined block height. These are almost always duplicative of entries in thetransaction
table, and having them stored separately inhibits other possible relational queries.We should implement a migration to:
tx
foreign key column.utxo
entries to reference matchingtransactions
entries.utxo
entries that do not have matches, fetch the corresponding transactions fromlightwalletd
to populate the remainingtransactions
entries that the wallet assumes are populated during scanning.The division of this work between the database migration and the network fetching might affect internals, but at a high level the migration API provided to
zcash_client_sqlite
users should hopefully be straightforward in the instructions it gives them.The text was updated successfully, but these errors were encountered: