Breaking change in LINQ to CSLA.NET between versions 3.6.2 and 3.6.3

MBursill posted on Thursday, July 23, 2009

My hierarchy of objects consists of:

Role (root)
|__ PermissionCategories (editable list)
                   |_PermissionCategory (editable object)
                                      |_ Permissions (editable list)
                                                  |_ Permission (editable object)

In CSLA.NET 3.6.2-090322, I used the following LINQ expression (inside the role class) without issues:

// get a list of all the current permissions this role has
var rolePermissions = from pc in PermissionCategories
                                 from p in pc.Permissions
                            select p;

In csla-3.6.3-090610 to csla-3.7.0-090721 the same LINQ query returns null.

I have confirmed that the proper data is still contained in the objects. The problem has to be with the way this LINQ statement is now being evaluated.

Any thoughts?

Thanks.

-Mike.

AaronErickson replied on Thursday, July 23, 2009

Good afternoon. I just checked a change into the trunk that should resolve this issue, as well as added a new test that demonstrates this bug.

MBursill replied on Tuesday, August 04, 2009

I just tested this with build 3.7.1-090803 and unfortunately the bug still appears to exist. Same holds true for the test in the csla test project.

I made a simple WPF project, dumped in the "nested_collections_return_valid_results" method, and necessary collection/item classes. I made the method return a bool, and changed the last line to:

return get42back.First().TestProp == "42";

I get a null exception on "get42back".

I don't know NUnit very well, but is it possible the Assert.IsTrue method is trapping the exception and causing a false positive?

-Mike.

MBursill replied on Tuesday, August 04, 2009

I see the problem... digging through the source of 3.7.1 it doesn't look like the fix made its way in (http://www.lhotka.net/cslacvs/viewvc.cgi/trunk/cslacs/Csla/Linq/CslaQueryProvider.cs?r1=3949&r2=4012), which is odd seeing as the change log quotes:

LINQ to CSLA (090723)

http://www.lhotka.net/cslabugs/edit_bug.aspx?id=448

Resolution to certain generic mapping issues in the method mapper caused SelectMany to break... resolved so that SelectMany method mapping is handled similar to GroupJoin, which has same sort of issues with mapping a generic Expression to a similar generic Func.

-Mike.

RockfordLhotka replied on Tuesday, August 04, 2009

It is possible that the fix is only in 3.8.

I changed the version structure yesterday, creating a new branch for 3.7.1, while trunk is now 3.8.0.