Skip to content
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

HasDbFunction to an otherwise unmapped entity causes strange migration behavior #25133

Closed
julielerman opened this issue Jun 21, 2021 · 2 comments
Labels
area-migrations closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. customer-reported Servicing-approved type-bug
Milestone

Comments

@julielerman
Copy link

File a bug

Apologies for my inability to describe this better in the title.

I have a class that I'm using to map to a TVF. It is configured as a keyless entity. It is not used for any other purpose and I do not need to map it to a table or view.

I initially migrated the model including seed data and then created the database from that migration.

Then I manually added a Table-Valued Function to the database. Running my demo, the mappings for the TVF work as expected and I can use them in queries.

The issue is related to migrating this model. I wanted to have a clean slate and include the functions in their own migration file.

Therefore, I deleted the migrations folder completely and then ran add-migration init. The resulting migration looked great. The class that the TVF was mapping to was not being picked up for table creation.

Next I needed an empty migration for the sake of providing the SQL to create the function. When I ran add-migration a second time, rather than empty UP and DOWN methods, migrations added "DROP TABLE" in UP and "CREATE TABLE" in DOWN for the table that was inferred by the class I defined for the mapping.

What I expected of course was an empty migration file.

Include your code

Here is the second migration file. The rest of the repo is on github at: https://github.com/julielerman/MappingDemo/tree/tvfonly

public partial class init2 : Migration
 {
     protected override void Up(MigrationBuilder migrationBuilder)
     {
         migrationBuilder.DropTable(
             name: "CustWithTotalClass");
     }

     protected override void Down(MigrationBuilder migrationBuilder)
     {
         migrationBuilder.CreateTable(
             name: "CustWithTotalClass",
             columns: table => new
             {
                 Name = table.Column<string>(type: "nvarchar(max)", nullable: true),
                 TotalSpent = table.Column<int>(type: "int", nullable: false)
             },
             constraints: table =>
             {
             });
     }
 }

I have experimented with this problem numerous times always with the same result. To be clear, I am literally running add-migration twice in a row without making any changes.

Thanks for either pointing out what I have done wrong (and sorry for wasting your time in addition to my own :( ) or confirming that there ism, indeed, something fishy going on here.

Include provider and version information

EF Core version: 5.0.7
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .NET 5.0
Operating system: Windows 10
IDE: Visual Studio 2019 16.10.2

@AndriySvyryd
Copy link
Member

This is "fixed" in 6.0 via #25034 as HasDbFunction no longer removes the table mapping. However we should consider patching it in 5.0.x

@julielerman I can't access the repro repo.

@julielerman
Copy link
Author

THanks. Definitely aware of the table mapping removal issue and needing to explicitly re-map the table if your hasdbfunction is pointing to an existing one. (n my case I did NOT want a table anyway. But I did not realize that what I was seeing was related. But WHY is this showing up in a SECOND migration? Well if that's all part of the problem in #25034 then I won't worry about it. However perhaps this additional side effect should be documented as well. What do you think?

Also [facepalm], repo defaulted to private when I uploaded it from VS and I forgot to change it. It's public now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-migrations closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. customer-reported Servicing-approved type-bug
Projects
None yet
Development

No branches or pull requests

4 participants