Entity Framework 4 Conventions - c#

Is it possible in EF4 to change conventions for a whole DbContext rather than on a per entity basis?
Currently when I run EF4 queries I'm getting an error on foreign key relationships
Invalid column name 'Account_Id'.
The table being queried (User) has a column named AccountId which is a foreign key to the related table (Account), if I change the column to Account_Id, it solves the problem.
However, the issue is that I don't want to do this on every table. I've set custom conventions no problem using NHibernate, so hopefully its as simple in EF4.

I don't think there is support for global settings. You can use fluent API, as you probably know, but this works for single entity only. I've decided to keep EF4 conventions and use xxxID for primary keys and table1_table2 for linker tables. It's easier to swim with, not against the current ;-). You might want to fire reflector to check the code for an easy way to hack it...

Related

How do you manage duplicate relationship in Entity Framework Core when working on Dynamics CRM?

I am working with Dynamics CRM and wanted to test the efficiency of entity framework core to generate the models and context for it's SQL Server database.
Using Scaffold-DbContext, I ran into this error :
The foreign key {'OwningBusinessUnit'} cannot be added to the entity type 'ActivityPointerBase' because a foreign key on the same properties already exists on entity type 'ActivityPointerBase' and also targets the key {'BusinessUnitId'} on 'BusinessUnitBase'
Quick look through the DB and found a relationship duplicated. Meaning: both foreign key constraints target the exact same foreign and primary key field.
They are perfectly identical, only the name differs.
Surely enough the Microsoft documentation shows that to be the case and I found both of these relationship mentioned.
business_unit_socialactivity
business_unit_activitypointer
I also found other such case.
Can I delete any of the two foreign key constraint (doubt it) ? If not, how do I manage this issue ?
I am using Entity Framework Core and .NET Core 3.1.25.
Is this a version issue?
If by "delete" you mean, delete the columns in the database, I would strongly advise you not do that. Typically you don't want to change the models of a system you are using unless you own the system and have a strong understanding of why it was there in the first place. If by "delete" you mean, not include one of the properties in your entity framework model, that will work until you need to update the table, which won't work at that point because the model won't know to update the missing column and may cause the data in the schema to become not well formed (e.g, missing an update to the table's column that should have happened).
Entity Framework supports having two foreign keys to the same table. You may need to set up your foreign key relationship differently. I'm guessing that the entity framework model might be reusing the same property for both foreign key relationships. If that's the case, then you need to add a second property representing the second foreign key.
It seems suspicious to me that the schema has a duplicate foreign key for the exact same purpose. I'd double check to make sure your understanding of its purpose is correct. It could be due to a refactor that Microsoft did to get a new standard name while retaining backwards compatibility in parts of their system or customer systems. If both foreign keys actually represent the same relationship (I think this is unlikely) Consider instead not specifying that both are a foreign key in the entity framework model. Specify that one is the foreign key, and don't specify that the other one is. Entity Framework will treat that as the property for navigation and join purposes, and think of the other as just a data column. Then it'll be up to you to make sure the other column is set correctly if it's changed.
If the entity framework model and configuration is being generated from a tool and you're getting this error, you may have to specify the model and configuration by hand to get the correct behavior.

Entity Framework 6.0 SQL-first synch with database without .edmx?

I have a database with some tables for school related project and I have a model with EF 6.0 SQL-first approach. I need to update the database with a new table & update an existing table with a new column. The twist is: I don’t have any *.edmx file.
How can I update the model without it? If it is impossible, then how can I generate *.edmx without interrupting the existing model?
Entities are essentially POCOs, so you really just need to update your schema and update the entity classes to match. For new entities if the project is not using an edmx then it should either be using classes extending EntityTypeConfiguration or setting things up with the modelBuilder on the OnModelCreating event in the DbContext.
EF can resolve most general mappings using convention, so adding a column to a table usually just means adding the property to the entity. Mapping only comes into play when you want to change a columns naming, handle type casting differences, or use identity/computed columns. For new entities it can also use convention, but commonly there would be config used for the Table name, PK name, and things like Identity columns, plus navigation properties for related entities.

Add entity relationship to EF Core scaffolded entity when database cannot be changed - and retaining the addition on rescaffold

I am using a database-first approach to a third party database that I cannot change. The database has two tables that should have a constraint defining their primary/foreign key relationship. The constraint is missing so the entities generated do not have the relationship. Is it possible to add the entity relationships to the scaffolded entities without losing my additions if I need to scaffold again (due to an upgrade etc)?
I've thought about creating a custom partial class file extending the existing entity but this will not work if the existing entity already has a constructor. I need a constructor to instantiate a HashSet<T> of the other side of the relationship. I've also thought about using inheritance but not sure if that will work well with the existing entity.
Update: It seems like easiest solution may be to instead use linq join syntax and not provide the relationship in the entities but I'll leave the question up in case anyone has a good solution and a use case where it is beneficial.

Using EntityFramework C# code-first from database - how to map table with no primary key

I am building an Ntier application with EntityFramework c#.
I am adding an Entity Data Model in my Data Access Layer with code-first approach from existing database.
Some of the tables of my db weren't included because they don't have primary key. I have seen some ways to work around this problem, modifying EntityFramework's edmx to force the mapping to the database, disguising some field like a key. But I am not using the .edmx, since I can't use automatic migrations with it. I only generate POCOs from my existing database and then go on with code first migrations.
Is there a way to force Entity Framework to generate a POCO for those tables without primary key ? Some only have one entry and really don't need PrimaryKey
In the end, I just wrote my own POCOs for the tables that weren't included.
I used an attribute [KEY] above the property i wanted to act like key. I added DbSet lines in the DataModel and EF did recognize them in my database.
I didn't want to generate primary keys because my boss didn't want, and thats a reason good enough. :) Hope the best for you thx for answer

Entity Framework: determine sides of foreign key relation

Is there a way to find which class is ,,Parent" and which is ,,Child" in FK relation? I can't think of a method to reliably accomplish it by using reflection and I don't have any idea how to do this with metadata without parsing strings. I am looking for something which would return Type of a ,,Parent" object.
The Entity Framework Mapping Api is one way to do it. I think it is technically possible to do what you need directly against EF but the code is a nightmare. I recall just trying to look up the primary keys directly against EF and it was convoluted. This library will make you life a lot easier.
The only one thing it does not do is show you the child relations, just the Foregin Keys. So you will need to implement your own logic to get child relations.

Categories