diesel icon indicating copy to clipboard operation
diesel copied to clipboard

Should we have a story for database views?

Open sgrif opened this issue 8 years ago • 10 comments

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.

sgrif avatar Dec 02 '15 23:12 sgrif

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

werner avatar Sep 06 '18 13:09 werner

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

mjanda avatar Sep 08 '18 06:09 mjanda

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

Razican avatar Jan 23 '21 22:01 Razican

@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.

weiznich avatar Jan 25 '21 09:01 weiznich

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?

letto4135 avatar Jan 25 '22 14:01 letto4135

@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.

weiznich avatar Jan 25 '22 15:01 weiznich

@weiznich That's all well and good, but asking if something is being worked on before running off and doing it yourself, or before opening a discussion assuming it is not being worked on, is a good first step in starting the work. Dead issues don't get work, people assume they're going nowhere or there isn't enough interest for it to be a useful addition. Unfortunately I suck at Rust as I've only just started with it otherwise I'd be more than happy to work on it. Maybe soon.

letto4135 avatar Jan 26 '22 01:01 letto4135

@letto4135 I've marked your comment as off topic, as this is obviously not the right place to discuss such stuff. To state that clearly: I warn people one time about commenting on old issues, without bringing in new information and after that such comments are considered off topic and will not get any reaction.

weiznich avatar Jan 26 '22 11:01 weiznich

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 avatar Jan 12 '23 18:01 Zizico2

Started a discussion https://github.com/diesel-rs/diesel/discussions/3473

Zizico2 avatar Jan 12 '23 22:01 Zizico2