Why can’t I define a member with the same name in subclasses? I have a one table per class inheritance with a rowversion timestamp field in each table. It seems like the Entity designer should allow for this and use the new keyword on the property to make it happen. What is the workaround? How can I specify the same field in an inheritance chain with different values if I can’t use new? This may be true for other databases that have rowguids, modifiedbys, modifieddates, etc.
Edit: I guess the logical way to do it would be to just rename the reference to the field, ie PersonRowversion in the Student class that decends from Person.
Am I missing a piece of EF that can track these kinds of fields automatically though?
Because a class cannot have two members with the same name. ‘new’ won’t do what you want. ‘new’ hides the inherited member; it doesn’t give you two different members with the same name. So if the code generated used ‘new’ then you would never be able to access the value in the ‘parent table’ from your C# code. It is fine for both database tables to have two columns of the same name, but you need to rename the duplicate column names in your conceptual model when two tables make up one class.
In terms of ‘modified date,’ etc., you generally only need one. If you have a super type of Animal and a subtype of Dog, the Entity Framework considers an update to the ‘animal portion’ or the ‘dog portion’ of the type to be an update to the entire instance, just like C# does.
Remember that the conceptual model and the storage model are different things, and play by different rules. Be careful of thinking in strictly OO or strictly relational terms when working in your entity model. Inside the entity model, you are bridging both worlds. As I wrote elsewhere:
One of the mental barriers that you have to get over when designing a good object relational mapping is the tendency to think primarily in object oriented terms, or relational terms, whichever suits your personality. A good object relational mapping, though, incorporates both a good object model and a good relational model. For example, let’s say you have a database with a table for People, and related tables for Employees and Customers. A single person might have a record in all three tables. Now, from a strictly relational point of view, you could construct a database VIEW for employees and another one for customers, both of which incorporate information from the People table. When using a one VIEW or the other, you can temporarily think of an individual person as ‘just’ an Employee or ‘just’ a Customer, even though you know that they are both. So someone coming from this worldview might be tempted to do an OO mapping where Employee and Customer are both (direct) subclasses of Person. But this doesn’t work with the data we have; since a single person has both employee and customer records (and since no Person instance can be of the concrete subtype Employee and Customer simultaneously), the OO relationship between Person and Employee needs to be composition rather than inheritance, and similarly for Person and Customer.