-
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
Support for querying objects without keys #1862
Comments
(made some edits to the original issue to clarify exactly what this is and isn't about) |
I'm not sure where to add this, but a bulk of people utilized Inversion Of Control with Entity Framework. So wouldn't we want to be able to do:
In EF6 you supported the above, I know it currently doesn't. |
@GArrigotti this feature is exactly for the scenario you describe. Being able to pass in |
I love Ef7 and was wondering if you would reconsider adding the Raw Store Access of arbitrary types to the initial release It’s hard to imagine any complex app not needing this ability, every singly MVC app that I created in the past had many read-only view models that had subset of column selections from the entities; currently the workaround is to add them to the DbSet and give them fake keys if no keys are available This clutters the DbSets with unnecessary entries that don’t belong there, I can’t imagine I am the only one running into this issue for any relatively complex apps My preference would be to leave FromSql() as is and do something like DbContext.QueryRawSql() as mikary suggested |
Hello, Totally agree with @mikary and @Vasimovic. I've found a solution for this while reading the source code. Add this class to your project.
You may use your own query. It works for me.. |
Currently planned for 1.1 - see https://blogs.msdn.microsoft.com/dotnet/2016/07/29/entity-framework-core-1-1-plans/ for details. |
@davidbaxterbrowne that is a quite ingenious way to approach the problem! I suspect it is possible to avoid binding to provider methods in the OnConfiguring method and still get the caching, but not sure right now what the code looks like. That would make the solution very generic. |
@bbsimonbb From reading the examples and watching some of the video content, I think the QueryFirst approach is very interesting. Given that the main point we haven't addressed yet with EF Core is the amount of ceremony required to root a query on a new type, I suspect some customer in this thread won't like the idea of writing all their SQL queries in a separate file either. Code generation that depends on Visual Studio would also limit things. But QueryFirst still sounds like a cool .NET data access tool to have under your belt, if you can stick to that. It also seems it would provide value using it side-by-side with EF Core or Dapper, rather than as a replacement. Have you considered building it as an extension that integrates with them? For example, I can imagine borrowing configuration details from a DbContext to connect to the database and discover result schemas, similar to how our design-time tooling works. |
Oh, I don't want to change the DbContext file, I always keep it read only. because Scaffold-DbContext often be ran, any changes will miss. |
@davidbaxterbrowne super |
Is there an update to this for 3.0? |
I upgraded to 3.0. Using the solution at #1862 (comment), I am now getting the error "The best overload for the 'ExecuteReader' does not have parameter named 'parameterValues' Any suggestions on a work around for this? |
It seems like you can just create a
Note, I have not tested this running since I am in the middle of upgrading my application to 3.0, but it compiles at least... |
Update version of @davidbaxterbrowne code for EF Core 3:
|
What if use dapper for mapping executed stored procedure results
|
Code in davidbaxterbrowne comment causes
exception when NpgSql EF Core provider is used. It is posted in and https://stackoverflow.com/questions/66191043/how-to-use-npgsql-ef-provider-as-scoped-service |
This is also an option: #10365 (comment) |
Is there a compelling reason we shouldn't just write extension methods that call Allowing direct access to a |
While executing the SP in the middle of transaction I'm getting the below error. Please help me |
@DNLMurthy Please open a new issue and attach a small, runnable project or post a small, runnable code listing that reproduces what you are seeing so that we can investigate. |
Note: The feature tracked in this issue could help with using EF Core with database views. However, the feature is not limited to database views and its completion would not mean that every aspect of database view support has been implemented. See #827 for an overview of the areas where EF Core interacts with database views.
While the
FromSql()
method onDbSet<TEntity>
can already be used to bootstrap raw queries which through standard LINQ composition end up projecting arbitrary types (i.e. types that are not mapped in the model), the method requires those queries to be rooted on a mapped typeTEntity
.E.g. assuming Product is an entity type and ProductListEntry is just an arbitrary CLR type that is not mapped in the mode, this works:
But this doesn't:
This item was used initially to track the ability to produce results from raw queries which cannot be expressed as a transformation over a known
TEntity
and hence cannot be rooted on aDbSet<TEntity>
.In the end we decided to enable mapping "query types", latter renamed to "entities without keys" in the model, which allowed us to support a large portion of the important scenarios this was about. We are now using #10753 to track working with other non-scalar types without having to add them first to the model.
The text was updated successfully, but these errors were encountered: