JSON and TPH Discriminator aclaration

[soycabanillas]

I've been trying to use JSON to store different entities on the same table. The only difference between the child objects is that every child object has different type to serialize/deserialize to/from the JSON field::

    public enum PersonEnum
    {
        Unknown = 0,
        Customer = 1,
        Employee = 2
    }

    public class Person
    {
        [Key]
        public long Id { get; set; }
        [Required]
        public string Serialized { get; set; }
        public PersonEnum Type { get; set; }
    }

    public class Customer : Person
    {
        public class CustomerData
        {
            public string VipLevel { get; set; }
            public string Preferences { get; set; }
        }

        [NotMapped]
        public CustomerData Data
        {
            get { return JsonConvert.DeserializeObject<CustomerData>(Serialized); }
            set { Serialized = JsonConvert.SerializeObject(value); }
        }
    }

    public class Employee : Person
    {
        public class EmployeeData
        {
            public string Name { get; set; }
            public decimal Salary { get; set; }
        }

        [NotMapped]
        public EmployeeData Data
        {
            get { return JsonConvert.DeserializeObject<EmployeeData>(Serialized); }
            set { Serialized = JsonConvert.SerializeObject(value); }
        }
    }

The DBContext configuration:

modelBuilder.Entity<Person>()
.HasDiscriminator<PersonEnum>(nameof(Person.Type))
.HasValue<Person>(PersonEnum.Unknown)
.HasValue<Customer>(PersonEnum.Customer)
.HasValue<Employee>(PersonEnum.Employee);

Now I can search by any Person, only by Customer or only by Employee. My question is about this behaviour, as I've been spent a while trying to make this work and I don't want to misunderstand the design behind the TPH / discriminator thing.

First and foremost... is going to work like that in the future? I'm not sure but I think the last time I tried something similar it didn't work #6001. Maybe the previous version did something different?

Is there any reason to have to specify a value for the parent type? I don't understand why the parent type has to have a value.

Sorry to bring again an issue related with TPH, but I've spent quite time trying to make this work and I would like to check that is aligned with your design decisions.

I'm using Microsoft.EntityFrameworkCore.SqlServer 1.1.0

[rowanmiller]

First and foremost... is going to work like that in the future? I'm not sure but I think the last time I tried something similar it didn't work #6001. Maybe the previous version did something different?

Everything looks good, that is how we intend the feature to be used.

Is there any reason to have to specify a value for the parent type? I don't understand why the parent type has to have a value.

Because it isn't an abstract class, there is nothing preventing you from adding and saving an instance Person. If it was an abstract class, the it wouldn't need a value.