Pack of doc changes for SQL queries #4042
Conversation
|
|
||
| [!code-csharp[Main](../../../samples/core/Querying/SqlQueries/Program.cs#FromSqlAsNoTracking)] | ||
|
|
||
| ## Querying primitive (non-entity) types |
|
|
||
| This code doesn't work, since database do not allow parameterizing column names (or any other part of the schema). | ||
|
|
||
| First, carefully consider whether you really want to fully parameterize the column name. For example, users may choose a column that isn't indexed, making the query run extremely slowly and overload your database. Except for truly dynamic scenarios, it's usually better to have two SQL queries for two column names, rather than using parameterization to collapse them into a single SQL query. |
There was a problem hiding this comment.
Not sure this really belongs here; the same is true when using the more common LINQ method builder to choose a property dynamically. I.e. it's not a consequence of using raw SQL. But I don't feel strongly.
There was a problem hiding this comment.
It's true that you have the same consideration with EF.Property - assuming you pass it arbitrary input, and not a fixed string (e.g. because of a shadow property - which I think is what it's usually used for).
The idea here was to make the user fully understand what it is they're doing when they interpolate a fully dynamic column name into their SQL (and possibly dissuade them from it, unless it's really required)... I do agree that a similar note could be a good idea for EF.Property as well.
I still think it's not a bad fit here to help "overall understanding/context", but can remove if people are against it.
There was a problem hiding this comment.
Revised this section to make it clear that it's a general note on dynamic queries rather than specific to SQL queries.
|
|
||
| First, carefully consider whether you really want to fully parameterize the column name. For example, users may choose a column that isn't indexed, making the query run extremely slowly and overload your database. Except for truly dynamic scenarios, it's usually better to have two SQL queries for two column names, rather than using parameterization to collapse them into a single SQL query. | ||
|
|
||
| If you've decided you do want to use parameterization, you'll have to use <xref:Microsoft.EntityFrameworkCore.RelationalQueryableExtensions.FromSqlRaw%2A>, which allows interpolating variable data directly into the SQL string, instead of using a database parameter: |
There was a problem hiding this comment.
I don't think this is true. Using Where(e => EF.Property<object>(thePropertyName) == x) is a better way of doing this.
There was a problem hiding this comment.
Oh sure, the idea was "if you've decided to use parameterization and have to do SQL as opposed to LINQ" (somewhat implied in the page context). I'll amend to make sure this is clearer.
There was a problem hiding this comment.
But people might think that the only way to do this is with raw SQL.
There was a problem hiding this comment.
Tweaked the wording to make it clear that we're discussing dynamic construction only in the SQL context.
|
/azp run |
|
No pipelines are associated with this pull request. |
* Rename "raw SQL" to "SQL queries" * Switch to showing the new `FromSql` by default. * Clearly document FromSqlRaw as appropriate only for dynamic SQL scenarios. * Document SqlQuery * Document ExecuteSql Closes dotnet#3971 Closes dotnet#4041 Closes dotnet#1787
FromSqlby default.Closes #3971
Closes #4041
Closes #1787