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

error mapping sql types in derived types #4251

Closed
esargent opened this issue Jan 7, 2016 · 4 comments
Closed

error mapping sql types in derived types #4251

esargent opened this issue Jan 7, 2016 · 4 comments
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Milestone

Comments

@esargent
Copy link

esargent commented Jan 7, 2016

This is an odd one I found while trying to repo a different issue. Notice that SpecialUser1 and 2 both derive from ApplicationUser. Also notice that they both define "Sex" but of different type. Probably this is an error on the dev's part, but in more complex hierarchies maybe that happens.

The problem is that EF scripts successfully into the database with "sex" column of type int, while SpecialUser2.Sex is type string! I'd expect an error to be thrown.

This is with RC2 16649. Did you loosen up error checking since RC1 - because that might explain why I can't repo the other issue I had where defining the same property in two sibling derived types threw an error, even if they used the same type. (#4224)

using Microsoft.AspNet.Identity.EntityFramework;
using Microsoft.Data.Entity;

namespace WebApplication5
{
public class ApplicationUser : IdentityUser
{
}
public class SpecialUser1 : ApplicationUser
{
//same property in SpecialUser1 and SpecialUser2
public char Sex { get; set; }
}

public class SpecialUser2 : ApplicationUser
{
    public string SomethingElse { get; set; }
    public string Sex { get; set; } //same property NAME in SpecialUser1 and SpecialUser2
    public string SomethingElse2 { get; set; }
}


public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public DbSet<ApplicationUser> ApplicationUsers { get; set; }

    //two derived classes with same property NAME as each other, but different types
    public DbSet<SpecialUser1> Users1 { get; set; }
    public DbSet<SpecialUser2> Users2 { get; set; }

    protected override void OnModelCreating(ModelBuilder builder)
    {
        base.OnModelCreating(builder);
    }
}

}

@smitpatel
Copy link
Contributor

In file MigrationsModelDiffer.cs

        private IEnumerable<IProperty> GetPropertiesInHierarchy(IEntityType entityType)
            => entityType.GetDeclaredProperties().Concat(entityType.GetDerivedTypes().SelectMany(t => t.GetDeclaredProperties()))
                .Distinct((x, y) => Annotations.For(x).ColumnName == Annotations.For(y).ColumnName);

is silently merging properties from derived types which have same name (regardless of other details of property)

@rowanmiller
Copy link
Contributor

Seems like we should throw if the types don't match. Should this happen in model validation of in migrations?

@smitpatel
Copy link
Contributor

The runtime model is presently shown as valid since both the properties are in their respective entities hence possesses all the details about the property. It can be part of model validation.
@AndriySvyryd - views?

@AndriySvyryd
Copy link
Member

It would make sense to validate this in model validation.
See #4074

@rowanmiller rowanmiller added this to the 7.0.0 milestone Jan 11, 2016
@smitpatel smitpatel modified the milestones: 1.0.0-rc2, 1.0.0 Mar 3, 2016
@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Oct 15, 2022
@ajcvickers ajcvickers modified the milestones: 1.0.0-rc2, 1.0.0 Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Projects
None yet
Development

No branches or pull requests

5 participants