Should we have a story for database views?

[sgrif]

Do we need one? @derekprior you might have opinions on this. I was just thinking about this, and it might be cool (if we go the DSL migration route) to allow using the query builder DSL for constructing views, and then when the migration is run store the previous version in the schema_migrations table, to get down for free.

[werner]

Hi, what is the status of this? Is there a way to support views? Is this in the roadmap?, thanks.

[mjanda]

@werner You can create your own schema for views manually (and keeping it in sync if you change your views) and it works.

[Razican]

Hi! What are the technical challenges for diesel to automatically add views in the schema as it does with tables?

[weiznich]

@Razican Using table! to represent views is only a crude workaround. Infer the necessary definitions from the database while doing diesel print-schema is probably quite easy, the main challenge here is to design and implement a dsl for views.
The main point here is that views have a different semantics than tables:

• They have no primary keys
• They can support data manipulation queries (like insert/update/delete) or not
• Nullability of their fields is much more complicated as far as I'm aware of

Based on this points I would assume that we would need a separate table! like macro for them + some modification to the existing query dsl (namely for insert/update/delete). Designing and implementing that is something that is currently not on my priority list, but this is definitively something where I would accept contributions. As starting point I would suggest to open a new topic in the discussion part of this repo and collect ideas about how such an API could look like there.

[letto4135]

This has been open for 7 years, and there have been more than a couple other people open issues relating to this, is there any chance this feature is in the near future?

[weiznich]

@letto4135 The comment above remains valid. It's not on my priority list, so I do not plan to work on this in foreseeable future. That written: We accept contributions for this feature. I suggest you open a discussion with some design ideas first, before starting to implement something.
Other than that: Please don't ask for updates on old issue. If there is something new that get's added to the issue, if there is nothing new then asking will not change that fact. Additionally it's always a bit shady to request updates from others on large features without having contributed something to a project. If you really need a feature to be done either try to contribute yourself or try to support others to work on this feature via a sponsor ship.

[Zizico2]

I want to start working on this. But I really don't know where to start. What could we consider a proof of concept? I was thinking a version where we completely disallow insert/update/delete, even in views that some DB (postgres for example) would allow it and consider all columns as nullable, to normalize any nullablebility inconsistencies (since we are only allowing reads, this wouldn't cause any errors on the DB side).

And about the point you made about primary keys: why does Diesel require primary keys on tables in the first place? What would be the technical difficulties of implementing views, without said primary keys?

The features described above would already be useful for a lot of people. From my experience views are mostly used as read only anyway.

[Zizico2]

Started a discussion #3473