tabs ↹ over ␣ ␣ ␣ spaces

by Jiří {x2} Činčura

Entity SQL and spatial data

22 Apr 2013 2 mins Entity Framework, Entity SQL, LINQ, Spatial data

When the Entity Framework was first introduced it came with (basically) two flavors of querying. LINQ to Entities and Entity SQL (ESQL). I’m not going to describe the history here. But as LINQ (any LINQ) gained popularity it was obvious, that LINQ to Entities is a future (though it had initially small deficit compared to Entity SQL). I even on my courses recommend using LINQ to Entities whenever possible and I’m also showing some dynamic querying where normally people start concatenating ESQL strings.

Recently Entity Framework added support for spatial data (and enums, …). All examples I’ve ever seen around spatial data and Entity Framework were using LINQ (obviously). Only few weeks ago I realized how the querying should work with Entity SQL. As it turned out spatial data are not first class citizen in Entity SQL world. There’s no literal for i.e. point. But canonical functions are here to save you. There’s a bunch of these spatial data related. What we’re looking for though is GeometryFromText/GeographyFromText. With these you can construct Geometry/Geography datatype from well-known text (WKT) and use it in query.

I’ve never used Entity SQL query in any real-world application I created. I’m too afraid of typos etc. But I did a lot of magic with expression trees. 😃 Wondering what percentage of people using Entity Framework is using Entity SQL and whether there are some scenarios that are crazy hard in LINQ…

Profile Picture Jiří Činčura is .NET, C# and Firebird expert. He focuses on data and business layers, language constructs, parallelism, databases and performance. For almost two decades he contributes to open-source, i.e. FirebirdClient. He works as a senior software engineer for Microsoft. Frequent speaker and blogger at