gov_action_proposal.description in a machine readable-way
mmahut opened this issue · comments
Right now, the gov_action_proposal.description is stored as a TEXT type such as:
{"contents":[null,[],{"keyHash-3f5896f3cb42f61f76f819b37da4c84dd42c6c4e26bc70786b65e20f":260,"keyHash-631a7084815f9c43fe5f028e6ce18063eb3665c4ce3488f017087de4":260},0.6666666666666666666],"tag":"UpdateCommittee"}
or
{"contents":[[[{"credential":{"keyHash":"248f556b733c3ef24899ae0609d3796198d5470192304c4894dd85cb"},"network":"Testnet"},5000000]],null],"tag":"TreasuryWithdrawals"}
To have more flexibility, can we have this parsed either into separate tables (ideal for indexing) or at least as jsonb? There is no way to for example reconstruct the current committee directly in SQL (where you need to back in history and replay the updates to end up with the current state).
I though description was already jsonb, we will change this.
Actually it's even possible for users to alter it in the existing tags, even though it's a bit hacky:
stop db-sync
run the following command
alter table gov_action_proposal alter column description type jsonb USING description::jsonb;
restart db-sync
About separate tables, we already have some, for treasury withdrawals and committee. Their readability could be improved as well.
About reconstructing the history from these tables, gov_action_proposal.enacted_epoch could be useful. Not sure if you already use it.
Hey! Thanks for the tip, that's certainly useful. However, if we were to replay/reconstruct each committee by querying JSON, it would still troublesome. It would be great if we would have something similar to delegation but for the committee so that we could also query the history (who was part of which committee and when), not just the current state. I would be extremely grateful for having the data in additional tables!
Note that there is a already a table new_committee, however it has fields deleted_member and added_members as they come from the proposal. DBSync could resolve this diff and find the final proposed members so that users don't have to do complicated queries. Now in terms of the representation of the members I can see 2 options:
The first one is to simply have a new_committee.members field, which has a list of hashes, possibly in a text format.
The second is the canonical solution. We can introduce a new committee_member_hash table, similar to stake_address and drep_hash. A number of other fields can reference this table like committe_(de_)registrations.cold_key, voting_procedure.committee_voter. The new_committee table then can be replaced by new_committee_member which will have a 1-n relation with gov_action_proposal and 1-1 relation with committee_member_hash.
A new table may also resolve #1571, but this is a bit orthogonal: a new table could simply be used for hot keys.