2015-04-03 18 views
10

Per quanto ne so, gli ID forniti da Neo4j (ID(node)) sono instabili e si comportano in qualche modo come i numeri di riga in SQL. Poiché gli ID sono principalmente usati per le relazioni in SQL e questi sono facilmente modellabili in Neo4j, non sembra esserci molto uso per gli ID, ma come si risolve il recupero di nodi specifici? Avere un'API REST che dovrebbe avere percorsi univoci per ciascun nodo (ad esempio /api/concept/23) sembra un caso piuttosto standard per le applicazioni Web. Ma nonostante sia così fondamentale, l'unica via praticabile ho trovato erano o tramite quadri specificiProprietà incremento automatico in Neo4j

  • lingua
  • come un nodo non connesso che mantiene gli incrementi:
// get unique id 
MERGE (id:UniqueId{name:'Person'}) 
ON CREATE SET id.count = 1 
ON MATCH SET id.count = id.count + 1 
WITH id.count AS uid 
// create Person node 
CREATE (p:Person{id:uid,firstName:'Gabriel',lastName:'Smith'}) 
RETURN p AS person 

Fonte:http://www.neo4j.org/graphgist?8012859

Non c'è davvero un modo più semplice e in caso contrario, io c'è una ragione particolare per questo? Il mio approccio è anti-pattern nel contesto di Neo4j?

risposta

7

Gli ID interni di Neo4j sono un po 'più stabili degli ID di riga di sql poiché non cambiano mai durante una transazione per es.

E in effetti non è consigliabile esporle per uso esterno. So che ci sono alcune intenzioni a Neo internals per implementare una funzione del genere.

Fondamentalmente le persone tendono ad usare due soluzioni per questo:

  1. utilizzando un generatore di UUID a livello di applicazione, come per PHP: https://packagist.org/packages/rhumsaa/uuid e aggiungere un/uuid vincolo univoco etichetta su tutti i nodi.

  2. Utilizzando una manciata Neo4j plugin come https://github.com/graphaware/neo4j-uuid che aggiungerà proprietà UUID al volo, in modo che si rimuove l'onere di gestire la cosa a livello di applicazione ed è più facile da gestire lo stato di persistenza del nodo oggetti

+2

Questo non risponde alla domanda. Gli ID di incremento automatico possono essere usati per ordinare gli oggetti in ordine di creazione, cosa che non può essere eseguita con uuid's –

+2

Quale parte della domanda risponde al tuo commento? –

+0

Credo che aggiungere un timestamp unix o qualche tipo di prefisso data-time alla stringa univoca casuale risolverebbe il problema di ordinamento. – Guy