2015-05-18 5 views
5

Per i seguenti dati:Perché l'ordinamento perso quando restituisce una raccolta tramite l'API REST con resultDataContents = grafico

create (a:Attendee {name:'luanne'}); 
create (a:Attendee {name:'adam'}); 
create (a:Attendee {name:'christoph'}); 
create (a:Attendee {name:'vince'}); 
create (a:Attendee {name:'michal'}); 

questa ricerca

MATCH p=(n:Attendee)-[r*0..1]-(m) 
WITH p order by head(nodes(p)).name 
return collect(distinct(p)) 

quando eseguiti tramite i percorsi shell ritorno di lunghezza uno, ordinato dal nome del primo nodo nel percorso.

Tuttavia, tramite l'API REST:

POST http://localhost:7474/db/data/transaction/commit 
{"statements":[ 
{"statement":"MATCH p=(n:`Attendee`)-[r*0..1]-(m) WITH p order by head(nodes(p)).name return collect(distinct(p))","parameters":{},"resultDataContents":["graph"]} 
]}]} 

stesso ordine non è mantenuto (sembra che è ordinato dal nodo id).

Come posso risolvere il mio Cypher per ottenere gli stessi risultati di quando viene eseguito tramite la shell?

PS. Funziona bene se resultDataContents è "row" e anche quando non c'è COLLECT utilizzato in REST

risposta

1

In questo caso non è necessario raccogliere.

return distinct p dovrebbe essere sufficiente.

In resultDataContents "graph" rielabora la risposta utilizzando set per raccogliere in modo univoco nodi e relazioni per la risposta. Molto probabile che lì l'ordine è perso.

+0

Ciao Michael, usiamo Collect per ridurre al minimo la quantità di Cypher inviata attraverso il filo. Otteniamo una singola riga indietro, tutti i nodi distinti, seguiti da tutte le relazioni distinte. Senza di esso, in formato "grafico", per ogni percorso dal nodo A a qualche altro nodo B, le informazioni sul nodo A vengono ripetute. Questo può gonfiare enormemente la risposta della cifratura e finiamo per elaborare gli stessi dati del nodo più volte nel client. Non c'è modo di aggirare questo? – Vince

Problemi correlati