Query: Full support for entity splitting#29062
Conversation
bb72359 to
bf10425
Compare
| } | ||
|
|
||
| var propertyMappings = table.FindColumn(property)!.PropertyMappings; | ||
| var column = table.FindColumn(property); |
There was a problem hiding this comment.
wrt #29079
This currently considers only properties stored in main fragment.
roji
left a comment
There was a problem hiding this comment.
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.
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.
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)
| [NotMapped] | ||
| public OwnedReference OwnedReference { get; set; } | ||
| [NotMapped] | ||
| public List<OwnedCollection> OwnedCollection { get; set; } = new List<OwnedCollection>(); |
There was a problem hiding this comment.
nit: target-typed new (here and below)
| mb.Entity<EntityOne>( | ||
| b => | ||
| { | ||
| b.ToTable("EntityOnes"); |
| 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.
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.
Is this 2nd join on LeafEntity needed?
There was a problem hiding this comment.
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.
Is it intentional that we don't have the corresponding tests on middle/base like TPH/TPT?
There was a problem hiding this comment.
In TPC, an entity type can only have owned entity with table sharing for leaf entities.
There was a problem hiding this comment.
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.
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.
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.
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.
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.
| } | ||
| } | ||
|
|
||
| else |
There was a problem hiding this comment.
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.
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.
| 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.
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.
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.
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