Why so many limitations on the usage of QueryType?

[milanc]

Hi

First to thank you for another release of EF core and your hard work on constant improvements of it.

When I heard about this new feature of query types I was hoping that it will be something to make easier building of a read only (query) contexts for CQRS pattern.

In order to achieve better performance for query stack I am creating db context with entity sets behind properties that are using AsNoTracking(); on top of 'DbSet`.
Also to prevent misuse this db context I have overrides on context's save methods to make sure that developers wouldn't use it for writing to db.

I was hoping that with DbQuery<T> we would get same/better behavior (no tracking, no modification) and it would not require work that I am doing now.
But current limitations that I see in documentation:

Only support a subset of navigation mapping capabilities - Specifically:
They may never act as the principal end of a relationship.
They can only contain reference navigation properties pointing to entities.
Entities cannot contain navigation properties to query types

are not helping in this scenario.

I am probably missing something, but if parent and its navigation properties are both intended to be readonly I see no reason for these restrictions.

Also, would it make sense to have a possibility to mark entire context as read only (or maybe have specialized read only context type)?

[Suchiman]

Query types were designed for entities that do not have primary keys. Entities without primary key are by nature readonly as EF cannot locate them (locating an entity is done via PK) and they cannot act as the principal end of a relationship because for that they would need a PK.
DbQuery and its restrictions were designed for entities without PK, not for readonly entities, that's just a side effect.
If you want to make a context readonly, just override its SaveChanges method to throw and set ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking; from the constructor to make NoTracking the default.

[milanc]

Hi @Suchiman, thank you for your response.
From documentation I understood what is the intention for DbQuery, but also I am just wondering why there would not be some simpler way to make readonly entities/contexts.

As I've mentioned, I was doing things you are suggesting to achieve readonly context, this is my constructor

this.ChangeTracker.AutoDetectChangesEnabled = false;
this.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;

and in save methods I am throwing exceptions.

I know that I can solve this by creating custom context base but instead overriding save methods and tweaking change tracker in constructor it would be nice to have this feature out of the box.

[ajcvickers]

@milanc Read-only entity types are tracked by #7586.

[milanc]

Thank you @ajcvickers.

[Vasim-DigitalNexus]

@Suchiman, re "Query types were designed for entities that do not have primary keys."

This is not always the case; all my query types have primary keys, they are subsets of read-only views or results from stored procedures that have multiple joins

EF 6 had the ability to map any query to a type with or without keys, EF Core has the DbQuery rooted in the DbSet, I have to agree with @milanc; if all I want to do is map results to a read-only type why not make that more straightforward for those cases - my 2 cents

[ajcvickers]

@Vasimovic This is a true statement: "Query types were designed for entities that do not have primary keys." It is certainly possible to use query types in some other scenarios, but their primary purpose is to support querying without keys.

[Vasim-DigitalNexus]

@ajcvickers, I understand. I was just pointing out that I have no choice but to use the DbQuery for my case, it seems like since day one I was missing the ability to do simple mapping to arbitrary types #1862, and the DbQuery is the closest thing I can use, I have hundreds of read-only only views, and I am sure others do too. In EF 6 this was trivial dc.Database.SqlQuery<T>

I hope I don't sound like I am complaining, EF Core is great and I appreciate the insane amount of work you all have done