I'm using the code-first approach (per se) in EF, however, I'm using T4 to generate a class per table, and then creating the associations in a separate partial file. I know I can use the edmx to generate poco's with table-per-type but thats not a route I want to go down.
It appears to work until I have a class name that's the same as another class, even though both classes are in different namespaces.
The solutions I've found seem to solely revolve around fixing the metadata in the connection string, however, since I have no edmx (csdl, ssdl, msl) I'm not sure how to correct the issue. Here's a related question, but the solution doesn't appear to be something that will help me - Can't have the same table names in different entity framework models?
Unfortunately just renaming the class is not a solution for us.
Here's the error:
The mapping of CLR type to EDM type is ambiguous because multiple CLR
types match the EDM type 'AppConfig'. Previously found CLR type
'Utility.AppConfig', newly found CLR type 'Config.AppConfig'.
Apprently this is fixed in EF 6 - for code first only.
Related
SQL database, in mvc project I use EF to create model classes. One of the classes has two fields related to one field of another class, many-to-one relation. They are named like "Field" and "Field1" in this linked class. Is there a way to rename auto-generated names of these two virtual fields in the class?
EDIT. Or maybe just a conclusion.
It looks like it's a messy topic about linking a database to an asp.net application. There are different approaches and tools and there are ways to abstract from it like partial classes, viewmodels, automappers and all with their own bugs and workarounds... and there is no a comprehensive tutorial on all this stuff explaining what and when and how to use... such a visual development environment... pure easiness.
I understand that Code First used to have a problem (or maybe still does) when you have two classes with the same name in different namespaces. I have found numerous posts about this. I have something a little... different?
Well, however they "fixed" it, they made it worse. I don't HAVE two classes with the same name, I have ONE class. I promise you, you are not seeing double. The class name that appears below is exactly the same, and there is not other classname.
The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'Classname'. Previously found CLR type 'App.Domain.Classname', newly found CLR type 'App.Domain.Classname'.
I get this error repeated many times (for different class names) when I attempt to create a new controller with the Template "MVC controller with read/write actions and views, using Entity Framework."
If you are having more than one edmx file in same module this problem will be occur. And even within those edmx it may have same kind of two entity was exist. This is framework issue from ef4. But it can be resolve by.changing the entity name manually.' Which was created by edmx generated. Or simple add one more dump column in any one.of the entity. In first way we should do more changes in all the entity class as well as reference entity class also.
And here goes yet another question on NHibernate.
This one most likely doesn't have a desired answer, but still - let's give it a try.
I'm currently putting all the efforts into mapping a domain model onto the database using NHibernate. This domain model comes from a framework which is heavily obfuscated. (Not that I have worked a lot with obfuscated code before, but this one in most of the places can be translated neither by Reflector, nor by Resharper.)
Everything went more or less fine until I faced an entity with a required many-to-one relationship represented by a property with no setter with obfuscated backed field.
Is it possible to reference this obfuscated field somehow? A very special IPropertyAccessor?
If not, how can I load a fully constructed entity? The only option to inject a related object is by using a constructor that accepts it. But at the time of instantiating of an entity being loaded, neither IInstantiator nor IInterceptor has any data of it apart from the key. Any other extension points that suit my need?
To allow NHibernate to access your field instead of property you can use this in your mappings:
access="field"
I have a situation where I have a Common.Domain.Person and Specific.Domain.Person.
First one should be provided as a part of a common package.
Second one appears when common package has to be customized to fit the needs of specific project.
In the object model, it can be easily implemented with inheritance.
In the NH mapping, however, I have encountered a small problem.
I can create an NHibernate <subclass> mapping, but that would require me to use an discriminator. However, I know that if specific person class was inherited, then common class instances will never be used within this specific project.
What is the best way to implement this without adding discriminator column to the base class (since there are no different cases to discriminate)?
this is what i wanted and nhibernate supports it using xml entities. Unfortunately this feature has been borked since (at least) NH v2++.
see also Using Doctype in Nhibernate
A work-around could be to inject these properies programmaticaly when you create the SessionFactory (Dynamic Mapping)
see also http://ayende.com/Blog/archive/2008/05/01/Dynamic-Mapping-with-NHibernate.aspx
Just map the Specific.Domain.Person and leave Common.Domain.Person unmapped.
If you are not saving instances of it, NHibernate does not need to know about it.
I'm trying to create a set of tables where we don't actually delete them, but rather we set the archive flags instead. When we delete an entity, it shouldn't be deleted, it should be marked as archived instead.
What are the programming patterns to support this?
I would also prefer not to have to roll out my own stored procs for every table that have these archive flags if there is another solution.
This is an old question and it doesn't specify the EntityFramework version. There are a few good solution for newer versions:
Entity Framework: Soft Deletes Are Easy
Soft Delete pattern for Entity Framework Code First
Entity Framework 5 Soft Delete
Also there are sources for EF 6.1.1+
Highlights of Rowan Miller’s EF6/EF7 Talk at TechEd 2014
Entity Framework: Building Applications with Entity Framework 6
myEntity.IsArchived = true;
context.SaveChanges();
if your requirements are to not delete, then don't delete ;-)
You'll have to write your own logic to do this, and steer clear of the "MarkForDeletion" method on those entities.
Your logic will need to take a provided entity, alter it in some way to signify it is now "archived", and then Save the changes on the context.
You'll then need to make sure any code pulling from the DB honors these values that signify an archived record.
To make it simpler, you can create partial classes to match your entity classes, so they honor say, a custom interface. That way you can code against the interface and not have to use reflection to set the entity values.
If you can use .NET 4.0, EF supports POCOs and you can mark the entities natively with the appropriate interfaces, which will cut down the number of files you have to work with.
I'm not sure about best practices, but you might try writing your own DeleteObject method and putting it in a class of some sort (EFHelper is the name of the class I use for these sorts of things). Then instead of calling ObjectContext.DeleteObject, you call EFHelper.DeleteObject, and do any custom logic you care to do in that method. If you're consistent with the way you name these archive flag properties, you can use .NET's reflection API to find the archive_flag property of each EntityObject you're "deleting" and set it appropriately.