3 ms·
all the things i explained about metadata are implemented in postgrest and they work, and there is no loss of flexibility sinceyou can expose any table you want
by ruslan_talpa 10y ago
all the things i explained about metadata are implemented in postgrest and they work, and there is no loss of flexibility sinceyou can expose any table you want from any schema by explicitly creating a "mirror" view in the exposed schema. and relations are detected across tables and views and there is a way to deal with collisions.
I am not saying that your way is bad (having a metadata file), just saying there is a way to automatically create it.
- b,c that's good that you don't expose the entire SQL
- 0x777 10y agoI guess we'll need to have 'auto generate relationships' tooling. Just curious, how do you infer the relationships between a table and a view?
- ruslan_talpa 10y agocan't reply to your question so doing it here. the code is OS so you can look it up :) the idea is this - detect table relations based on FK - for each view check where each column comes from (view column usage) based on the info above you know all the relations in the system, even view to view also there is a way to do it in a single query but that is not yet implemented in postgrest
- 0x777 10y agoWhile we can get the information on the columns used in a view, we can't infer if the uniqueness properties propagate to the view which guarantee the semantics of relationships. I guess it might be convenient to do this (determine relationships across views), but the users should be aware of the guarantees offered in this scenario.
- ruslan_talpa 10y agoI am not sure i understand what you are saying about guarantees. If there is a FK, there is a relation. It's the user that is driving the relations by specifying what columns are FK, it's the same thing as defining relations in a GUI, only you do it at the database level