Efcore: DBQuery() is obsolete in EF core 3?

[amira133]

hello I want to know DBQuery() is obsoleted in EF core3?
beacuse Visual studio show a message that means DBQuery() is obsoleted!!!
if DBQury is obsoleted what we must used instead of it?

[ajcvickers]

@amira133 See the breaking change documentation here: https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-3.0/breaking-changes#query-types-are-consolidated-with-entity-types

[amira133]

Thanks @ajcvickers for your answer.
As I realized , DBSet() should be used instead of DBQuery().
But in DBSet() we must define a primary key , although in DBQuery() we did'nt need to define a primary key ,So how can I prevent from this problem?
please see my whole problem in here.

[ajcvickers]

@amira133 As it says in the link to the breaking change documentation I posted above, use ModelBuilder.Entity<MyEntity>().HasNoKey().

I would be interested to understand why that wasn't clear from the breaking change documentation? We work hard to make it easy to understand, so if there is something confusing about it, then it would be good to get that feedback.

[amira133]

Thanks @ajcvickers my problem soved!
for your question : we need some example behind breaking change documentation.

[ajcvickers]

@amira133 What kind of example would be helpful? Can you show the code you would have liked to see?

[Davilink]

I used the DbQuery to indicate that the query was coming from a view, that way it's clear that we can only read data from that Entity, reverting to a DbSet isn't that breaking that purpose ?

[ajcvickers]

@amira133 A DbSet for an entity type that is configured with HasNoKey is functionally equivalent to a DbQuery.

[Davilink]

@ajcvickers Yes but will the intellisense will show you that you cannot Create/Update/Delete that entity ?

[danobri]

In 3.0, when using the code first approach, how do you define a view _with_ a key? The problem I am running into is that Add-Migration is creating a table that mirrors my view.

[ErikEJ]

A view with a key is a table! Remove it from the migration by hand.

[danobri]

Although my view contains a logical key, I guess there is no need to define that in EF, and by defining a key I am triggering EF to generate a table and primary key. So I removed the [Key] attribute from the class, and added the .HasNoKey() call, which solves the problem. Definitely wouldn't want to manually alter every migration!

[Davilink]

I used the DbQuery to indicate that the query was coming from a view, that way it's clear that we can only read data from that Entity, reverting to a DbSet isn't that breaking that purpose ?

Is it an another way to clearly expose the readonly behavior ?

[MuhAssar]

for future readers, if adding .HasNoKey() didn't prevent the CodeFirst migration from creating a table for that view, try adding the following:
modelBuilder.Entity<User>().ToView("Users").HasNoKey()

as in my situation the migration kept creating a table for the view and using ToView fixed it

[loganmarshall1]

If you use efcore cli to scaffold from existing db it overwrites the on model building event. So we keep dbQuery in separate partial class works great.

Unfortunately we can't upgrade to 3.0 without a solution.

[zboyles]

As @abuassar mentioned, using ToView stoped the keyless table being created. I use ToView(nameof(DbSetName)) for flexibility.

modelBuilder.Entity().ToView(nameof(Users)).HasNoKey();

[craigmoliver]

@amira133 As it says in the link to the breaking change documentation I posted above, use ModelBuilder.Entity<MyEntity>().HasNoKey().

I would be interested to understand why that wasn't clear from the breaking change documentation? We work hard to make it easy to understand, so if there is something confusing about it, then it would be good to get that feedback.

I would have been helpful if you had documented "a = b":

modelBuilder.Query(); = modelBuilder.Entity().HasNoKey();

[paulirwin]

This is an unfortunate change from a design standpoint. I really liked the single responsibility aspect of DbQuery. It prevented adding or removing items from the set/query (making a view or table read-only) in a clean and understandable way. It's a "query", not a "set". Perfectly named.

I do not agree with the justification in the breaking changes document. If you were "confused" about this, EF Core 3.0 could have _also_ supported using DbSet with HasNoKey. To deprecate DbQuery (which prevents addition/removal of items) to solve "confusion" in this regard, which implies throwing away the investment in this feature in a future release, does not follow logically. Please un-deprecate this type and continue to support it _in addition to_ the HasNoKey approach.

[ajcvickers]

@paulirwin The problem with that is that everything gets duplicated when there is only a single very specific semantic change in the model. Literally the only thing that a DbQuery is is a DbSet for an entity type without a key. For example, it's perfectly reasonable to have a DbSet with a key that is read-only. Some things, like being read-only, are implied when there is no key, but that doesn't mean that removing the key is the right way to make a DbSet read-only. The same with mapping to a view, or excluding it from migrations. There are correlations in behavior here, but these things are not inherently coupled to entity types without keys.

[clockwiseq]

I've read through this issue because I ran into this same issue where I am curious as to why we're removing DbQuery. When I'm grabbing data from another SQL Database, I use a DbContext so EF can do all of the connection magic for me. I use DbQuery to map between a stored procedure or view in a separate database and a partial entity model. This works beautifully and I'm not quite sure how I'll do it now without using the ModelBuilder to specify HasNoKey. An attribute for this would great.

[loganmarshall1]

Agreed, us too for mapping DTOs to SPs, even though all our solutions are dotnet core 3.1, our efcore nuget sadly (perhaps indefinitely) remains 2.6

Logan

On Dec 18, 2019, at 8:48 AM, clockwiseq [e-mail] wrote:



I've read through this issue because I ran into this same issue where I am curious as to why we're removing DbQuery. When I'm grabbing data from another SQL Database, I use a DbContext so EF can do all of the connection magic for me. I use DbQuery to map between a stored procedure or view in a separate database and a partial entity model. This works beautifully and I'm not quite sure how I'll do it now without using the ModelBuilder to specify HasNoKey. An attribute for this would great.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/EntityFrameworkCore/issues/15656?email_source=notifications&email_token=AEYSEODWR6C5P7IPN2YX44LQZISY7A5CNFSM4HLSSGO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHGFDMA#issuecomment-567038384, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEYSEOBXYKIN4X7NBEM2XNTQZISY7ANCNFSM4HLSSGOQ.

[Joehannus]

Why was this issue closed? We are using DqQuery too for views. And we'd have to make a lot of breaking changes to a database that has been in production for more than one year. This breaking change is not acceptable.

Also - we don't use the modelbuilder for our migrations, so we don't have a solution for this in our .net core web api. based upon entity framework core (e.g. using modelBuilder.Entity().HasNoKey();). We have a separate application for master data management, based upon DevExpress XAF and asp.net web forms which uses Entiry Framework (using the normal .net framework). In other words we use regular Entity Framework for our Migrations.

Because we have a hybrid approach in which we use regular Entity Framework together with Entiry Framework Core (using DbQuery only in EF Core) this is quite the breaking issue for us.

[loganmarshall1]

Completely agree!
From: Joehannus [e-mail]
Sent: January 6, 2020 8:09 AM
To: aspnet/EntityFrameworkCore [e-mail]
Cc: Logan Marshall [e-mail]; Comment [e-mail]
Subject: Re: [aspnet/EntityFrameworkCore] DBQuery() is obsolete in EF core 3? (#15656)

Why was this issue closed? We are using DqQuery too for views. And we'd have to make a lot of breaking changes to a database that has been in production for more than one year. This breaking change is not acceptable.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/EntityFrameworkCore/issues/15656?email_source=notifications&email_token=AEYSEOGLYFG7D6765AKMMTTQ4MUOJA5CNFSM4HLSSGO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFMPQI#issuecomment-571131841, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEYSEOGPOWTAMJLC4PWPYRTQ4MUOJANCNFSM4HLSSGOQ.

[Joehannus]

Completely agree! From: Joehannus [e-mail] Sent: January 6, 2020 8:09 AM To: aspnet/EntityFrameworkCore [e-mail] Cc: Logan Marshall [e-mail]; Comment [e-mail] Subject: Re: [aspnet/EntityFrameworkCore] DBQuery() is obsolete in EF core 3? (#15656) Why was this issue closed? We are using DqQuery too for views. And we'd have to make a lot of breaking changes to a database that has been in production for more than one year. This breaking change is not acceptable. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#15656?email_source=notifications&email_token=AEYSEOGLYFG7D6765AKMMTTQ4MUOJA5CNFSM4HLSSGO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFMPQI#issuecomment-571131841>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEYSEOGPOWTAMJLC4PWPYRTQ4MUOJANCNFSM4HLSSGOQ.

I opened a new issue for this (#19509)