New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RevEng: Support Views #1679

Open
lajones opened this Issue Feb 20, 2015 · 32 comments

Comments

@lajones
Member

lajones commented Feb 20, 2015

Note: This issue is tracking a specific aspect of using EF Core with database views. See #827 for an overview of the areas where EF Core interacts with database views. The completion of this feature does not mean that every aspect of database view support has been implemented.


See also #5719, which is about support for tables without keys.

Part of #830. At the moment we generate code only from tables, not views. Need to include views but may have to consider what we want to use as the primary key.

@roji

This comment has been minimized.

Contributor

roji commented May 27, 2016

Just a note for whenever this gets tackled - PostgreSQL views are updatable in some cases, see the docs for when this is valid. I'm not sure if this kind of thing is supported in other databases, just want to make sure views in EFCore aren't approached as necessarily read-only entities.

@garethsuarez

This comment has been minimized.

garethsuarez commented Jul 10, 2017

any chance that view mapping (which would also require stored proc mapping for insert/update/delete) could be a 2.x feature, or are we likely to have to wait for a 3.0 release?

@divega

This comment has been minimized.

Member

divega commented Jul 11, 2017

@garethsuarez the straightforward answer is that we don't know yet. We haven't even completed the planning for the next version after 2.0. We will take into account votes as well our best effort to understand the usefulness and the cost of each feature.

@tdjastrzebski

This comment has been minimized.

tdjastrzebski commented Sep 19, 2017

Views can be updatable but the framework will never be able to 100% correctly guess the pk.
Hence, it may make more sense to generate (scaffold) views as regular entities; read-only until pk is defined. Does not it sound like a reasonable deal? Why a separate ViewType? Just to indicate it is read-only while with PK added it may not be? Keep it simple. Not to mention that sql server views (tables too) really do not require pk to be updatable but ok, it is not a good practice.

@roji

This comment has been minimized.

Contributor

roji commented Sep 21, 2017

@tdjastrzebski the framework may not need to "guess" the PK - this information might be available in from the database itself, at least in some cases. I admit I'm not sure exactly what is possible and what PK information is exposed by PostgreSQL, but it's important to keep an open mind here with regards to what different databases support (rather than limiting things upfront).

When the times comes to spec this feature out I'd be happy to investigate PostgreSQL capabilities more.

@tdjastrzebski

This comment has been minimized.

tdjastrzebski commented Sep 21, 2017

@roji I absolutely agree and that was my point. The framework, depending on the provider, may or may not be able to guess the PK. Even more, in some cases (providers) the difference between a view and a table may be blurry or simply table/view concept may not exist at all.

Therefore, I strongly advocate for implementing no special treatment for views.

It is an Entity Framework, not just (some) SQL Entity framework. Why not to simply retrieve views like tables but as read-only with no PK, until PK is manually defined.
In my developer life I have came across several data access frameworks, most of them overly complicated with that respect. Keep it simple please.

@ErikEJ

This comment has been minimized.

Contributor

ErikEJ commented Sep 21, 2017

@tdjastrzebski
no special treatment for views != Why not to simply retrieve views like tables but read-only with no PK, until PK is manually defined.

@roji

This comment has been minimized.

Contributor

roji commented Sep 21, 2017

I must say I tend to agree that technically the table/view distinction isn't necessary interesting or important. However, we should keep in mind that views are a standard relational database concept, so for users to understand and quickly use EF Core we should probably retain the terminology.

In other words, documentation and possibly some API sugar should probably contain "view", even if behind the scene it's just a table without a primary key (and which is therefore also read-only).

@tdjastrzebski

This comment has been minimized.

tdjastrzebski commented Sep 21, 2017

@roji Again, I could not agree more. Documentation should use commonly understood terms.
However, I would be careful not to (over) design EF Core mainly towards (some) SQL server in mind.
Even for MS SQL Server views supporting "instead of" triggers the table/view distinction from practical perspective does not make much sense.

@ErikEJ: I am unclear about what you mean by this predicate. In my opinion views support could be simply enabled with "as-is" 2.0 functionality. Albeit I must admit, I have not followed EF Core development closely and I am not aware of all the constraints/dependencies so I could be wrong.
What I know, however, is that by 'fooling' EF Core to generate entities for my views (see #9854 for details) I get just what I need.

@tdjastrzebski

This comment has been minimized.

tdjastrzebski commented Sep 21, 2017

And just a thought: if you really need to distinguish tables and views do so using marker interface only - the harmless way.

@bricelam

This comment has been minimized.

Member

bricelam commented Sep 25, 2017

@tdjastrzebski ViewType is just a fancy word we've been using to describe read-only entity types without a key. At the API level, they'll probably end up looking just like any other entity type.

@bricelam

This comment has been minimized.

Member

bricelam commented Sep 25, 2017

I imagine RevEng will generate a normal entity type with an additional configuration like .IsReadOnly() and no .HasKey() call.

@tdjastrzebski

This comment has been minimized.

tdjastrzebski commented Sep 25, 2017

@bricelam Thank you for the explanation. I think ReadOnlyDbSet<T> may be another option.

@bricelam

This comment has been minimized.

Member

bricelam commented Sep 25, 2017

Oh I like that--it could hide .Add() and .Remove(). I'm sure @divega and @anpete have also considered it, but I'll cc them just in case.

@anpete

This comment has been minimized.

anpete commented Sep 25, 2017

Yep, working name is DbView<T> 😄

@roji

This comment has been minimized.

Contributor

roji commented Jun 20, 2018

Add providers-fyi? I occasionally search for stuff I need to react it with providers-fyi and provider-beware, so it's useful to have them on any issues which may require provider attention.

@irowbin

This comment has been minimized.

irowbin commented Jul 29, 2018

@ajcvickers Is there any way to generate Views from Ef Core CLI as a workground? Thanks.

@ajcvickers

This comment has been minimized.

Member

ajcvickers commented Jul 30, 2018

@irowbin If by "Ef Core CLI" you mean the "dotnet ef" command line tools, then I am not aware of any workaround.

@MikeDempseyFL

This comment has been minimized.

MikeDempseyFL commented Aug 16, 2018

For scaffolding purposes is it not true that a provider can treat a view exactly the same way as a table - except that it will not have any indexes, FKs or a PK?
[This is what I was planning to implement in our provider]
With rather more logic I think we could even copy the PK [and maybe FKs] from the underlying table if it was just a simple select from a single table. [Otherwise it would be read only]

However when it comes to Migrations there would need to be something in the DatabaseTable type to let us know this is a view not a table... otherwise it would be created as a table.

@ajcvickers ajcvickers modified the milestones: 2.2.0-preview2, 2.2.0 Sep 11, 2018

@ajcvickers ajcvickers modified the milestones: 2.2.0, 3.0.0 Oct 1, 2018

@jwooley

This comment has been minimized.

jwooley commented Oct 9, 2018

Since this is now punted to 3.0, should the 2.2 roadmap be updated (aspnet/Announcements#308). I would comment there, but feedback has been turned off on that page.

@divega

This comment has been minimized.

Member

divega commented Oct 23, 2018

Thanks @jwooley. I have posted an update to the announcement.

@ajcvickers ajcvickers removed the size~1-week label Nov 7, 2018

@iSatishYadav

This comment has been minimized.

iSatishYadav commented Nov 9, 2018

I was using Visual Studio Add-> Controller for scaffolding but was unable to scaffold database views.
Here's a hackish but working work-around.

  1. Create view in database.

  2. Create a POCO with same structure as view.

  3. Add a new Controller with POCO created in step#2
    a. If key related error occurs, add a Key attribute on a column and then remove after scaffolding is completed.

  4. A new property with DbSet<T> should have gotten added where T is the class created in step#2. Change DbSet to DbQuery.

  5. In OnModelCreating method of DbContext, add following code:

     modelBuilder.Query<POCO from step#2>().ToView("Name of the view");
    

Source: https://blog.satishyadav.com/How-to-Scaffold-Controllers-with-database-views-to-EF-Core-2-1/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment