[odata] DISTINCT bestaat niet (in odata v2) - truukje gezoch

[Sando]

Ik werk niet zoveel met Microsoft producten maar afentoe moet ik iets met een odata bron. Gelukkig is het vrij simpel om een query mee te geven in het request via JSON of een query string.

Maar nu moet ik ergens resultaten vandaan halen van een record waar er meerdere van zijn, en odata kent geen distinct. Ik wil bijvoorbeeld alle distinct namen hebben, bij voorkeur met de hoogste revisie, uit de volgende voorbeeld-tabel:

code:

Name    Revision
Henk    1
Henk    2
Henk    3
Kees    1
Kees    2
Kees    3

Maar er is geen distinct of subqueries:
MSDN: Supported OData Query Options
http://www.odata.org/documentation/overview/

Is er een al dan niet gangbare manier om toch voor elkaar te krijgen om hier alleen Henk 3 en Kees 3 te krijgen? Dit kan natuurlijk 'clientside' (of hoe je dat noemt als het ook een server is), maar het gaat om heel veel records en de odata server heeft een ingebouwde maximum limit van 50 resultaten.

[ Voor 3% gewijzigd door Sando op 09-08-2013 14:47 ]

[RobIII]

Sando schreef op vrijdag 09 augustus 2013 @ 14:46:
Is er een al dan niet gangbare manier om toch voor elkaar te krijgen

[google=odata distinct] geeft overal 'tzelfde resultaat -> kan niet / doe het client-side.

Sando schreef op vrijdag 09 augustus 2013 @ 14:46:
Dit kan natuurlijk 'clientside' (of hoe je dat noemt als het ook een server is)

Al draait 't op een andere server, je applicatie/server is dan nog altijd de client van de OData server

Sando schreef op vrijdag 09 augustus 2013 @ 14:46:
maar het gaat om heel veel records en de odata server heeft een ingebouwde maximum limit van 50 resultaten.

Dan ga je toch sowieso al nat als 't meer dan 50 namen zijn?

Je kunt, neem ik aan, ook niet bij de server die de OData verzorgt? Want als je dat wel zou kunnen kun je natuurlijk een extra methode toevoegen die specifiek die lijst aan namen produceert...

[Sando]

Nee exact, ik kan niet bij de odata provider.

Met die max 50 resultaten ga ik niet perse nat, want ik kan natuurlijk steeds een $skip 50 doen net zolang tot ik alle resultaten heb en dan clientside 98% van de resultaten weggooien om distinct te krijgen. Maar dat is wel erg [insert animated gif van iemand die een lampje wil vervangen en uiteindelijk de auto aan het repareren is].

Misschien is het niet anders.

[Woy]

Ik heb nooit echt veel met oData gedaan, maar volgens mij is het inderdaad niet mogelijk om data te aggregeren op de server. In je voorbeeld zou het dan ook logisch zijn als er iets van een "IsLatestRevision" veld o.i.d. zou zijn om daarop te kunnen filteren.

Overigens wil je niet echt een DISTINCT doen, want de rijen zijn niet exact gelijk, je zult altijd iets van een aggregatie uit moeten voeren want je wil blijkbaar de rij met de hoogste revisie selecteren.

[Sando]

Oh daarom hebben veel van die oDatafeeds een isLatest record, ik vond dat altijd zo raar, maar God (lees: Microsoft) zag blijkbaar dat het goed was zo.

[Woy]

Sando schreef op zondag 11 augustus 2013 @ 21:26:
Oh daarom hebben veel van die oDatafeeds een isLatest record, ik vond dat altijd zo raar, maar God (lees: Microsoft) zag blijkbaar dat het goed was zo.

Op zich ook logisch natuurlijk, want je zult altijd de laatste versie op willen halen, dan is het veel eenvoudiger om bij het wijzigen direct op te slaan wat de laatste versie is, anders moet je dat bij elke request weer op gaan zoeken.

Maar oData is gewoon niet bedoeld om data transformeren/projecteren. Als je dat wil zal de service zelf iets van een View/Entity aan moeten bieden die de reeds geprojecteerde data aanbiedt.

[ Voor 15% gewijzigd door Woy op 12-08-2013 08:23 ]

[EfBe]

Wat je wilt zou kunnen met een group by

SQL:

select name, max(revision) from names 
group by name

maar odata kent geen max aggregate function.

Met odata (heb zelf een odata provider geschreven dus waarmee je een service kunt maken) is het altijd net-niet... v3 is wel OK, v2 is echt dat je denkt... hebben jullie daar zoveel jaar over gedaan?!

Maar oData is gewoon niet bedoeld om data transformeren/projecteren. Als je dat wil zal de service zelf iets van een View/Entity aan moeten bieden die de reeds geprojecteerde data aanbiedt.

Ben ik niet met je eens, het is juist bedoeld voor het ontsluiten van een datamodel waarop je custom projections kunt doen op de server zonder dat je daar extra code voor hoeft te schrijven.

[Woy]

EfBe schreef op maandag 12 augustus 2013 @ 10:04:
maar odata kent geen max aggregate function.

Helemaal geen aggregate functions toch?

EfBe schreef op maandag 12 augustus 2013 @ 10:04:
Ben ik niet met je eens, het is juist bedoeld voor het ontsluiten van een datamodel waarop je custom projections kunt doen op de server zonder dat je daar extra code voor hoeft te schrijven.

Ik probeerde te zeggen dat de implementatie er niet voor bedoeld was. Natuurlijk is het uiteindelijk wel het doel van de standaard

[ Voor 20% gewijzigd door Woy op 12-08-2013 10:17 ]

[Sando]

Ik vind het ook wel een beetje vreemd hoor, geen max, geen distinct, vanalles niet, een hele standaard moet 'gepatched' worden door de data maar aan te passen om de query ('latest') te hard-coden.

Sowieso ziet een querystring er nogal omslachtig uit waardoor je zou vermoeden dat er juist erg veel mogelijk is. Maar dat valt tegen. Maar goed, volgens mij is het ook niet de bedoeling dat je zelf querystrings gaat maken. Je hebt daar hele omslachtige software van Visual Studio voor. Of LINQPad.

Maar dat zou niet moeten hoeven IMO. En het werkt niet (lekker) in Linux.

[Woy]

Sando schreef op maandag 12 augustus 2013 @ 10:39:
Ik vind het ook wel een beetje vreemd hoor, geen max, geen distinct, vanalles niet, een hele standaard moet 'gepatched' worden door de data maar aan te passen om de query ('latest') te hard-coden.

In dit geval vind ik dat sowieso de beste optie, ook al zou je wel kunnen grouperen. Immers zou je anders al snel bij iets als een groupwise maximum query aankomen. Want aangezien het om revisies gaat zal een query zoals EfBe aanhaalt al niet meer werken omdat het veld waar je in geïnteresseerd bent waarschijnlijk ook veranderd is

Sowieso ziet een querystring er nogal omslachtig uit waardoor je zou vermoeden dat er juist erg veel mogelijk is. Maar dat valt tegen. Maar goed, volgens mij is het ook niet de bedoeling dat je zelf querystrings gaat maken. Je hebt daar hele omslachtige software van Visual Studio voor. Of LINQPad.

Maar dat zou niet moeten hoeven IMO. En het werkt niet (lekker) in Linux.

Zo omslachtig zijn de query strings ook weer niet, maar ze bieden gewoon een hoop flexibiliteit. Alleen op het punt van data aggregatie/projectie bieden ze IMHO nog te weinig opties. Verder moet het vast eenvoudig zijn om zelf een tooltje te maken die aan de hand van een LINQ query een oData query string oplevert.

[Sando]

Woy schreef op maandag 12 augustus 2013 @ 10:48:
[...]

In dit geval vind ik dat sowieso de beste optie, ook al zou je wel kunnen grouperen.

Ben ik met je eens. Ik moet maar even kijken of we toch een veld kunnen toevoegen serverside. En anders toch maar een (gegroepeerde) megaquery doen en opsplitten in chunks van 50 records met $skiptoken.