Skip to content
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

TreeNode CompareTo is flakey / Type parameters change unnecessarily #55

Open
cherrydev opened this issue Mar 5, 2015 · 1 comment
Open

Comments

@cherrydev
Copy link

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.

@cherrydev
Copy link
Author

Pull request here:
#57

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

No branches or pull requests

1 participant