A redeemer can have 6 types: spend, mint, cert, reward, vote, propose, which is depicted in the redeemer.purpose field. This field with the redeemer.tx_id and redeemer.index, identifies uniquely a redeemer and it's relation to another table
spend -> tx_in
mint -> ma_tx_mint
cert -> delegation or stake_deregistration
reward -> withdrawal
vote -> delegation_vote
propose -> gov_action_proposal
In addition to that, the schema also provides the reverse relations
tx_in.redeemer_idstake_deregistration.redeemer_iddelegation_redeemer_id
(ma_tx_mint doesn't have a redeemer_id reference)
withdrawal_redeemer_iddelegation_vote.redeemer_id
(gov_action_proposal doesn't have a redeemer_id reference)
The motivation of these were to make it easier to identify which entries have an attached redeemer, but they are duplicate data. Other than that, they complicate parallelising the workload of db-sync since they create dependencies within the insertion of a block.
A redeemer can have 6 types:
spend,mint,cert,reward,vote,propose, which is depicted in theredeemer.purposefield. This field with theredeemer.tx_idandredeemer.index, identifies uniquely a redeemer and it's relation to another table spend -> tx_in mint -> ma_tx_mint cert -> delegation or stake_deregistration reward -> withdrawal vote -> delegation_vote propose -> gov_action_proposalIn addition to that, the schema also provides the reverse relations
tx_in.redeemer_idstake_deregistration.redeemer_iddelegation_redeemer_id(ma_tx_mint doesn't have a redeemer_id reference)withdrawal_redeemer_iddelegation_vote.redeemer_id(gov_action_proposal doesn't have a redeemer_id reference)The motivation of these were to make it easier to identify which entries have an attached redeemer, but they are duplicate data. Other than that, they complicate parallelising the workload of db-sync since they create dependencies within the insertion of a block.