Rails 3 和图形数据库
在 Postgresql 上运行的 Rails 3 应用程序需要切换到图形数据库才能成长。它们有很多，并且都提供不同类型的 API，主要是 REST。
演讲给我很大启发“http://www.youtube.com/watch?v=2ElGO1P8v0c”rel="noreferrer">Emil Eifrem，NeoTechnologies 首席执行官，关于Neo4j 可以完成什么。我必须承认，我已经玩过它了，这个东西绝对是我们所需要的，但是有几个障碍。
- REST API 不是事务性的。
- Rails 3 应用程序在 ruby 1.9.2 上运行，但不能在 jRuby 1.5.3 或 1.6 上运行来实现本机 API。
有些数据库也是由 Java 驱动并提供 REST API，因此使用它们不会有任何改变。由于许可证或成本或缺乏背后的团队，我们无法选择其他人。
我想我遗漏了一些东西，所以如果您能提供有关我们的选择以及什么对我们有利的提示、见解或建议，我将不胜感激。谢谢。
A Rails 3 application running on Postgresql needs to switch to a graph database to be able to grow up. There are many of them and they all offer different kind of API, REST mostly.
I am highly inspired by talks of Emil Eifrem, CEO of NeoTechnologies, about what can be accomplished with Neo4j. I must confess, I've played with it and this thing is absolutely what we need, but there are several obstacles.
- REST API is not transactional.
- Rails 3 apps are running on ruby 1.9.2, but not jRuby 1.5.3 or 1.6 to achieve native API.
Some databases are also driven by Java and offer REST API, so taking them changes nothing. Someother are not an option for us because of a license or a cost or a lack of team behind them.
I assume I'm missing something, so would appreciate any tip, insight or advice about what are our options and and what can play well for us. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以在 jruby 1.6 上使用 Rails 3 运行 Neo4jrb，所以这应该不是问题。
要在此之上运行事务（REST）API，您可以轻松编写自己的 Neo4j-Server 插件/扩展 也可以在内部使用 Neo4jrb，但公开适合您的域的 API，并且比细粒度的 Neo4j-Server REST API 更简洁/简洁。这也应该更容易让您的客户理解，因为它用您的术语、词汇和用例进行讨论。
我们目前正在致力于创建一个通用 (j)ruby 服务器扩展，该扩展能够使用发布的代码并使其可用作新的 REST 端点。
You can run Neo4jrb with Rails 3 on jruby 1.6, so that should not be a problem.
To run a transactional (REST) API on top of that you can easily write your own Neo4j-Server plugin/extension that could also use Neo4jrb internally but exposes an API that fits your domain and is less verbose/chatty than the fine grained Neo4j-Server REST API. This should also be easier to consume for your clients as it talks in your terms, vocabulary and use-cases.
We're currently working on creating a generic (j)ruby server extension that is able to consume posted code and make it available as new REST endpoints.