Delegated Types in Rails, handling models with overlapping attributes
blackboxengineering.work
Delegated Types in Rails, handling models with overlapping attributes
1–4 of 4 posts
Re: Delegated Types in Rails, handling models with overlapping attributes
#2Whoa, cool feature I hadn't heard about. Good to know!
Another approach to this problem I've used in the past is Postgres views, which basically let you create a third table that's either materialized (constructed in advance) or generated on the fly and has columns based on transforms of the first two tables. So in this case you could create a Post model backed by a view table that pulls in the names and other metadata it needs from the text and video tables and merges them into columns that function as a third table in the eyes of the Post model. But there's no actual duplication / denormalization happening, which keeps things clean..
Re: Delegated Types in Rails, handling models with overlapping attributes
#3Whoa, cool feature I hadn't heard about. Good to know! Another approach to this problem I've used in the past is Postgres views, which basically let you create a third table that's either materialized (constructed in advance) or generated on the fly and has columns based on transforms of the first two tables. So in this case you could create a Post model backed by a view table that pulls in the names and other metada…
That is an interesting approach. Our of curiosity, how is an engineer made aware of the psql view? For example, the view likely relies on specific columns in specific models. What guard rails are available for preventing this kind of breaking change with the view approach?
Re: Delegated Types in Rails, handling models with overlapping attributes
#4Whoa, cool feature I hadn't heard about. Good to know! Another approach to this problem I've used in the past is Postgres views, which basically let you create a third table that's either materialized (constructed in advance) or generated on the fly and has columns based on transforms of the first two tables. So in this case you could create a Post model backed by a view table that pulls in the names and other metada…
That is an interesting approach. Our of curiosity, how is an engineer made aware of the psql view? For example, the view likely relies on specific columns in specific models. What guard rails are available for preventing this kind of breaking change with the view approach?
specs--it's basically the same question as with changing the structure of any db table. How do you know some code doesn't rely on it?
We also use/love this gem https://github.com/scenic-views/scenic to version our views