EnumerableRowCollection Type

If you've been playing with LINQ to DataSet, you may have noticed the EnumerableRowCollection type. For example, if you have a query like the following, the type of query is EnumerableRowCollection.

var query = from row in ds.Tables[0].AsEnumerable()

            where row.Field<string>("name") == "Bob"

            select row;

So what is this type and what is it used for?

As you know, the return type for any particular call must exist. While LINQ works with IEnumerable<T>, there still needs to be an implementation type. EnumerableRowCollection is that type. The EnumerableRowCollection type has always existed, but you would never have cause to see it before Beta2. What would happen is that the AsEnumerable call would return am EnumerableRowCollection (it used to have a different name – EnumerableDataTable, but that was just a refactor). Once you made your first LINQ call, that type would be “lost”. That is, the return type from the LINQ call is IEnumerable<T>, so the actual implementation class is no longer part of the signature.

In order for LinqDataView to work without using IQueryable (which we didn’t want to do for performance reasons), we have to hold on to the implementation class. As long as are working with a EnumerableRowCollection instance instead of a “something” which implements IEnumerable we can capture each LINQ operator into a state bag which allows us to recreate the effects of the LINQ query in a DataView. Once you call a LINQ operator that we can’t support in LinqDataView (e.g., Group By), the return type is then IEnumerable, and all further calls execute in the LINQ library, not LINQ to DataSet, and the return type will then show up as IEnumerable. If there is interest I can go into further detail.

This is something that doesn’t really have an impact on the usage of LINQ to DataSet, but knowledge is never a bad thing.