NotMapped Error in EF5 and .NET 4.5 - c#

In VS2012(.NET 4.5 and Entity Framework 5 )
When exposed the inheritance relationship,caused the compile-time errors:
You cannot use Ignore method on the property 'InnerString' on type
'MrTree.SubSubClass' because this type inherits from the type
'MrTree.BaseClass' where this property is mapped. To exclude this
property from your model, use NotMappedAttribute or Ignore method on
the base type.
The code is as follows:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Data.Entity;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
MyDbcontext db = new MyDbcontext();
int i = db.SubSubClasses.Count();
}
}
public class BaseClass
{
[NotMapped]
public string InnerString { get; set; }
}
public class SubClass : BaseClass
{
}
public class SubSubClass : SubClass
{
}
public class MyDbcontext : DbContext
{
public DbSet<SubSubClass> SubSubClasses { get; set; }
public DbSet<SubClass> SubClasses { get; set; }
}
}
Can you tell me what's wrong?

I have found a work around for this issue I have experienced myself. I did post some supplementary information about what might be causing the issue but it was deleted by some egotistical nerd who felt it wasn't worthy.
So here is my ANSWER to this problem - might not be entirely right but it works for me so please don't delete this Mr Nerd just in case it helps out someone else.
Firstly, this issue only affects classes that do not inherit the abstract class using the NotMapped attribute directly but instead those that inherit from another class that itself inherits from the base class, as per the original statement.
The following works for me using something similar to the following class setup:
BASE CLASS:
public abstract class EntityBase
{
public virtual int Id { get; set; } // this will be mapped
public virtual int DoNotMap { get; set; } // this should be ignored
}
FIRST LEVEL INHERITANCE
public class Contact : EntityBase
{
public string Name { get; set; }
}
SECOND LEVEL INHERITANCE
public class Employee : Contact
{
public DateTime StartDate { get; set; }
}
Create a generic configuration class that inherits from EntityTypeConfiguration:
public class DataEntityBaseConfiguration<T>
: EntityTypeConfiguration<T> where T : EntityBase
{
public DataEntityBaseConfiguration()
{
Ignore(x => x.DoNotMap);
}
}
Create configuration classes for all first level inheritance that inherit directly from the EntityBase class, i.e.:
public class ContactConfiguration : DataEntityBaseConfiguration<Contact>
{
// place any further configuration rules in the constructor
}
WORKAROUND: any classes that inherit from the EntityBase indirectly, simply create a Configuration class that inherits from EntityTypeConfiguration:
public class EmployeeConfiguration : EntityTypeConfiguration<Employee>
{
// place any further configuration rules in the constructor
}
In your DataContext, in the OnModelCreating method, add you configurations:
modelBuilder.Configurations.Add(new ContactConfiguration());
modelBuilder.Configurations.Add(new EmployeeConfiguration());
Assuming a TPT approach in this instance, map the specialised version, Employee to its own table with an FK relation to Contact:
modelBuilder.Entity<Contact>().Map<Employee>(m => m.ToTable("Employees"));
This, for me at least, creates a contact table without the "DoNotMap" property and an Employee table without the "DoNotMap" table and with a PK/FK relation to Contact. Even though I do not inherit from the EntityBaseConfiguration for Employee Configuration, it still, somehow, picks up Ignore and leaves it out.
I would assume that if we went with a TPH approach, we would simply end up with a single Contact table plus Discriminator column. TPC would obviously recreate all the Contact properties in the Employee table but I'm not sure if it would also create the DoNotMap property - will test that when I have a moment spare.
In short, going back to the original question, I'm not sure why this happens with both the NotMapped attribute and the Ignore. I was getting the error when my EmployeeConfiguration inherited from the EntityBaseConfiguration. I'm not keen on the workaround as it firstly the error is false in its statement and secondly, it's a an error that would easy to fall into again, even if the solution is now quite simple.
Hope that helps anyone that has struggled with this inheritance issue.
Regards

The fact that the primary key has to be included in the POCO class definition A already means that Ais not a POCO object. You cannot ignore properties on POCO objects

Do you have a property called InnerString in your SubSubClass? That's what the error is saying, although you don't have it listed in your example code.
Your code above worked for me, but I had to add a PK, here's the entire Console app:
public class BaseClass
{
public int Id { get; set; }
[NotMapped]
public string InnerString { get; set; }
}
public class SubClass : BaseClass
{
}
public class SubSubClass : SubClass
{
}
public class MyDbcontext : DbContext
{
public DbSet<SubSubClass> SubSubClasses { get; set; }
public DbSet<SubClass> SubClasses { get; set; }
}
class Program
{
static void Main( string[] args )
{
var context = new MyDbcontext();
context.SubSubClasses.Add(new SubSubClass());
context.SaveChanges();
}
}
And the database it created:

Related

Entity Framework Context.Set<T> throwing error "Entity type 'ClassName' is not part of the model for the current context"

I have 2 classes that represents the same table in the Database, Difference is in the properties of these classes. I am using this way because of differences in the custom fields in databases the application will connect to.
[Table("T1")]
public class Class1
{
.
.
}
[Table("T1")]
public class Class2
{
.
.
}
Here Now i am using the set method to get data. I have not declared anything in the DB context.
DbSet<Class1> set = context.Set<Class1>();
return set.Where(p => p.Active == "Y");
But system throws error
'Entity type 'Class1' is not part of the model for the current context'
What i am trying to achieve is to define the model for the DbSet dynamically, is this possible in some other way?
To use the DbContext.Set<T>() method, your context needs to have a matching DbSet<T> property. If you have a setup where one of the tables changes, then you have a couple of options.
Add both DbSet<Class1> and DbSet<Class2> properties to your DbContext:
public DbSet<Class1> Class1s { get; set; }
public DbSet<Class2> Class2s { get; set; }
I'm personally not a fan of doing this.
Have a generic context and make the table that changes inherit from a common base. For example:
public class BaseClass
{
//shared properties go in here
}
public class Class1 : BaseClass
{
//custom properties here
}
public class Class2 : BaseClass
{
//custom properties here
}
And your context could look like this:
public class MyContext<T> : DbContext
where T : BaseClass
{
public DbSet<T> Class1s { get; set; }
}

Can C# constraints be used without a base type?

I have some classes with common properties, however, I cannot make them derive from a base type (LINQ-to-SQL limitations).
I would like to treat them as if they had a base type, but not by using Reflection (performance is critical).
For example:
public class User
{
public int Id { get; set; }
public string FirstName { get; set; }
}
public class Vehicle
{
public int Id { get; set; }
public string Label { get; set; }
}
In this case I would be happy if I had the Id property available, regardless of the type I'm holding.
Is there any way in C# to to something similar to this:
public static int GetId<T>(T entity) where T // has an int property 'Id'
{
return entity.Id;
}
I guess I could have used dynamic, however, I'm looking for a way to restrict the code in compile time from using this method for an object that has no Id property.
You can use interfaces:
public interface IHasId
{
int Id { get; }
}
public class User : IHasId { ... }
public class Vehicle : IHasId { ... }
public static int GetId<T>(T entity) where T : IHasId
{
return entity.Id;
}
However, if you are not able to modify the classes to add the interface, you won't be able to do this. No compile-time checks will verify that a property exists on T. You'd have to use reflection - which is slow and obviously not ideal.
There is no way to guarantee a type has a given member without constraining to a common base type or interface. One way to work around this limitation is to use a lambda to access the value
public static int Use<T>(T value, Func<T, int> getIdFunc) {
int id = getIdFunc(value);
...
}
Use(new User(), u => u.Id);
Use(new Vehicle(), v => v.Id);
You can create an interface with the common properties and make your classes implement it:
public interface IEntity
{
int Id { get; set; }
}
public class User : IEntity
{
public int Id { get; set; }
public string FirstName { get; set; }
}
public class Vehicle : IEntity
{
public int Id { get; set; }
public string Label { get; set; }
}
public static int GetId<T>(T entity) where T : IEntity
{
return entity.Id;
}
You could simplify GetId like this:
public static int GetId(IEntity entity)
{
return entity.Id;
}
The other answers mentioning the interface approach are certainly good, but I want to tailor the response to your situation involving Linq-to-SQL.
But first, to address the question title as asked
Can C# constraints be used without a base type?
Generally, the answer is no. Specifically, you can use struct, class, or new() as constraints, and those are not technically base types, and they do give some guidance on how the type can be used. That doesn't quite rise to the level of what you wish to do, which is to limit a method to types that have a certain property. For that, you will need to constrain to a specific interface or base class.
For your specific use case, you mention Linq-to-SQL. If you are working from models that are generated for you, then you should have options to modify those classes without modifying the generated model class files directly.
You probably have something like
// code generated by tool
// Customer.cs
public partial class Customer // : EntityBaseClasses, interfaces, etc
{
public int ID
{
get { /* implementation */ }
set { /* implementation */ }
}
}
And other similar files for things such as Accounts or Orders or things of that nature. If you are writing code that wishes to take advantage of the commonly available ID property, you can take utilize the partial in the partial class to define a second class file to introduce a common interface type to these models.
public interface IIdentifiableEntity
{
int ID { get; }
}
And the beauty here is that using it is easy, because the implementation already exists in your generated models. You just have to declare it, and you can declare it in another file.
public partial class Customer : IIdentifiableEntity { }
public partial class Account : IIdentifiableEntity { }
// etc.
This approach has proven valuable for me when using a repository pattern, and wishing to define a general GetById method without having to repeat the same boilerplate in repository after repository. I can constrain the method/class to the interface, and get GetById for "free."
Either you need to make both classes implement an interface with the properties you need, and use that in the generic constraint, or you write separate methods for each type. That's the only way you'll get compile-time safety.

Accessing Properties or a Parent Class from Base

I am attempting to create an application which interacts with a database.
I program in many languages and I loved how easy it was to use Models in an MVC based application.
So my question is, trying to replicate this functionality, I have 2 classes as follows:
Base Class:
public class BaseModel
{
protected string TableName { get; set; }
public BaseModel()
{
}
public void Save()
{
// Save data in derived class to table stored in TableName
}
}
Derived Class:
public class UserModel : BaseModel
{
public string Field1 { get; set; }
public string Field2 { get; set; }
public UserModel()
{
base.TableName = "user";
}
}
From my main application, i want to be able to do the following:
public class Class1
{
public Class1()
{
UserModel model = new UserModel();
model.Field1 = "Value1";
model.Field2 = "Value2";
model.Save();
}
}
Here is where i have hit a problem. I cannot for the life in me figure out, how i would be able to access the properties in UserModel so they can be saved to the database table specified in in the constructor of UserModel to the BaseModel.
Hope this made sense. :)
This code is not my working code, it is a very simple representation of what i would like to achieve so Fields and properties (validators etc) have been dumbed down for ease of reading.
I think that a more "real" example would actually help understand better, but I think that you should create a virtual (or even abstract) method in the base class to get the data to save in the database:
public class BaseModel {
protected virtual string GetDataToSaveInDB() {
// if it makes sense to have the data as a string...
}
public void Save() {
string data = GetDataToSaveInDB();
// do something with data...
}
}
Then you return the data in the derived classes:
public class UserModel : BaseModel {
protected override string GetDataToSaveInDB() {
return "Field1=" + Field1 + ";Field2=" + Field2;
}
}
This is just to illustrate the concept, if you provide more information it will be easier to provide a real answer.
How do you save the data in your DB? How is the structure to the table?
This is in general solved by utilize abstract functions at the base level and then overriding them with specifics in the derived class. So would would set up a call tree in the base but functions that need to know the details of the derived class would be implemented in the derived class.
public class BaseModel
{
protected string TableName { get; set; }
public BaseModel()
{
}
public abstract void Save();
}
In this case where you have one concrete data representation manifested in a base class it may be better to create a DTO object which your business classes take in a utilize. This is the approch of most of the frameworks like entity.

Entity Framework and generics

I have a couple independent objects, each of which has a list of a common object. For instance,
public class Project
{
public IEnumerable<CommentEntry<Project>> Comments{get;set;}
}
public class Sample
{
public IEnumerable<CommentEntry<Sample>> Comments{get;set;}
}
public class CommentEntry<T> where T: class
{
public int TId {get;set;}
public int CommentEntryId{get;set;}
public DateTime TimeStamp{get;set;}
public string Comment{get;set;}
}
Using fluent api of Entity Framework 5, I would like a CommentEntry table for Projects and Requests. So, here is my mapping code:
modelBuilder.Entity<CommentEntry<Project>>()
.Map(m =>
{
m.ToTable("EngineeringProjectComments");
});
modelBuilder.Entity<CommentEntry<Request>>()
.Map(m =>
{
m.ToTable("SampleRequestComments");
});
When I attempt my migration I encounter the following message:
The type CommentEntry`1[Project]' was not mapped. Check that the type has not been explicitly excluded by using the Ignore method or NotMappedAttribute data annotation. Verify that the type was defined as a class, is not primitive, nested or generic, and does not inherit from EntityObject.
I can see the obvious flaw of my attempt to use generics in this context. However, can anyone suggest an alternative to my database table structure, classes code or mapping code that will allow me to share the single, generic type among many classes and have independent tables?
Just use the normal inheritance structure. And, instead of using a specific ID name, like EngineeringProjectId, just use Id.
public class Project
{
public ICollection<ProjectCommentEntry> Comments{get;set;}
}
public class Sample
{
public ICollection<SampleCommentEntry> Comments{get;set;}
}
public class ProjectCommentEntry : CommentEntry {}
public class SampleCommentEntry : CommentEntry {}
public class CommentEntry
{
public int Id {get;set;}
public int CommentEntryId{get;set;}
public DateTime TimeStamp{get;set;}
public string Comment{get;set;}
}
By the way, you can't use IEnumerable for navigation properties in EF, you need a full collection which is why you should use ICollection instead.

EF 4.0 generics based inheritance

I have a class like this
public abstract class BaseType<T>
{
public string Name {};
public T TypedValue {
get {
return GetTypedValue(PersistedValue);
}
};
public string PersistedValue {}
public abstract T GetTypedValue(PersistedValue);
}
then many derived classes like
public class IntegerType:BaseType<int>
{
...
}
is it possible to map this hierarchy using EF 4.0 using Table per inheritance scheme ?
Currently the generated code creates has an error because it generates a property like
public <T> ObjectSet<TypedAttribute<T>> TypedAttributes
{
get
{
return _typedAttributes ?? (_typedAttributes = CreateObjectSet<TypedAttribute<T>>("TypedAttributes")); }
}
private ObjectSet<TypedAttribute> _typedAttributes;
I don't think so because:
Inheritance mapping requires the base class to be entity in EDMX.
When inheritance is used the ObjectSet is for base type. What generic argument would you use to create an instance of ObjectSet when it has to be used to retrieve any subtype?
It can be partially achieved without inheritance (at least for POCOs). Simply model your subtypes in EDMX without base type. Then manually create POCO classes and derive them from generic base types. The only rule you have to follow is that POCO class must have the same name as entity in EDMX and it must have all its properties with accessibility set in EDMX. If you want to use change tracking properties must be marked as virtual. If you want to use lazy loading navigation properties must be virtual as well.
Example:
Suppose that I have two entities in EDMX: IntegerValue and DoubleValue. Now I defined these POCOs as follows:
public abstract class BaseType<T>
{
public virtual int Id { get; set; }
public virtual string Name { get; set; }
public virtual T Value { get; set; }
}
public class IntegerValue : BaseType<int>
{ }
public class DoubleValue : BaseType<double>
{ }
It will result in single table per sub type.

Categories

Resources