On December 4, the final version of EF Core 2.2 was released. It is released in parallel with ASP.NET Core 2.2 and .NET Core 2.2 and is the most recent release of our open-source and cross-platform technology for managing the mappings between language objects and the database.

EF Core 2.2 RTM contains more than a hundred fixes and several new features, which we will discuss in this article.

Links lead to relevant articles on Habré. This is the last, third article of the series. Next time we will talk about the new release - and it will be in the new year.

Spatial data

Spatial data is used to store the physical location and shape of objects. Many existing databases have built-in methods for storing, indexing, and searching for such data. The main use scenarios are to search for objects at a selected distance and verify that one of the polygons contains a given point. EF Core 2.2 can now work with such databases and geodata in them using types from the NetTopologySuite library (NTS).

Spatial data is implemented as a set of extension packages for special providers. Each of these packages adds both new mappings for NTS types and methods, and the corresponding spatial types and functions in the database. Such provider extensions have already been implemented for SQL Server, SQLite and PostgreSQL (thanks to the Npgsql project). Spatial types can be used directly, together with the EF Core in-memory provider, without using any other extensions.

As soon as the extension is installed, support for new types is included. Properties with these types can be used in your entities, for example:

using NetTopologySuite.Geometries; namespace MyApp { public class Friend { [Key] public string Name { get; set; } [Required] public Point Location { get; set; } } } 

Of course, now this data can be saved:

 using (var context = new MyDbContext()) { context.Add( new Friend { Name = "Bill", Location = new Point(-122.34877, 47.6233355) {SRID = 4326 } }); context.SaveChanges(); } 

Similarly, it becomes possible to make queries to the database that involve spatial data and operations:

  var nearestFriends = (from f in context.Friends orderby f.Location.Distance(myLocation) descending select f).Take(5).ToList(); 

Spatial data is a big topic, familiarity with which you should start with official documentation .

Dependent Entity Collections

In EF Core 2.0, it became possible to model one-to-one relationships. EF Core 2.2 extends this feature with the ability to directly indicate who is in this respect the main entity (owner) and who is dependent (owned). This allows you to limit and clarify the scope of the entity.

For example, dependent entities:

• Can only be used in reference properties ( “navigation property” ) contained in other types of entities;
• Automatically loaded and tracked in DbContext only along with its main entity.

In relational databases, dependent collections are not displayed in the table of the main entity, but in separate tables, similar to the usual one-to-many relationships. In document-oriented databases, everything is somewhat different, and we plan to put dependent entities (in dependent collections or links) in the same document that stores the main entity.

The feature can be used by calling the new OwnsMany() API:

 modelBuilder.Entity<Customer>().OwnsMany(c => c.Addresses); 

For more information, refer to the documentation .

Query tags

This feature is designed to simplify the task of finding the connection between LINQ queries in the code and the SQL queries generated from them, which can be found in the logs.

To enable tags, you must annotate a LINQ query using the new TagWith() method. Let's slightly modify the previous example from the section on spatial data:

  var nearestFriends = (from f in context.Friends.TagWith(@"This is my spatial query!") orderby f.Location.Distance(myLocation) descending select f).Take(5).ToList(); 

In the log you will see the following text:

 -- This is my spatial query! SELECT TOP(@__p_1) [f].[Name], [f].[Location] FROM [Friends] AS [f] ORDER BY [f].[Location].STDistance(@__myLocation_0) DESC 

As always, there is about it [section in the documentation].

Compatible with EF Core 2.1

We spent a lot of time and effort by ensuring backward compatibility of EF Core 2.2 with existing providers of EF Core 2.1 and making sure that the application is assembled without any visible problems after updating to EF Core 2.2. Most likely, in most cases, the migration to the new version will be simple, but nevertheless, if you suddenly encounter problems, you should tell about them in our bugtracker .

At the moment there is only one change that may require small changes to the application code. You can read about it in the description of the following ticket:

• # 13986 : A type configured at the same time as a normal property and as a dependent requires the creation of a primary key immediately after upgrading from 2.1 to 2.2.

We intend to continue to maintain and update the list of problems requiring modification of the old code.

What's next: EF Core 3.0

After the release of version 2.2, our next target is EF Core 3.0. We have not yet implemented any new features, so the NuGet packages released on December 4 contain only a few small changes made after the release of EF Core 2.2.

There are already some widely discussed big ideas planned for the next release. We want to talk about them in the following news releases, but here are a few topics about which you can already say something:

• Improvements in LINQ . LINQ allows you to write database queries without having to switch from your primary language to a database language, using type information to display IntelliSense and validate at compile time. But this also means that LINQ allows you to write an unlimited number of complex queries that have always been a real test for LINQ providers. In the first versions of EF Core, we solved this problem by determining which parts of the query can be translated to SQL, and then allowed the rest of the query to run directly on the client, using the memory of this client. This client-side execution can sometimes be useful, but in many cases it leads to extremely inefficient queries that cannot be found until the code goes into production. In EF Core 3.0, I want to do a thorough job of changing the LINQ internals and how to test them. It is necessary to make them more robust and reliable (for example, so that requests do not break after rolling in fresh patch releases); implement the correct translation in SQL of a greater number of expressions; focus on generating queries that will work more efficiently in more cases; consider that ineffective requests do not go unnoticed.

  
  
  

• Cosmos DB support . We are continuing to work on the Cosmos DB provider for EF Core so that developers familiar with the EF software model can immediately target Azure Cosmos DB as their main base. The challenge is to use the very best in Cosmos DB, for example global distribution, “always on” availability, elastic scalability, low latency, and so on. The EF Core provider must provide most of the available features. We started doing this long before EF Core 2.2 and even released a few preliminary versions . We will continue to develop the provider in parallel with EF Core 3.0.

  
  
  

• Support C # 8.0 . In C # 8.0 there are several useful innovations like async streams (including await foreach ) and nullable reference types, which are supported in the EF Core.

  
  
  

• Reverse engineering database in query types . EF Core 2.1 added support for query types that represent data that can be read from the database, but cannot be updated. They are great for modeling views in SQL databases, and therefore in EF Core 3.0 you want to automate their creation.

  
  
  

• Property Bag Entities . This adds entities that store data not in normal properties, but in indexed ones, and can use instances of the same class in .NET (for example, something like Dictionary<string, object> ) to display many different types of entities in one the same EF Core model. This feature is another step on the way to full-fledged “many-to-many” relationships without the use of unifying entities - that is, one of the most expected features of EF Core.

  
  
  

• EF 6.3 on .NET Core . It is clear that now there are many applications that use EF, and porting them to EF Core only in order to get some advantages from using .NET Core sometimes requires a lot of effort. Therefore, we will adapt the next version of EF 6 to make it also work on .NET Core 3.0. This is done in order to encourage developers to port their applications so that at the same time they have to change as little code as possible. Of course, this will result in a number of restrictions (for example, new providers will be required and support for spatial data will not turn on for SQL Server). In addition, we do not plan to add any additional features to EF 6.

  
  
  

Conclusion

The EF team thanks the community for the quality feedback and development assistance that eventually led to the emergence of EF Core 2.2. As always, we remind you that new ishshui can be added directly to our tracker . Thank!

Don't forget that the DotNext tickets will go up from January 1st. Personal - for a thousand, and Standard - for two thousand. Details about Early Bird - on the site .