I am in the process of migrating the database from SQL to postgres. The application code is using Entity framework 6. I am facing issues with case sensitivity as postgres stores table, column names in lower case unless using double quotes.
The data present in postgres is in lower case (table and column names). With Entity framework 6, I am facing issues with it not been able to find the table or column names as it is trying to use Pascal case.
I have searched and found few links:
Case insensitive name of tables and properties in Entity Framework 7
The above is for EF7 and most of the solutions doesn't work with EF6. I also tried to look for options in OnModelCreating but didn't find anything useful with DbModelBuilder as this is the object being passed to OnModelCreating.
I don't want to change all the entities to include the table and column names. I am wondering if one of you could help on this.
Appreciate any help.
Have a look at defining some custom Conventions or using the ModelBuilder to standardize case names. (see: https://learn.microsoft.com/en-us/ef/ef6/modeling/code-first/conventions/custom) The other options are to define table and column names via the attributes/configuraion.
Personally, with PostgreSQL I elected to use PascalCase for my table/column names. It meant my manual querying needed to use quotes, but frankly I'm more comfortable looking at naming conventions that way in databases.
I have a situation where I would like to create a 1-to-1 relationship in Entity Framework (4.2) using code first fluent configuration API, the twist is that I need to use a link/map table to do it.
Here is a diagram of my table layout.
This is what I am after ...
HasOptional(x => x.FieldPerson)
.WithOptionalPrincipal()
.Map(map =>
{
map.ToTable("user_account__field_person");
map.MapLeftKey("user_account_id");
map.MapRightKey("field_person_id");
});
... but there doesn't seem to be a way to do it.
The alternative is to create my 3 entities and manage them myself using joins where appropriate.
Is this even possible or is it a scenario that EF fluent API doesn't handle?
I'm going to answer my own question again!
I don't think EF code first deals with this situation because the whole concept of a link/map table suggests a many-to-many relationship.
For my particular case this is a database-first situation and I "have" to deal with these tables as I cannot change the database as this stage.
What I've done is use a Many-to-Many code first configuration ...
HasMany(t=>t.FieldPersons)
.WithMany(t=>t.UserAccounts)
.Map(map =>
{
map.ToTable("user_account__field_person");
map.MapLeftKey("user_account_id");
map.MapRightKey("field_person_id");
});
... as there is nothing in my database schema to prevent me from creating a many to many relationship. If I did want that behaviour then I would simply need to add a unique constraint on each field (which EF code first doesn't support anyway)
Is it possible to auto generate the POCO classes and the mapping with the database defined separately using Fluent API (instead of annotations) for an existing database? Instead of coding all these entity classes manually, I find it easier if they are auto generated and then I can change them as required if the names are not incorrect (plural or singular) or the some of the relationships are not correctly mapped etc. This will save lot of time for me compared to coding all the entity classes and relationships from scratch and I am not that familiar with the fluent API syntax as well.
Yes, i encourage you to use Entity Framework Power Tools CTP1
Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database.
hope this helps
The Power tools are incredibly slow to generate files. It takes over an hour to work on my companies database (has a lot of tables).
Instead take a look at this visual studio extension http://visualstudiogallery.msdn.microsoft.com/ee4fcff9-0c4c-4179-afd9-7a2fb90f5838
It generates cleaner code, WCF serialisation classes, and includes the database default constraints as part of the POCO ctor.
Disclaimer: I should mention that I am the author of this extension
If we've been using an Entity Framework 4 model for some time, and we eventually want to switch the underlying database to a different vendor's product (say, from SQL Server to MySQL), is it simple to adjust the table and column mappings in the entity model without needing to update any of the entity class code?
We're trying to design code that is as database agnostic as possible, so I'd like to know in advance how much trouble we're in for if we ever switch our databases around. Ideally, we'd like to not have to touch our applications that use our entity classes. I can't seem to find any way in the entity designer or XML editor to adjust the underlying database column names without it giving me an error.
(I can, however, edit the entity's property names in the designer while leaving the database column names alone, but that's the opposite of what I need.)
Thanks!
EDMX is not database agnostic. SSDL part of EDMX is tightly coupled with database server (in case of MSSQL even with its version). You need separate SSDL for each supported database server.
I don't understand how changing column names relates to database agnostic model. Reverse is true! If you need your database to have different column names for different server products you need separate mapping for each of them!
Changing column names when using model first is possible only if you modify T4 template used for generating database creation SQL script. But every time you create that script designer will delete whole your storage description (SSDL) and mapping (MSL) and replace them with a new one.
The easiest way to have database agnostic code is using code first but even then you can have problems with some type and feature inconsistency among servers.
If you want database agnostic ORM you should probably check NHibernate.
I'm planning on using the Entity Framework 4.1 in my next project, but I'm having trouble finding a good way to go about it.
In short, I want to build a multi-tiered application in which the entities will be travelling through web services, and to keep it all as clean as possible I want to use POCO's rather than self tracking entities. Also, there already exists a SQL 2008 database that will be used to base the entities on.
From what I've read so far (from Julie Lerman's article on http://msdn.microsoft.com/nl-nl/magazine/hh148150%28en-us%29.aspx, amongst others), it seems that:
If you use the Database First approach, you get a beautiful .edmx to edit your model in, but you'll always end up with persistence-aware objects rather than POCO's, which is not useful in my situation.
If you use the Code First approach, the "ADO.NET DbContext generator" only partially helps you: it does generate entities from the .edmx, but it doesn't generate the code required to get the foreign keys and cardinality correct. This means that the code will not work out-of-the-box (-edit, not true, see my post below-), you either have to
a) use Data Annotations on your POCO's, which is ugly imo because it pollutes the POCO's with database information and also creates a dependency on the EntityFramework assembly.
b) use the DbModelBuilder passed to DbContext.OnModelCreating to set the correct foreign key, mapping etc. information (i.e. the 'fluent' API). And even though the API may be 'fluent', it's still pretty hard (and probably unmaintainable) to set all this information correctly so that it matches the existing database (see http://sessionfactory.blogspot.com/2011/04/conventions-in-entity-framework-41.html for some examples of this).
I realize that the reason why the "DbModelBuilder-way" requires so much effort is because it was designed to be used the other way around: you're supposed to generate the database from the Entity definitions, not try to tweak all Entities so that they (hopefully) match an already existing database. However, it seems to me that the "DbModelBuilder-way" will, in the end, produce the best result: pure POCO's with no database metadata in them.
Now, having said all this, my question is:
Does anyone know of a way to load an .edmx into the DbModelBuilder, so that the foreign key, column mapping and other information doens't need to be specified by hand through the fluent API?
I think that this would be the best of both worlds, because you can visually edit the mapping like you would in the Database First scenario, and still get clean POCO's because all required metadata is stored in the DbModelBuilder.
Man what are you talking about?
If you use the Database First approach, you get a beautiful .edmx to
edit your model in, but you'll always end up with persistence-aware
objects rather than POCO's, which is not useful in my situation.
That is not true. EDMX can produce almost everything code first can and even many things which code first can't.
If you use the Code First approach, the "ADO.NET DbContext generator"
only partially helps you: it does generate entities from the .edmx,
but it doesn't generate the code required to get the foreign keys and
cardinality correct. This means that the code will not work
out-of-the-box, ...
That is not true. Once you set up EDMX correctly it will create exactly entities you want.
Does anyone know of a way to load an .edmx into the DbModelBuilder
That way is DbContext T4 generator!
Anyway there is one more tool you can check: EF Power Tools CTP1. This tool can create code first mapping from existing database.
Of course every tool creates model which is 1:1 mapping to the database. If you want anything more you must modify the model or mapping manually!
Apparently, there are two ways you can use the generated code from the "ADO.NET DbContext Generator", depending on which type of connection string you use.
If you use an entity connection string, i.e.:
<connectionStrings>
<add name="MyDBEntities" connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SqlClient;provider connection string="Data Source=.;Initial Catalog=MyDB;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
</connectionStrings>
the DbContext will be filled with all the metadata (column mappings, foreign key relations, etc.) from the .edmx. Also, the DbContext's OnModelCreating isn't executed. This is Database First using POCO's, and this is what I wanted to achieve.
What I did wrong was that I used a regular SQL connection string to pass into the DbContext. This causes a totally different type of behaviour: because the DbContext is now empty, it will try to explore all Entity classes and use conventions to generate a database schema for this. Now the OnModelCreating is called, expecting you to tweak this mapping and then generate a database from this.
In short, the solution was to use an entity connection string rather than a SQL connection string.
Read about the T4 POCO generation templates:
Walkthrough: POCO Template for the Entity Framework
POCO Template Code Generation Options
Using the POCO T4 Code Generation Template for Entity Data Models (video screencast with Julie Lerman)
Those T4 code generation templates allow you to use
database-first approach with EDMX model file
but: generate simple POCO (plain-old CLR objects) which have no inheritance from any EF specific class - they're just absolutely plain CLR classes.....
This gives you the best of both worlds - a nice EDMX model and persistence-ignorant POCO classes.