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
Even though db-sync already supports different insert options, most of them operate on the same db schema. The only case where this is not true is the consumed-tx-out flag, which adds a new field to the tx_out table. Since we want to optionally add a new table Address, which also requires to change the tx_out.address field, we have the following challenges:
An option to add the address feauture should be orthogonal to consumed-tx-out
This forces us to support 4 different combinations, so 4 different schemas
Persistent doesn't provide much flexibility for this. We may want 4 different Schema files which define at least TxOut
I think for this we can follow the same approach as we did for consumed-tx-out: Initially run the .sql file migrations and then run additional migration from Haskell code instead of .sql files. We could keep a flag in ExtraMigrations about whether the address table feauture is enabled and adjust the queries accordingly.
The text was updated successfully, but these errors were encountered:
Even though db-sync already supports different insert options, most of them operate on the same db schema. The only case where this is not true is the
consumed-tx-out
flag, which adds a new field to thetx_out
table. Since we want to optionally add a new tableAddress
, which also requires to change thetx_out.address
field, we have the following challenges:consumed-tx-out
TxOut
I think for this we can follow the same approach as we did for
consumed-tx-out
: Initially run the.sql
file migrations and then run additional migration from Haskell code instead of.sql
files. We could keep a flag inExtraMigrations
about whether the address table feauture is enabled and adjust the queries accordingly.The text was updated successfully, but these errors were encountered: