Updating the schema to reflect changes in Db-sync

[CodiePP]

recent versions of Db-sync have new tables that need to be included in the BigQuery schema and the update process

• denormalisation of the new tables

[CodiePP]

public.epoch_param has been expanded:

CREATE TABLE IF NOT EXISTS public.epoch_param
(
    id bigint NOT NULL DEFAULT nextval('epoch_param_id_seq'::regclass),
    epoch_no word31type NOT NULL,
    min_fee_a word31type NOT NULL,
    min_fee_b word31type NOT NULL,
    max_block_size word31type NOT NULL,
    max_tx_size word31type NOT NULL,
    max_bh_size word31type NOT NULL,
    key_deposit lovelace NOT NULL,
    pool_deposit lovelace NOT NULL,
    max_epoch word31type NOT NULL,
    optimal_pool_count word31type NOT NULL,
    influence double precision NOT NULL,
    monetary_expand_rate double precision NOT NULL,
    treasury_growth_rate double precision NOT NULL,
    decentralisation double precision NOT NULL,
    protocol_major word31type NOT NULL,
    protocol_minor word31type NOT NULL,
    min_utxo_value lovelace NOT NULL,
    min_pool_cost lovelace NOT NULL,
    nonce hash32type,
    cost_model_id bigint,
    price_mem double precision,
    price_step double precision,
    max_tx_ex_mem word64type,
    max_tx_ex_steps word64type,
    max_block_ex_mem word64type,
    max_block_ex_steps word64type,
    max_val_size word64type,
    collateral_percent word31type,
    max_collateral_inputs word31type,
    block_id bigint NOT NULL,
    extra_entropy hash32type,
    coins_per_utxo_size lovelace,
    pvt_motion_no_confidence double precision,
    pvt_committee_normal double precision,
    pvt_committee_no_confidence double precision,
    pvt_hard_fork_initiation double precision,
    dvt_motion_no_confidence double precision,
    dvt_committee_normal double precision,
    dvt_committee_no_confidence double precision,
    dvt_update_to_constitution double precision,
    dvt_hard_fork_initiation double precision,
    dvt_p_p_network_group double precision,
    dvt_p_p_economic_group double precision,
    dvt_p_p_technical_group double precision,
    dvt_p_p_gov_group double precision,
    dvt_treasury_withdrawal double precision,
    committee_min_size word64type,
    committee_max_term_length word64type,
    gov_action_lifetime word64type,
    gov_action_deposit word64type,
    drep_deposit word64type,
    drep_activity word64type,
    pvtpp_security_group double precision,
    min_fee_ref_script_cost_per_byte double precision,
    CONSTRAINT epoch_param_pkey PRIMARY KEY (id)
)

we could export these data as JSON:

SELECT t.epoch_no, to_json(t) AS params FROM (
  SELECT * FROM public.epoch_param WHERE epoch_no > 510
) AS t;

so no future changes need to be made to the query. (same for table param_proposal). @monoid-is-a-monad ?

[monoid-is-a-monad]

yes that sounds like a good idea!