@Emyrk I know we had the thread discussing this, but what's the long-term vision here? If we continue compounding views, nobody will ever adjust the schema. It'll be an insane amount of effort for a trivial change.

@kylecarbs This is the last 2 views to make Users a privileged endpoint. If we end up sharing workspaces, then that might require it too. This is where the buck stops because the Users resource is not related to the ones I am joining from a permission point of view.

We got away with not needing joins for other relations because the permissions are the same. Eg reading a workspace build == reading a workspace. So we just do the extra db calls in the dbauthz layer.

If more joins are required, then we need to find a more general solution. However, a general solution is going to require a significant amount of work (heavy lifting likely done in design). Implementing a general solution today to solve this is overkill and likely not to gain much support until it is absolutely needed.

When the general solution is required, it should not affect this code much if at all.

I suppose I'm confused, because that assumes we're making a general solution, but there's no plan for that.

Right now if I want to modify workspace_builds or templates I believe the entire view has to be recreated? Which doesn't seem like a great pattern we want to adopt long-term.

I understand I'm here without great ideas to improve it - it just seems bad to make things harder without an eventual plan to make them easier.

Yes you do have to recreate the view.

There's a unit test that is run on make gen to at least advise the developer of this requirement.

From talking with Cian, scale tests currently hammer the DB. We likely should solve this as we want to hit larger scales. But at present we just rely on vertically scaling the hosts.

This should be solved imo, but I felt that way awhile ago so I can't really speak to when we'll be "forced" to actually do it.

I did debate making some sort of autogen solution that automatically re creates the view.

The reason of doing this is to keep our permissions consistent.

Another option would be to use the SystemContext to fetch this data. That just comes with the downside that we're bypassing the dbauthz's purpose.

Using the SystemContext to fetch data we return from the API is not a pattern I wanted to introduce.

I think we could get a lot of value from forking sqlc here to come up with a solution.

Using a PG view is a nice way to package up a view of a joined set of tables. The downside is just managing the migrations.

Views in PG are not physically materialized. So there is no reason why we could not write the views as a sqlc query and then build them dynamically in the generator.

I started an issue on sqlc to see what the author thinks:
sqlc-dev/sqlc#2491

@kylecarbs

Forking SQLc would allow us to do it ourselves. We could also implement other features we specifically wanted:
Emyrk/sqlc#1

Obviously we would have to find a way to keep it up to date with the official SQLc.

I was looking at the plugin gen code, and unfortunately no AST information is sent to the plugins. So this might require implementation in the core of SQLc.