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
On my current project, we have a following layered structure of table and 2 views:
A) ledger_breakdown_keys - table
B) ledger_billing_entries - view built on top of A
C) ledger_usage_entries - materialized view on top of B
When I need to update the underlying table A, I often have to rebuild B and C but I haven't found an out-of-the-box way of how to rebuild a dependent materialized view in Scenic. So far I am using this migration (see example).
Do you think that abstracting that could be in any way useful to others? Dependent views does not seem to be so uncommin usecase but I may be wrong. I can forge a PR if we agree that would be useful:
class AddMovieDcuIdToLedger < ActiveRecord::Migration[7.0]
def up
rebuild_billing_views_after(4, 3) do
add_column :ledger_breakdown_keys, :movie_dcu_id, :bigint
end
end
def down
rebuild_billing_views_after(3, 2) do
remove_column :ledger_breakdown_keys, :movie_dcu_id, :bigint
end
end
private
def rebuild_billing_views_after(billing_view_version, usage_view_version)
raise 'Missing block' unless block_given?
execute "DROP MATERIALIZED VIEW IF EXISTS ledger_usage_entries CASCADE"
execute "DROP VIEW IF EXISTS ledger_billing_entries CASCADE"
yield
execute "CREATE VIEW ledger_billing_entries AS #{definition('ledger_billing_entries', billing_view_version)}"
execute "CREATE MATERIALIZED VIEW ledger_usage_entries AS #{definition('ledger_usage_entries', usage_view_version)}"
end
def definition(name, version)
Scenic::Definition.new(name, version).to_sql.rstrip.chomp(';')
end
end
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
On my current project, we have a following layered structure of table and 2 views:
A)
ledger_breakdown_keys
- tableB)
ledger_billing_entries
- view built on top of AC)
ledger_usage_entries
- materialized view on top of BWhen I need to update the underlying table A, I often have to rebuild B and C but I haven't found an out-of-the-box way of how to rebuild a dependent materialized view in Scenic. So far I am using this migration (see example).
Do you think that abstracting that could be in any way useful to others? Dependent views does not seem to be so uncommin usecase but I may be wrong. I can forge a PR if we agree that would be useful:
Beta Was this translation helpful? Give feedback.
All reactions