EF6 VS EF Core inheritance

Lost some time with this subtle gotcha, so maybe this will help you spare time.

In EF6 you can configure inheritance with a single type.

An inheritance hierarchy with a single type might seem pointless, but I saw this get used to automatically filter data, which I found pretty clever (to ignore records marked as deleted, the discriminator column was used to only map records with deleted set to false)

Say you want to map SomeEntity only to rows that have value “SomeEntityType” in the field Discriminator:

public class SomeContext : DbContext
{
   protected override void OnModelCreating(DbModelBuilder modelBuilder)
   {
      modelBuilder.Entity<SomeEntity>()
         .Map(m => m.Requires("Discriminator")
            .HasValue("SomeEntityType")
         );
   }
}

Now, transporting the EF6 implementation as is to EF Core syntax won’t work:

// EF Core: incorrect
modelBuilder.Entity<SomeEntity>()
   .HasDiscriminator<string>("Discriminator")
   .HasValue<SomeEntity>("SomeEntityType");

However the gotcha is, that it won’t work, but it won’t crash or warn you either. It will just return all SomeEntities, ignoring the discriminator. Nothing gets added to the WHERE clause in the generated T-SQL.

I spend some time troubleshooting this, until I carefully read the docs again:

EF will only setup inheritance if two or more inherited types are explicitly included in the model

https://docs.microsoft.com/en-us/ef/core/modeling/inheritance

So in the incorrect mapping, the base type gets setup but nothing else, so no discriminator gets applied (it just ignores the faulty configuration apparently).

You actually need have a separate base and derived type, and map them accordingly, like so:

// EF Core: correct
modelBuilder.Entity<SomeEntityBase>()
   .HasDiscriminator<string>("Discriminator")
   .HasValue<SomeEntityBase>("NotSomeEntityType")
   .HasValue<SomeEntity>("SomeEntityType");

A bit more verbose, but in normal inheritance scenarios you would have had the base type anyway.

Theme music for this blog post

Advertisements
EF6 VS EF Core inheritance

SQL-92 ‘Til Infinity

Think you know SQL, then take this quick quiz at windowfunctions.com

It’s a lovely part quiz (10 questions), part tutorial experience, that will surely teach you a thing or two (or nine in my case, after the first question I was lost already)

If you’re anything like me, coming from a developer perspective, you can get your SQL-92 on, but anything a bit more smart or analytical gets complicated quickly.

You heard of  the OVER clause, but do your best to avoid needing it, right.
Or you think these SQL Server analytic functions and ranking functions have just been released. Well, this straightforward quiz made me finally “get” some of the basics and made the whole deal less intimidating, recommended.

Theme music for this blog post

SQL-92 ‘Til Infinity

Multi Model SQL Server

Graph database

SQL Server is introducing graph support. What I find great, is that you can mix it in your traditional relation database, so there’s no big to-SQL or NoSQL decision necessary.

This makes graphs a very feasible option in Microsoft (eco)systems, since you can start using this transparently to your IT infrastructure/department. Standard SQL Server operation and maintenance┬á procedures apply, no need to go through the pains of introducing an “exotic” to them database which noone has any experience running in production.

Document store

That’s in SQL Server 2017, what I totally missed in 2016 though, is the built-in JSON support. And I thought Marten was unique for .NET with its approach of exploiting the JSON support in Postgresql, to create a robust document store.

NoSQL – No SQL Server Marketing

I don’t have any experience with the graph or JSON support in SQL Server yet, so I might be missing something. And I’m sure a pure bred NoSQL product can go an extra mile or more. But I get the impression SQL Server responded to the NoSQL hype, and then didn’t really sell its new features to .NET developers.

Just last month at work, we were still discussing MongoDB to store documents and weighing whether taking on a new database technology in a Microsoft shop would be worth it, and we didn’t even consider SQL Server as a document option!

Obviously you can always build your own solution in SQL Server, but who has the time for that.

Now Cosmos DB markets itself as the all-in-one database for the cloud, but on-premise it looks like SQL Server will still get you from A to B.

Theme music for this blog post

 

Multi Model SQL Server