-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring back DbQuery<T> #18719
Comments
@Neme12 We appreciate the feedback, but I think we are going in the correct direction here. A query type was simply an entity type without a key defined. It could be mapped to a table, or to a view, or not to anything at all. All three of these possible mappings are also valid for entity types with keys. So Migrations working differently just because a type doesn't have a key led to a lot of confusion about what query types really were. See #17270 The second part of this, which we unfortunately not able to get to for 3.0, is a general mechanism to avoid creating database artifacts for any part of the model.
What is the reason you need to DbSet properties for these types on your DbContext? |
Want to add a scenario which worked before but broke when upgrading to EF Core 3.0: We created a partial dbContext which is completely separated from the generated context (we use database first and scaffolding). We collect all DbQuery's for the raw sql queriers in the manually created context. DbSet forces us to add HasNoKey to them but we can't override OnModelCreating since it's allready overriden in the generated context. Is there any soulotion to this? |
@loth0 Why doesn't the generated context use |
@loth0 just implement the OnModelCreating partial method, and make any changes there. |
@ajcvickers That would mean I'd have to modify the generated context each time I scaffold, which kinda defeats the purpose of a manually handled partial context, separated from the autogenerated context. I allready have to modify it (because of the default OnConfiguring generation) but the more modifications I have to do after each scaffolding the less convinient it gets. @ErikEJ I don't follow, the OnModelCreating method is allready implemented in the generated context, I can't implement it in the manually created context too. |
@ErikEJ Sorry my bad, now I found that a OnModelCreatingPartial method is generated, that one does the trick, thanks a lot! |
We don't. I think the author wrote it that way to avoid having to use fluent configuration (which we now have to use anyway to prevent EF Core from trying to create a table for it but at the same time be able to use it in |
I still think it would be useful to have a separate data type for a set of keyless entities as opposed to |
@ajcvickers What about creating a new attribute then that would mark an entity as not being mapped to a table or anything in the database, similar to how there's an |
@Neme12 Thanks for the feedback.
That's basically why we created the new type originally. However, it quickly became very apparent that understanding the difference between I added a note to #2725 about the attribute. |
Hi there, I wanted to add a vote related to a point made in @Neme12 latest comment, which is to have some way for the compiler to understand that on a DbSet for a keyless entity, Find won't work. Currently that throws at run time. Is it technically possible? I didn't see an issue for it and am happy to add one explicitly if it's useful to track. Thanks |
@julielerman Can you explain what you mean by, "the compiler to understand?" |
Oh sorry for lack of clarity.
which doesn't make sense but let's say it's a mistake from habit...it will compile and run but throw an exception at runtime when EF Core tries to work out the query. Not in front of my computer so can't give an example. Hopefully that's enough. |
@julielerman We discussed this and we're wondering if just using |
I'm following this thread and the exchange between @Neme12 and @ajcvickers, but I don't understand this part. Is the DbSet property still (in .net core 3.1) required if we are using .FromSql()? I am still using FromSql, so I'll still need the DbSet item, and .HasNoKey() and .ToView(null), right? I created a Stack Overflow Question about this. |
In EF Core 2.2, we used a query type similar to this (notice the
Id
property):that wasn't mapped to anything - not a table, not a view. We only used it with
FromSql()
. In our DbContext we had:After upgrading to EF Core 3.0, I see that
DbQuery
is marked as obsolete, suggesting the use ofDbSet
instead. I was a little confused, because - how will EF Core then be able to tell that this isn't actually supposed to be an entity... only a query type? And of course after running this, EF Core suddenly treated it as an entity and wanted to create a table forRecords
.I saw a suggestion to mitigate this by configuring the type using
HasNoKey()
. That didn't work. EF Core still wanted to create a table for it. So I tried a few other things - callingToTable(null)
since we don't want a table, but that threw an exception. Eventually I tried usingToView
(even though we don't want to map this to any view) and callingToView(null)
finally did the trick.My question is: why the deprecation of
DbQuery<T>
?The docs says:
In my opinion, the previous behavior was really clear and unambiguous - in our
DbContext
, we hadDbSet<T>
andDbQuery<T>
properties. You could immediately see what was an actual entity mapped to a table in the database (DbSet
) and what was not (DbQuery
).Now, I can't tell by looking at the
DbContext
itself. Instead of a simple change in the type of a property, I have to add additional configuration for the type to prevent it from being treated as an entity and mapped to a table, in a way that's not intuitive at all. I find the current state much more confusing than before.The text was updated successfully, but these errors were encountered: