Filter does not work with property with ComplexType

[tdhung80]

Hi,

I got an exception on this case. I have debugged, I see the method below does not return a proper column for a property of ComplexType.

  private static string ParseColumnNameFromExpression(LambdaExpression expression)
        {
            if (expression == null)
                throw new ArgumentNullException("Lambda expression is null");

            var body = expression.Body as MemberExpression;
            if ((body == null) || (body.Member == null) || string.IsNullOrEmpty(body.Member.Name))
            {
                //  The expression does not specify a column - it's a lambda expression/predicate that will need to
                //  be expanded by LabdaToDbExprssionVisitor during the query evaluation.
                return null;
            }

            var propertyExpression = body.Expression as MemberExpression;
            if ((propertyExpression != null) && (propertyExpression.Member != null) && (propertyExpression.Member.Name != body.Member.Name))
            {
                //  The expression is a property accessor - i.e. field.HasValue.  It's a lambda expression/predicate
                return null; // <== __problem at this line__
            }

            return body.Member.Name;
        }

Cheers,
Hung Tran

[jcachat]

Complex Types are not supported at the moment. I'll take a look at this for a future update.

[NickStrupat]

I am also running into this issue, but from a different situation. Has there been any work on solving this yet? I'm happy to help.

[jcachat]

Sorry, no. I've been crushed by work lately and haven't had time. I may try to find some time in the next few days to give it a shot. But if you want to take a stab at it, I'd be happy to accept any help.

This may be a difficult change though. I don't think the code shown above is the only place affected. That will only fix the non-lambda expression filters. Maybe that's the "different situation" you are hitting?

And figuring out the correct database column name might be tricky too if it's been mapped to a name other than EF's default of "[type]_[prop]".

[NickStrupat]

I took a peek last night and started tinkering with some changes. I'll likely spend some more time this weekend.

Does the library already figure out the correct database column names for properties? In other words, if a non-default naming convention is used, does this library work correctly? My situation doesn't deal with that, I'm just wondering about a solution that would deal with that as well as the complex type issue.

[jcachat]

It does handle that. But that's because I construct the DbExpression's inside LambdaToDbExpressionVisitor. Then EF translates those into actual SQL (and figures out column names and such). So actually, the column names won't be a problem - we just need to figure out how to properly construct the DbExpressions and then EF should do that for us.

[NickStrupat]

Ok, awesome. I wrote some code that looks for the ComplexType attribute on the expression member and some preliminary logic for how to skip that instance access and wait for the next node which contains the property inside the complex type. With that node, as you say, we just need to figure out what that DbPropertyExpression is supposed to be.

I'll look at it more this weekend with clearer eyes.

[NickStrupat]

I have working some basic support for complex types, including nested complex types in my fork. It broke a couple unit tests and doesn't seem to work in my larger project, but I'll take another stab at it tomorrow. Feel free to take a look.