Skip to content

Conversation

bahusoid
Copy link
Member

@bahusoid bahusoid commented Jul 11, 2023

Fixes #3352
Annoyingly, it’s caused by my non-regression fix #3320. On the bright side, it uncovered a few flaws in the current Fetch implementation which I plan to fix in 5.5
Apart from regression it fixes broken in 5.3 fetching lazy properties from base unmapped class.

resultOperator.RelationMember.ReflectedType.FullName).FirstOrDefault();
if (!string.IsNullOrEmpty(entityName))
foreach (var entityName in queryModelVisitor.VisitorParameters.SessionFactory
.GetImplementors(resultOperator.RelationMember.ReflectedType.FullName))
Copy link
Member Author

@bahusoid bahusoid Jul 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main problem with resultOperator.RelationMember.ReflectedType that we don't know the actual entity type. Only declaring type of fetched property (which is not equal to entity type if this property is from some base class). That's why we need to check all implementors.

Ideally, we should retrieve entity from query source (my plan for 5.5)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main problem here that we don't know the actual entity type.

Actually we do. It is in query source as you've said.

@hazzik
Copy link
Member

hazzik commented Jul 11, 2023

Btw, querySource resolved at the top of the file is incorrect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants