Is there an equivalent saving of time to

EntityCollection<FooEntity> foos = ((ILLBLGenProQuery)from ..... select x).Execute<EntityCollection<FooEntity>>();

for linq queries using the group operator? I'm guessing I need to figure out what the resulting type is of the query?

The docs use this example:

var q = from c in metaData.Customer
        group c by new { c.Country, c.City } into g
        select new { g.Key, g.Count()};

What would q be?

What would q be?

An anonymous type

I think it would be based on a LinqSupportClasses.Grouping<string, Customer> and that I would have to hack up a lot of code to remove internal and get access to the _elements.

Is it possible to do something similar to that query with the normal Adapter querying? Or am I kidding myself that the time to enumerate all my results will have a significant impact?

tmatelich wrote:

I think it would be based on a LinqSupportClasses.Grouping<string, Customer> and that I would have to hack up a lot of code to remove internal and get access to the _elements.

In your grouping example (second query) 'q' is IQueryable<_anonymoustype_>, where the anonymous type has two properties, the key and the count.

Is it possible to do something similar to that query with the normal Adapter querying? Or am I kidding myself that the time to enumerate all my results will have a significant impact?

I don't fully understand what you're after. Could you elaborate a bit about the current query you're using and what you want to optimize, as it's currently not clear to me.

http://www.llblgen.com/documentation/2.6/Using%20the%20generated%20code/Linq/gencode_linq_gettingstarted.htm#ILLBLGenProQuery

I was just hoping I could get the same advantage mentioned there for a grouped query.

I'm going to be retrieving up to a thousand measurements and in my ui, I'll be displaying them grouped by sample that they came from, having to transfer them from the enumerator to collections for each sample seems like a waste of time.

I could probably normalize my schema to have a separate table for samples (I'm currently totally denormalized) and have the sample entity contain a collection of measurement entities, but I think that would heavily complicate the query. Currently I'm retrieving all measurements in a group of samples, pseudo select * from measurements where group = "foo" group by sample. This seems simpler than a normalized setup, but perhaps I'm not giving SQL enough credit?

I still don't understand what you really want. To me seems like you don't need the group part. How your table looks like? and How the results you want look like? Seems like you want all the fields of your table, and you just have to work on the filter (where clause).

ah! I see what you mean.

The Enumerator traverses the set and returns a list, which is a copy action, and the Execute method avoids that (it returns the set produced by the query without copying it).

You can avoid this by simply enumerating the 'q', which makes you enumerate the real result list, and do the action you want to perform per element. This might not doable in your situation, e.g. you might want to add additional linq to objects operators to the resultset. This indeed has the side effect that the linq provider fetches the data into a list, and you then again copy it in a list through the operations applied to it in memory.

Though you can always cast the 'q' (unless it's a scalar value, because Linq doesn't defer the execution of these queries, they're executed immedately) to ILLBLGenProQuery and call Execute. You don't know the type to pass to the generic method, but there's a non-generic method as well. You can cast that result to IList for example, if you don't want to have the copy action.

Other than that, you either have to write a custom class per query or use strictly enumeration over the queries (so foreach(var v in q) {} )