-
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
Query: Full support for entity splitting #29062
Conversation
bb72359
to
bf10425
Compare
@@ -91,7 +91,13 @@ public static IEnumerable<IProperty> GetNonPrincipalSharedNonPkProperties(this I | |||
continue; | |||
} | |||
|
|||
var propertyMappings = table.FindColumn(property)!.PropertyMappings; | |||
var column = table.FindColumn(property); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wrt #29079
This currently considers only properties stored in main fragment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, see minor nits/suggestions - nothing that can't be handled later.
AssertSql( | ||
@"SELECT [e].[Id], [s0].[IntValue3], [s0].[StringValue3] | ||
FROM [EntityOne] AS [e] | ||
INNER JOIN [SplitEntityOnePart2] AS [s0] ON [e].[Id] = [s0].[Id]"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we improve this in the future by only querying SplitEntityOnePart2, given that all the information is there? If so, should we file an issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can potentially improve. Though need to keep in mind optional dependents and optional fragments if we do that in future. #29035 could also alleviate this in a different way (like how we don't have any extra table for TPC selected)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filed #29113
Added notes there.
[NotMapped] | ||
public OwnedReference OwnedReference { get; set; } | ||
[NotMapped] | ||
public List<OwnedCollection> OwnedCollection { get; set; } = new List<OwnedCollection>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: target-typed new (here and below)
mb.Entity<EntityOne>( | ||
b => | ||
{ | ||
b.ToTable("EntityOnes"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly not needed?
LEFT JOIN [OwnedReferencePart3] AS [o0] ON [b].[Id] = [o0].[LeafEntityId]"); | ||
} | ||
|
||
public override async Task Tpt_entity_owning_a_split_reference_on_leaf_with_table_sharing(bool async) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly add test coverage querying an unrelated sibling, to make sure the owned fields/tables aren't queries (for the multiple scenarios here, TPH/TPT/TPC)
SELECT [l0].[Id], [l0].[BaseValue], [l0].[MiddleValue], [l0].[LeafValue], N'LeafEntity' AS [Discriminator] | ||
FROM [LeafEntity] AS [l0] | ||
) AS [t] | ||
LEFT JOIN [LeafEntity] AS [l] ON [t].[Id] = [l].[Id] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this 2nd join on LeafEntity needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we are selecting owned entity columns from this table which is also inside the TPC, so either we generate join or we inject inside TPC null columns for every other type and non-null for the leaf type owning the entity.
LEFT JOIN [OwnedReferencePart3] AS [o0] ON [l].[Id] = [o0].[LeafEntityId]"); | ||
} | ||
|
||
public override async Task Tpc_entity_owning_a_split_reference_on_leaf_with_table_sharing(bool async) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it intentional that we don't have the corresponding tests on middle/base like TPH/TPT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In TPC, an entity type can only have owned entity with table sharing for leaf entities.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah OK, was not aware. Can still add those tests and assert failure for the day when we do implement TPC+owned on non-leaf (do we have any issue?). But obviously not very important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are model validation tests for it. I think if we remove that exception @AndriySvyryd would remind us to add query support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt we'll ever support it. Table splitting on non-leaves in TPC would require the columns to exist on all derived tables as well, which doesn't sound that useful considering the complexity of implementation.
EntityProjectionExpression entityProjectionExpression, | ||
ITableBase targetTable, | ||
INavigation navigation) | ||
if (navigation.IsCollection) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make sure - this is relevant even when targetEntityType.IsMappedToJson()? (because it's not in an else clause)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JSON shouldn't reach here. I think the innerShaper
being not null condition above is not needed since for JSON we always add shaper in advance. I will update code there to make it clearer.
@@ -1510,7 +1511,7 @@ Expression CopyProjectionToOuter(SelectExpression innerSelectExpression, Express | |||
return innerShaperExpression; | |||
} | |||
} | |||
|
|||
else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can remove an unindent the following (I'd add a comment either way since this function is huge and it's easy to lose track of which scenario we're in)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
variable name clash is I think the reason it remained this way in code cleanup.
// Either we encountered a custom table source or dependent is not sharing table | ||
// In either case we need to generate join to owner | ||
var ownerJoinColumns = new List<ColumnExpression>(); | ||
var owenrTableReferenceExpression = selectExpression._tableReferences[baseTableIndex]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
var owenrTableReferenceExpression = selectExpression._tableReferences[baseTableIndex]; | |
var ownerTableReferenceExpression = selectExpression._tableReferences[baseTableIndex]; |
} | ||
|
||
if (unwrappedTable is SelectExpression subquery) | ||
// Either we encountered a custom table source or dependent is not sharing table |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure, but seems like there may be some DRY potential between the code below and above, can improve later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered it but it was causing a lot of complexity in readability. I think at this point there are 2 major things which are kind of duplicated - adding join to other split tables and populating properties.
Join has difference in terms of finding existing table and populating properties eventually would be different from column sharing perspective in what nullability they get.
Plus adding join also populate some variables to be used later so if we move that to a method for DRY, we need to pass states around.
Feel free to change code if you can refactor it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filed #29115
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I saw it wasn't a straightforward DRY. If we can make it better somehow, great, but definitely not a good idea to make it significantly more complex with state just to DRY.
bf10425
to
b6e5a30
Compare
b6e5a30
to
8f20257
Compare
Resolves #620