2011-05-05 1 views
13

Un'applicazione Rails 3 in esecuzione su Postgresql deve passare a un database grafico per poter crescere. Ce ne sono molti e offrono tutti diversi tipi di API, principalmente REST.Rails 3 e database di grafici

Sono molto ispirato da talks di Emil Eifrem, CEO di NeoTechnologies, su ciò che può essere realizzato con Neo4j. Devo confessare, ho giocato con esso e questa cosa è assolutamente ciò di cui abbiamo bisogno, ma ci sono diversi ostacoli.

  1. L'API REST non è transazionale.
  2. Le applicazioni Rails 3 sono in esecuzione su Ruby 1.9.2, ma non su jRuby 1.5.3 o 1.6 per ottenere l'API nativa.

Alcuni database sono anche guidati da Java e offrono API REST, quindi non apportare modifiche. Qualcuno non è un'opzione per noi a causa di una licenza o un costo o una mancanza di squadra dietro di loro.

Presumo che mi manchi qualcosa, quindi apprezzerei qualsiasi consiglio, intuizione o consiglio su quali sono le nostre opzioni e che cosa può giocare bene per noi. Grazie.

+0

Puoi espandere ciò che intendi per "API REST non è transazionale"? –

+2

Sicuro. Utilizzando l'API REST, non è possibile eseguire il rollback di un insieme di operazioni contemporaneamente. Ad esempio, si desidera eliminare 3 nodi, si esegue la prima e la seconda richiesta, ma il terzo in qualche modo fallisce e non è possibile ripristinare la memoria allo stato in cui si trovava, prima di iniziare, con una parola "rollback". Ma questo può essere ottenuto con l'API nativa. – mcmlxxxiii

+1

Questo è un problema. Hai segnalato questo bug a neo4j ragazzi? Sono sicuro che vorranno correggerlo. –

risposta

9

È possibile eseguire Neo4jrb con Rails 3 su jruby 1.6, quindi non dovrebbe essere un problema.

Per eseguire un transazionale (REST) ​​API in cima che si può facilmente scrivere il proprio plug-in Neo4j-Server/extension che potrebbe anche usare Neo4jrb internamente, ma espone un'API che misura il vostro dominio ed è meno verboso/loquace rispetto alla API REST Neo4j-Server a grana fine. Questo dovrebbe anche essere più facile da consumare per i tuoi clienti in quanto parla nei tuoi termini, vocabolario e casi d'uso.

Attualmente stiamo lavorando alla creazione di un'estensione generica del server (j) ruby ​​in grado di utilizzare il codice pubblicato e renderlo disponibile come nuovo endpoint REST.

+0

Grazie, Michael. Il consumo di codice pubblicato sembra molto rassicurante. – mcmlxxxiii