You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, this problem potentially has several causes, but it would be easy to fix (for now) by having CompareTo working properly:
I've implemented ExpandNode for EF7. It works fine, but because of the new implementation of .Include in EF7, it relies on being applied to the EntityQuery with the same type parameter as the entity. For some reason, when a Filter node is executed, it always changes the type parameter to "object". This wouldn't be a problem, except that it requires ExpandNode to execute first.
FilterNode has the following implementation of CompareTo:
public override int CompareTo(TreeNode other)
{
if (other is FilterNode)
{
return 0;
}
return -1;
}
Obviously this will result in a stable/consistent ordering only in trivial cases and in my particular case, FilterNode will always end up first regardless of the implementation of ExpandNode's CompareTo, which breaks ExpandNode.
So, first of all, it seems like the solution to the CompareTo is to give each node some sort of priority and sort by that.
Secondly, I've figured out how to preserve the types of the queries. This can be done by calling Queriable.CreateQuery in its generic form by reflection, since the non-generic form returns IQueriable. I'll create a pull request for this.
The text was updated successfully, but these errors were encountered:
So, this problem potentially has several causes, but it would be easy to fix (for now) by having CompareTo working properly:
I've implemented ExpandNode for EF7. It works fine, but because of the new implementation of .Include in EF7, it relies on being applied to the EntityQuery with the same type parameter as the entity. For some reason, when a Filter node is executed, it always changes the type parameter to "object". This wouldn't be a problem, except that it requires ExpandNode to execute first.
FilterNode has the following implementation of CompareTo:
Obviously this will result in a stable/consistent ordering only in trivial cases and in my particular case, FilterNode will always end up first regardless of the implementation of ExpandNode's CompareTo, which breaks ExpandNode.
So, first of all, it seems like the solution to the CompareTo is to give each node some sort of priority and sort by that.
Secondly, I've figured out how to preserve the types of the queries. This can be done by calling Queriable.CreateQuery in its generic form by reflection, since the non-generic form returns IQueriable. I'll create a pull request for this.
The text was updated successfully, but these errors were encountered: