1

I have implemented a WCF oData service and can successfully query the oData service from LINQPad. Within my oData service I am sorting a memory resident collection into a logical business order and have confirmed via a raw html browser query the expected ordered data is shipped across the wire.

However it seems that LINQPad imposes its own default order on results based on the "ID" key of the objects shipped.

Is this expected behavior in LINQPad? Have I missed some setup property that can disable default ID sorting?

Edit: As Lasse indicated I should have included the query, here it is...

MyClass.Take (50)

And in the WCF service here is the essential collection code...

var list = new System.Collections.Generic.List<MyClass>();

..    // collection population

return list.AsQueryable();

* Update *

The local sorting behavior is specific to the ClassName.Dump(nn) LINQPad command.

Both ClassName and ClassName.ToList() display results in the order shipped from my oData service. This is still a slight problem for me since I was planning to ship LINQPad to a semi technical user testing population so they could query interim calculations in a financial modelling application. The Dump() command is the first default query suggested by LINQPad.

camelCase
  • 83
  • 4

2 Answers2

2

I think you are forgetting that like SQL, unless explicitly specified otherwise, preservation of order is rarely imposed in LINQ (it is in LINQ to objects, for the most part).

In order to address this, you should always specify order, especially if you need to perform operations like Take (or top n in SQL). This will guarantee the results everytime.

Otherwise, they are indeterminable.

casperOne
  • 73,706
  • 19
  • 184
  • 253
  • @casperOne: Interesting perspective. My experince is with LINQ to Objects and so far I have found that linq queries reflect the physical order of memory resident collections. I focus in high performance computing areas and attaching OrderBy() to all queries as a generic comfort factor does not feel right, bit like SQL programmers who stick "DISTINCT" on every query because they don't understand their DB schema. – camelCase Jan 13 '11 at 14:13
  • casperOne - are you and camelCase related :-) – jim tollan Jan 13 '11 at 14:35
  • @jim - No, we are not. I don't see the connection? – casperOne Jan 13 '11 at 14:50
  • @camelCase: Yes, I agree, for *LINQ to Objects* this holds true, but the call to `MyClass.Take` is to a WCF data service, so the LINQ aspect is not against an in-memory store of objects, that exists on the *server*. Just because the server sends back a sequence in a particular order doesn't mean the proxy which ultimately processes it will honor that order (unless specifically guaranteed by documentation, etc, which I don't believe WCF Data Services does). That's why he needs to use `OrderBy`. – casperOne Jan 13 '11 at 14:54
  • casperOne. sorry, just a silly scotsman playing with the 'visual' shape of your names. i'll get me coat then... – jim tollan Jan 13 '11 at 16:08
  • @casperOne: I am going to execute an intellectual LINQ u-turn. But first let me say that having confirmed the wire (HTTP) level data order I am still seeking an explanation why LINQPad's Dump() verb decides to sort in ID key order. Anyhow re. the u-turn. One of the attractions of LINQ is being able to prototype against a non relational datasource and then migrate to a real DB backing store with little disruption. So yes there is a good argument for declaring OrderBy() requirements in LINQ queries as a routine policy. – camelCase Jan 13 '11 at 16:32
  • @All: My question triggered some debate about when LINQ to Objects (via oData in my case) should be expected to preserve collection order. The following SO question discusses this in detail: http://stackoverflow.com/questions/204505/preserving-order-with-linq – camelCase Jan 14 '11 at 15:06
  • @camelCase: Note, that is for LINQ-to-Objects, that's a specific provider for LINQ, other providers are not guaranteed to follow the specifics of that answer. – casperOne Jan 14 '11 at 16:59
1

i think the default order is based on the order that they are physically inserted into the database. this being the case, i'd ensure that your real app ALWAYS applies a logical sort to the data (or in this case, your linqpad query).

I know this from working experience as I had a linq query that worked fine until some external data was inserted. this external data although inserted in a linear fashion actually had date references spanning many years. thus when i made sequential runs thro linq, sections were missing. sorting by date fixed the problem. (this was a few years back, i've sinced learned to think about default sort ordering) :)

just my tuppence

jim tollan
  • 22,305
  • 4
  • 49
  • 63
  • There is no database involved everthing in memory resident in my code and as mentioned above, when I hit the oData service with Internet Explorer the page source confirms the expected data order at the http wire level. – camelCase Jan 13 '11 at 13:34