In the blog post ROW_NUMBER Support we saw how to implement a custom function and in the previous post Improved Value Conversion Support we realized that inserting and selecting custom types is one thing but using them for filtering is something totally different.
Entity Framework Core (EF) 2.1 introduced a new feature called Value Conversion. Now, we are able to map custom .NET types to a type the database understands and vice versa. This long-awaited feature is especially popular among software engineers following the domain driven design (DDD) patterns.
In the previous post (Custom Functions – using IMethodCallTranslator) we looked at the more flexible approach that requires some boilerplate code. For the usage of a custom function in a project, especially if there are no plans to make the function public then the sacrifice of some (not required) flexibility to reduce the amount of code is fully acceptable.
In the previous blog post (Entity Framework Core: ROW_NUMBER Support) we saw how to use the custom function RowVersion with Entity Framework Core (EF). Now, we will look into the implementation.
There are some use cases that force me to use raw T-SQL instead of using LINQ.
Motivation One of the main queries in my projects is to select multiple database records
When working with Entity Framework Core (EF) a lot of code can be tested using the In-Memory database provider but sometimes you want (or have) to go to the real database. For example, you are using not just LINQ but custom SQL statements due to performance reasons or you want to check that a specific exception is thrown by the database under some conditions like when having a primary key violation.
In the first part of this short blog post series we looked at how to change the database schema of a DbContext, now it is all about changing the schema of the EF Core Migrations at runtime.
The samples are on Github: PawelGerr/EntityFrameworkCore-Demos
One of the new features of Entity Framework Core 2.1 is the support of TransactionScopes. The
In the previous post we have created 2 Entity Framework Core (EF Core) models with a code first approach. One model was using the Table-per-Hierarchy (TPH) pattern and the other one Table-per-Type (TPT). In this post we want to approach a more common scenario we see in customer projects: we are using the database first approach now.
All demos are on Github.
