I can repro the issue you run into. It's the new object [] { ... } they put in the select, my code doesn't anticipate on that .

I'll build that in, it's not such a big deal, but it will take some time though...

Ok! I've managed to implement this. Grouping on constants, multi groupings without alias errors ( ) and projections to arrays.

Tomorrow I'll try to see if Miha's project works. I'll attach a new build to this post in a couple of minutes.

Otis wrote:

Ok! I've managed to implement this. Grouping on constants, multi groupings without alias errors ( ) and projections to arrays.

Tomorrow I'll try to see if Miha's project works. I'll attach a new build to this post in a couple of minutes.

But of course it works. While the pagging doesn't - for some reason it goes into endless recursion - try using all orders as datasource.

mihies wrote:

Otis wrote:

Ok! I've managed to implement this. Grouping on constants, multi groupings without alias errors ( ) and projections to arrays.

Tomorrow I'll try to see if Miha's project works. I'll attach a new build to this post in a couple of minutes.

But of course it works.

Cool! So first phase has been done

While the pagging doesn't - for some reason it goes into endless recursion - try using all orders as datasource.

I assume paging won't work, as it likely uses Skip/Take, and Skip throws an exception. I'll check what the query is that it is executing. I'll implement a fake Skip, so it will be reworked as paging code, if used together with take (if it's used without take, it's ignored).

Btw, I discovered a bug in linq to sql:

var q = from c in nw.Customers select new List<string>() { c.CustomerID, c.CompanyName};

when enumerated, it crashes with an exception: 'ListInit' unknown nodetype. This isn't a small glitch, they haven't anticipated this issue. Our provider also crashes on this, I'll address this shortly. Not sure if this will be used a lot though, probably not. I thought about this when implementing projection to array, which I also didn't anticipate for, and thought: what if you use another list-like class, that requires a ListInit expression, but in the linq to sql expression visitor, there's no code for handling ListInit,because ListInit's are local expressions and can be compiled.

Ok, I now have the app you wrote working. It's executing a couple of queries for the single set of customers. That's not really encouraging.

What I also read on the microsoft forums is that this grouping on constant will decrease performance on large tables, and devexpress is executing this every second time they're fetching the data. (they also fetch the data without the grouping but with a sorter).

I ran into a couple of issues in our code as well: grouping on a column dies in the alias mapper, which didn't show up in our unittests because we didn't have any projection to object arrays

This is a good tester app as well, I'll see which bugs I can bash out of our code with it

(edit) fixed a bug with the alias mapper, I can now group in the grid. And look here: when I group on Country AND City, it only groups on 'country' on the database, the city group is done on the client. This is, I think, because it's a bit nasty to implement with the anonymous types you need to specify the grouping. Oh well. (llblgen pro supports this btw)

I can't get the paging to work btw... is it implemented in this grid? I can fetch orders just fine (after I've regrabbed the right columns of course).

When I scroll through the grid I see these kind of queries popping up:

value(SD.LLBLGen.Pro.LinqSupportClasses.DataSource2`1[LinqToLLBLGenPro.EntityClasses.OrdersEntity]).Select(o => o).WithPath(value(SD.LLBLGen.Pro.LinqSupportClasses.IPathEdge[])).OrderBy( => .OrderId).Where( => ((((((((((((((((((((((((((((((((.OrderId = 10344) || (.OrderId = 10345)) || (.OrderId = 10346)) || (.OrderId = 10347)) || (.OrderId = 10348)) || (.OrderId = 10349)) || (.OrderId = 10350)) || (.OrderId = 10351)) || (.OrderId = 10352)) || (.OrderId = 10353)) || (.OrderId = 10354)) || (.OrderId = 10355)) || (.OrderId = 10356)) || (.OrderId = 10357)) || (.OrderId = 10358)) || (.OrderId = 10359)) || (.OrderId = 10360)) || (.OrderId = 10361)) || (.OrderId = 10362)) || (.OrderId = 10363)) || (.OrderId = 10364)) || (.OrderId = 10365)) || (.OrderId = 10366)) || (.OrderId = 10367)) || (.OrderId = 10368)) || (.OrderId = 10369)) || (.OrderId = 10370)) || (.OrderId = 10371)) || (.OrderId = 10372)) || (.OrderId = 10373)) || (.OrderId = 10374)) || (.OrderId = 10375)))

Clearly they don't know that you can do: .Where(new int[] { 10344, 1045, ...}.Contains(.OrderId))...

Or their xpo can't deal with contains on a list (which is a nasty piece of code ), not sure. They use this I think to traverse through the set of rows to display.

I can't get prefetch paths to work either, perhaps a bug somewhere... (edit) fixed as well . Looking good! I now have a grid with orders with 1 line of code and I can group, filter (using the grid's filtering stuff ) and prefetch the order details efficiently with the orders

(edit) Btw, Miha: you shouldn't have the linqhandler tracer set to level 4. Set it to level 3, more efficient ). I've attached a new build.