Uh oh!
There was an error while loading. Please reload this page.
Add support for INCLUDE clause in indexes - #699
Conversation
d3e848a to
38f4885CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
austindrenski
left a comment
There was a problem hiding this comment.
A few inline comments, but looks good so far.
One note is that if we do change the naming, we need to make sure it's consistent throughout the PR.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
roji
left a comment
There was a problem hiding this comment.
Looks good from my side, but let's see what the others think.
Are you planning to work on scaffolding support for this as well? It would be nice to release full support for this feature at the same time. If so, let's include it in this PR, otherwise can you please open a separate issue to track? Maybe I'll take a stab at it.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
khellang
commented
Nov 15, 2018
I'll address PR feedback and add XML comments tonight, then you can have a final review pass 👍🏻 |
khellang
commented
Nov 15, 2018
We punted on it for #662. Maybe we can create an issue and tackle both at the same time? You probably need to dig into some of the same metadata anyway. |
austindrenski
commented
Nov 15, 2018
khellang
commented
Nov 15, 2018
I think we're mostly there. The only unresolved issue, as far as I can see, is whether we should do a |
khellang
commented
Nov 15, 2018
Filed #704 for scaffolding support. |
khellang
commented
Nov 15, 2018
I have a PR lined up for fixing #326 once this is merged 😄 |
Ah OK, understood. EDIT: Just saw #704 for the scaffolding support, thanks! |
I added an Npgsql-specific method to return a generic According to dotnet/efcore#4846 (comment), we might be able to obsolete it once 3.0 ships with an official
It's being tracked by dotnet/efcore#12366 |
austindrenski
commented
Nov 15, 2018
@khellang wrote:
Per the inline discussion above, no need to add the check. It would indeed introduce a bit too much hidden magic without adding much in value terms. @khellang wrote:
Nice! |
austindrenski
left a comment
There was a problem hiding this comment.
The implementation looks good. Just some nits in the XML docs
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| .Append(IndexColumnList(operation.Columns, operators)) | ||
| .Append(")"); | ||
| if (!string.IsNullOrEmpty(operation.Filter)) |
There was a problem hiding this comment.
@roji hi,
I don't know why this 'Where' is deleted but i can't add a filter for my all indexes. I need to add this index filter; 'is_deleted is FALSE' just because i am using soft delete with unique indexes. Any idea?
There was a problem hiding this comment.
INCLUDE isn't the same as the WHERE option. The feature which @khellang added supports the first one to improve read performance (the specified columns are included into the index, but not participate in ordering; this allows to take values only from one table called an index table without joining to the original table).
There was a problem hiding this comment.
@suadev It's deleted because it's using the overriden IndexOptions method, with a call to base.IndexOptions below.
If you take a look at the base class (in EF Core), you can see that it's still adding the WHERE clause if there's a filter specified:
There was a problem hiding this comment.
To add to what @YohDeadfall wrote, the WHERE support wasn't deleted - it was simply moved into EF Core itself (see MigrationsSqlGenerator).
Are you seeing an actual issue with it not working? If so, please open a new issue with a code sample so we can investigate.
There was a problem hiding this comment.
You may need to look at this: https://docs.microsoft.com/en-us/ef/core/miscellaneous/configuring-dbcontext#design-time-dbcontext-configuration
There was a problem hiding this comment.
@roji thanks, but i didn't get it. I am still not sure what is my mistake. Overriding IndexOptions method is not a correct way?
There was a problem hiding this comment.
You could also try to just modify the model itself, instead of swapping components? I.e.
protectedoverridevoidOnModelCreating(ModelBuildermodelBuilder){foreach(varentityinmodelBuilder.Model.GetEntityTypes()){foreach(varindexinentity.GetDeclaredIndexes()){if(index.IsUnique){index.SetFilter("is_deleted is FALSE");}}}}There was a problem hiding this comment.
@khellang thank you! i am not even aware of GetDeclaredIndexes() method !
There was a problem hiding this comment.
Changing the model is definitely a better approach than replacing services, wherever it's possible.
Closes#697