Encapsulating traversals in a server side plugin

30 views
Skip to first unread message

KentFitch

unread,
Feb 22, 2012, 1:22:31 AM2/22/12
to Neo4j
Hi,

We've written a server plugin (neo4j 1.6) to essentially take a
"simple" search query and expand it into a complex lucene search query
required to implement the relevance ranking our application requires,
and that is working fine.

But now we similarly want to encapsulate traversals. Our traversals
are complex and dependent on many factors in the graph and other
factors such as identity of the user.

We note the warning at the top of http://docs.neo4j.org/chunked/snapshot/rest-api-traverse.html,
and started on the approach "write your own server side plugin
executing the interesting traversals with the Java API".
We actually used the Java API to load groovy and have been
experimenting with gremlin to do most of the work, but here's the
problem:

The server plugin has to return an iterator. We dont want to return
the raw nodes found by the lucene search: in our case, we only ever
want to return the json resulting from a highly customised traversal
of these nodes. Returning the json as a list of strings causes the
part of the neo4j web server which formats reponses to "double escape"
the json we generated and put in the string, so that didnt work.

So, I'm wondering how to encapsulate traversals with a server plugin.
It seems that we'd want to return from our server plugin either:

- 2 things:
- the list of nodes
- the traverser to be applied to each node

or

- a "ready to send" json response.

I can see that the server plugin architecture is set up to support
multiple output formats, not just json, so the second alternative
doesn't seem to fit.

But I'm not sure how to bring about the first, or how else to achieve
what we're after. Maybe an unmanaged extension is the way to do this?

On a related issue, can an unmanaged extension access the http
request? I ask because a requirement we'll soon need to address will
be personalisation of traversals and responses based on user profiles,
and an HTTP cookie is a common part of patterns to handle this.

Regards,

Kent Fitch

Jim Webber

unread,
Feb 22, 2012, 3:59:26 AM2/22/12
to ne...@googlegroups.com
Hi Kent,

I think your instincts are right - you're going sufficiently off-piste with respect to managed plugins that an unmanaged extension will be an easier path (though you'll get to write your own serializers).

The unmanaged extension API is just JAX-RS, so you get the same programmatic access to the underlying HTTP request/response as if you were just writing a normal JAX-RS app.

Jim

KentFitch

unread,
Feb 22, 2012, 6:11:45 PM2/22/12
to Neo4j
Thanks Jim, that makes sense.

I am not experienced with JAX-RS, so if someone can point me to an
example of an unmanaged extension using JAX-RS to process HTTP
requests against neo4j it would be greatly appreciated!

Or is the HelloWorldResource example all I need, other than to read-up
on JAX-RS?

regards,

Kent


Michael Hunger

unread,
Feb 22, 2012, 6:18:49 PM2/22/12
to ne...@googlegroups.com
Yes the hello-world example covers it already nicely.

You might also look at the RestfulGraphdatabase.java which contains lots of the neo4j-REST-API.

https://github.com/neo4j/community/blob/master/server/src/main/java/org/neo4j/server/rest/web/RestfulGraphDatabase.java

Michael

Jim Webber

unread,
Feb 22, 2012, 6:38:37 PM2/22/12
to ne...@googlegroups.com
Hi Kent,

Here's an example of an unmanaged extension from the Doctor Who koans:

https://github.com/jimwebber/neo4j-tutorial/blob/master/src/koan/java/org/neo4j/tutorial/koan14/SalaryUnmanagedExtension.java

Jim

Reply all
Reply to author
Forward
0 new messages