Allow selecting from views

[am0d]

I've noticed that Diesel can't infer_schema for views. I'd like to see something very similar generated for views as for tables, without (at least at this time) support for updating / inserting rows. But I believe copying all the SELECT / Queryable support from tables would provide the support that is needed for now (at least in my use case).
I could be interested in working on this myself, if someone could provide me with some pointers on where to start.

[killercup]

You can create the table DSL for views by calling the table! macro yourself. Does this solve your problem?

[am0d]

Sorry for the slow response. It seems calling the macro myself does solve the problem a little, although I would definitely prefer to have the view inferred for me to ensure at compile time that it matches the definition in the database.

[pfernie]

I was looking at this sort of functionality today as well (using postgres). The quick-and-dirty approach of hacking diesel_infer_schema to include table_type='VIEW' when reading information_schema.tables is insufficient, as views fail to satisfy some requirements of diesel for tables, notably having a PK. The following questions/issues are what came to mind; posting them here to get a feel for what roadmap/plan exists for supporting (read-only) views, if any:

1. Views (at least in PG) do not support constraints (namely primary keys), which diesel requires for tables.
2. Presumably, it should not be possible to, e.g., #[derive(Insertable)] on views or allow views to be involved in mutating operations.
3. As such, view metadata/schemas, etc., while largely similar to tables in terms of schema parsing/generation & usage for selects, should probably be distinct in w.r.t. types (diesel_infer_schema::view_data::ViewData, trait View, etc.).
4. However, I am unsure how items 1 & 3 would play with the type machinery w.r.t. join semantics, etc. A superficial look suggests "not well", as Table and PrimaryKey are referenced much in those APIs.
5. "nullability tracking" is not well developed in PG, meaning that inferred schemas will most likely be populated with Option fields even if the source table columns are not actually nullable.

It seems introducing inferred views could not be quickly/easily integrated; it would perhaps require the introduction of some trait or abstraction (Identifiable, Joinable?). Would it be worthwhile to implement "basic inferred" views that can be selected but not involved in the join API? Or does support for this warrant more thought?

[sgrif]

I'm not sure there's much else that's going to happen on this in the near future. infer_schema! and diesel print-schema should be excluding views (if that's not the case, please open an issue). Creating a table! declaration for a view is fully supported. table! requires a primary key, but you can safely just pick any column and call that your "primary key"