On one of my projects we are using Entity Framework Core. Although my experience on combining Entity Framework Core and SQL Server was quite OK, I couldn’t say the same thing when using the Entity Framework Core drivers for PostgreSQL(https://www.npgsql.org/efcore/index.html).
Although you get the impression that everything works, the moment you have a look at the logs you see 2 obvious issues:
- For a lot of LINQ statements the driver cannot correctly translate it to a working SQL statement. So what happens is that everything is loaded in memory and the expression is executed on the in-memory collection. The only way to discover this is through the logs where you see a warning when the driver couldn’t translate your LINQ statement. If you didn’t check the logs, you aren’t even aware of the issue.
- The generated SQL statements are far from optimal. For example every time you add an include an extra correlated subquery is generated which turns out to be quite slow on PostgreSQL.
In our situation I can add another issue on the list as we were using some GIS features through NetTopologySuite. Problem there was that our (simple?) use case wasn’t supported. In our use case we have a set of buildings stored in our database. Every building has a location and we wanted to return all buildings within a certain bounding box to show them on a map. We couldn’t get this working through the LINQ integration and had to fallback to raw SQL.
I’m happy to see that the driver is evolving but I thought it would be a good time to give NHibernate a try. (But that is for another blog post).
PS: I also don’t like that the EF Core driver uses Pascal casing to generate the database, columns, … This is really annoying as PostgreSQL is case sensitive and requires that you escape all names when they aren’t lowercase…