, Apr 8, 2010 at 10:17 PM, Michael Ludwig mil...@gmx.de wrote:
Tobias Ivarsson schrieb am 08.04.2010 um 18:23:27 (+0200)
[Re: [Neo] Traversers in the REST API]:
On Wed, Apr 7, 2010 at 3:05 PM, Alastair James al.ja...@gmail.com
wrote:
when we start talking about returning 1000s of nodes
. We can certainly build a
separate API that we can all leverage if needed, but I don't think it
should be in the core REST-ful layer.
Just my $0.02, after taxes.
Original Message
Subject: Re: [Neo] Traversers in the REST API
From: Tobias Ivarsson
Since in manycases the results of a query will need to be reformed into
their associated domain objects
Unlikely to be the case over the HTTP API. Its unlikely people will create
domain objects in (e.g.) PHP they will just use the data directly.
Pagination is kinda tricky if the data changes
Why not just slap memcached in the middle? Would help with scalability
as well, plus you could keep cached results keyed by query params in
there if needed. Just a thought...
Original Message
Subject: Re: [Neo] Traversers in the REST API
From: Alastair
What I want to avoid
is keeping state on the server while waiting for the client to request the
next page.
You are quite right. However, I think for many use cases (e.g. generating a
paginated list of results on a webpage) it would not be necessary to store
state on the server.
That would be
Tobias Ivarsson schrieb am 08.04.2010 um 18:23:27 (+0200)
[Re: [Neo] Traversers in the REST API]:
On Wed, Apr 7, 2010 at 3:05 PM, Alastair James al.ja...@gmail.com
wrote:
when we start talking about returning 1000s of nodes in JSON over
HTTP just to get the first 10 this is clearly sub
On 8 April 2010 21:17, Michael Ludwig mil...@gmx.de wrote:
Limiting and paging usually go hand in hand with sorting, in my
experience. Why would anyone want to page through an unsorted
collection?
Its quite possible that you might want the nodes in the order they were
found (e.g. the closest
These two ways of traversing a graph complement each other, it's not that
one is better than the other. Would you agree on this?
I think I agree. I would hope to be able to use XPath/Gremlin style querying
for most things, and a more programatic system for more complex ones.
a JSON
Our thoughts on how to handle pagination is not yet, we'll get something
that works first, and then add pagination (in a number of places) later on.
As for sorting: yes, that is a comment on the API as a whole. We have opted
at not providing sorting, since there are good sorting facilities
Cheers guys. All sounds good. One comment:
As for sorting: yes, that is a comment on the API as a whole. We have opted
at not providing sorting, since there are good sorting facilities available
in the JRE already. Since that makes it easy for the user to implement
their
own sorting it
We had a little discussion about how to make a first/good implementation of
traversers in the Neo4j REST API. If we just start at the core and expose
basic traversers, as they are in the graph database API (or will be, with
the next iteration of the traversal framework finding its way into the
Hi guys,
For what its worth
I have yet to use the Neo4j traversal framework because it is simply is not
expressive enough. The traverser framework is like a single-relational
traverser on a multi-relational graph. You only allow or disallow certain edge
labels--not the ordered
On Tue, Mar 30, 2010 at 4:20 PM, Marko Rodriguez okramma...@gmail.comwrote:
Hi guys,
For what its worth
I have yet to use the Neo4j traversal framework because it is simply is not
expressive enough. The traverser framework is like a single-relational
traverser on a multi-relational
Mattias Persson schrieb am 30.03.2010 um 16:06:49 (+0200):
a JSON document describing the traverser, like:
{ order: depth first,
uniquness: node,
return evaluator:
{ language: javascript,
body: function shouldReturn( pos ) {...} },
prune evaluator:
{
14 matches
Mail list logo
