Hi there,
as both Rick and Michael say - there is different use cases, different
ways of organizing your data and different ways to query it.
Marko and me tried to summarize what is working especially good with
Graph Databases and what not:
You could perhaps use the LuceneFulltextQueryIndexService (which is a
LuceneFulltextIndexService, but which interprets the value argument in
getNodes() as lucene query
syntaxhttp://lucene.apache.org/java/2_9_1/queryparsersyntax.html).
Index your URI|time as a one concatenated value and query it
There are some problems at the moment regarding insertion speeds.
o We haven't yet created an rdf store which can use a BatchInserter (which
could also be tweaked to ignore checking if statements already exists before
it adds each statement and all that).
o The other one is that the sail layer on
I definitely agree that limiting or paging a set of results is probably not
very useful without some sort of sorting. The (only) benefit of pushing
sorting to the client is that the client might be able to filter the result
further before sorting it. Since sorting is generally the most expensive
Hi,
Sorry for the much delayed response.
First a disclaimer:
Neo4j makes no claim to magically make P=NP (the problem of finding a
minimal dominating set is NP-hard), it would be cool if Neo4j could be used
to prove such a thing, but I am not going to spend the rest of my life
attempting it.
I
Now we're getting somewhere... I like this solution a lot, thanks for the
great idea. Let me see if I get time to try and implement it soon! Or if you
get to if before me and supply a patch. It's nice either way :)
2010/4/9 Niels Hoogeveen pd_aficion...@hotmail.com
Having thought about
Since in manycases the results of a query will need to be reformed into
their associated domain objects, we've chosen to do our sorting at that
point (and on the server). We do our (primary) filtering within the
traversal/DB-domain object processes. That seems to work well.
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
On 9 April 2010 14:21, Max De Marzi Jr. maxdema...@gmail.com wrote:
On first traversal, add a relationship to a found node to each node that
would return, and check for this relationship on the second traversal?
Maybe create a unique id, set a property or add a node property with the
unique
Alastair James schrieb am 09.04.2010 um 14:04:37 (+0100)
[Re: [Neo] How to efficiently query in Neo4J?]:
So, I suppose this question boils down to, is there an efficient way
to calculate the union of two traversals without retrieving all result
sets and performing the union in user code?
No
In a previous post, I suggested a two-way traversal (I guess it's
actually a traversal done once in one direction and n-1 times in the
other direction, where n = number of tags you're matching posts on).
I'm willing to bet it could be pretty fast...
Do you have any code that
12 matches
Mail list logo
