|Accessing Neo4J from C++||Andreas H.||9/14/11 11:50 AM|
I have been googeling for this quite some time, but either I did not come up with the right search-terms or no one shares my problem:
What performant way would you recommand to interact with Neo4j from a C++ program (inserting and updating lots of nodes, but also doing complex queries).
The only way I found was the HTTP REST interface, which leads to the next question: Any tools you recommand? I don't like the idea to start with CURL and implement all the parsing I would need.
Sorry, if the answer to my questions is obvious... Please point me into the right direction.
|Re: Accessing Neo4J from C++||Saikat Kanjilal||9/14/11 11:53 AM|
There is a C++ curl library called libcurl that you can use so you wouldnt really be starting with CURL but would be calling the CURL APIs with this library. See the following link:
Hope this helps, the other option is more complicated and would involve writing JNI wrappers
|Re: Accessing Neo4J from C++||Peter Neubauer||9/14/11 12:04 PM|
there are embedded - Python drivers just coming out that use jpype. I
am no expert but that might be a way?
|Re: Accessing Neo4J from C++||James Thornton||9/14/11 2:25 PM|
Hi Andreas -
The standard way is to use the REST interface, but it's fairly straight forward to set up a ZeroMQ channel between Neo4j/JVM code and code in another programming language.
Here are the C++ and Java bindings:
I am doing this for Python/Java to create a fast connection between a Python program and the new Neo4jBatchGraph library (see https://groups.google.com/d/msg/gremlin-users/1wITOCYBtL0/nlz52WOpjY8J)-- I'll post an example soon.
|Re: Accessing Neo4J from C++||Andreas H.||9/14/11 2:37 PM|
Thanks for these quick answers, but thats not really what I was hoping for ):
@Saikat: I already know libcurl, but I thought, there already exists some kind of graph-database specific abstraction layer for it...
@Peter: Do you think about SWIG oder boost.python? As it is easier to integrate Python in C++ as it would be to wrap Java-Classes? Or do you suggest to use something like jpype but for C++ instead of Python?
|Re: Accessing Neo4J from C++||Andreas H.||9/14/11 2:45 PM|
Hi James -
Your answer came in while writing my last post. Seems I was too cutty (:
That ZeroMQ looks pretty interesting. I will have a closer look at it tomorrow.
|Re: Accessing Neo4J from C++||James Thornton||9/14/11 2:46 PM|
If you go the Python route, Bulbs is a Python library for Rexster (http://bulbflow.com).
|Re: Accessing Neo4J from C++||Andreas H.||10/6/11 6:26 AM|
As mentioned in another thread ( https://groups.google.com/forum/#!topic/gremlin-users/C1OlTG9xCpo ) a C++ interaction is now possible by using James' ZeroMQ binding.
Code is available here: https://github.com/Squelsh/lightsocket/tree/squelsh
|Re: [TinkerPop] Re: Accessing Neo4J from C++||Peter Neubauer||10/6/11 6:30 AM|
great to see some examples of this, certainly a very interesting binding!
http://www.neo4j.org - Your high performance graph database.
|Re: [TinkerPop] Re: Accessing Neo4J from C++||Arun Koshy||10/6/11 6:43 AM|
Now this is starting to get real ;-)
|Re: Accessing Neo4J from C++||James Thornton||10/6/11 10:08 AM|
This is cool Andreas!
|Re: Accessing Neo4J from C++||Andreas H.||4/16/13 6:35 AM|
the code is still there, just the access scheme on GitHub seems to be chagend :
Am Montag, 15. April 2013 13:59:27 UTC+2 schrieb Alireza Rezaei Mahdiraji:
|Re: Accessing Neo4J from C++||James Thornton||4/16/13 7:15 AM|
Hi Alireza -
Andy's C++ code has also been merged into the main Lightsocket repo (https://github.com/Squelsh/lightsocket); however, Lightsocket is several years old, and Blueprints has changed a lot during that time.
If I were writing a C++ binding today, I would write it for RexPro (https://github.com/tinkerpop/rexster/wiki/RexPro).
RexPro is a binary protocol for connecting to Rexster's new Grizzly NIO TCP sockets. Here's an overview of the some high-level concepts to think about when writing a RexPro driver (https://groups.google.com/d/msg/gremlin-users/QY_kf6D4k4s/DN1iWqDfJ7wJ).
As Stephen has said, the RexPro protocol is still in flux, but it's the future and much more current than Lightsocket. I might revive Lightsocket again someday as a ZeroMQ routing library, but RexPro is what you should build clients on today.
RexPro makes it easy to plug in different serializers and protocols, one of the things we want to do is make it easy to write RexPro clients in any language.
The last few days I've been looking into different protocol options and the tradeoffs of each, e.g. Avro, Thrift, websockets, SPDY, etc.
SPDY (http://www.chromium.org/spdy) is the foundation of HTTP 2.0, and it looks like it might replacement backend protocols as well.
SPDY will work for public facing sites and it has nice properties to make it ideal for the backend as well -- you can enable TLS or disable TLS on the backend if you want, and it uses binary framed messages so the the message doesn't have to be reparsed at each stage (http://www.igvita.com/2012/01/18/building-a-modern-web-stack-for-the-realtime-web/).
Plus, HAProxy now supports SPDY so it could be used with load-balance servers without having to build load-balancing logic into the client.
Rexter uses Grizzly as its NIO server, and Grizzly 2.3 supports SPDY so it will be easy to add to Rexster:
Ilya Grigorik of Google gave an AirBnB TechTalk on SPDY, and at the end he makes the case for using it for modern backend RPC instead of stuff like Thrift, etc.
"Building a Modern Web Stack"
SPDY clients exists in several languages, and the list is growing. SPDY handles connection management,m and you don't need to worry about connection pools since it's multiplexed so this would significantly simplify RexPro client development.