Add to dbset but not create a table for it

[jvelezc]

Issue: a table named for my stored procedure is created because I am forced to register it in the dbset. If I add builder.ignore then I can't invoke the sp.

I have a stored procedure that I am invoking using the following syntax.

var data = dbCtx.Set<RoleAdminGridViewModel>().FromSql($"[dbo].[uspGetRoleAdminGridViewModelSp]").ToArray();

Since I have to add it to my dbCtx it creates a table called RoleAdminGridViewModel

public DbSet<RoleAdminGridViewModel> RoleAdminGridViewModel { get; set; }

public class RoleAdminGridViewModel
{
  [Key] // I am also not happy that I have to declare a primary key here. Now I always have to use 
// @rownumber in my stored procs.
  int PrimaryKey
}

My work around is to drop the table and name the procedure something different.
CREATE PROCEDURE uspGetRoleAdminGridViewModelSp
SELECT 1 As Primarykey

[rowanmiller]

I think you want the feature we are already tracking with #1862

[divega]

I think there is a subtly different scenario from what we track in #1862 in which you actually do want a type to become an entity in the model but you know that all your queries will be sourced using some FromSql() and probably you will use your own custom SQL or stored procedures for CUD (which at some point EF Core should support). So basically you want Migrations and EnsureCreated() to not create the table but you still want to be able to do things like change tracking.

I believe we have items tracking this, but I cannot find them at the moment 😄

[divega]

I found this one that I believe is related to that scenario:

• Support for defining query Support for defining query in query types #3932

I think we had another issue about just ignoring the table for Migrations and EnsureCreated() but that one I cannot find.

[rowanmiller]

@divega either way I think we have this one covered. But the sample code shows a ViewModel type with no PK etc. so I don't think you would actually want this to be part of the model.

BTW the issue about ignoring tables from migration is #2725

[divega]

Ok, I agree this one is probably a duplicate of #1862 then. Glad we have the other ones as well 😄

[rowanmiller]

Think we have this covered by the other issues already mentioned