I'm uncertain about one ambiguity in your model, you are able to find
messages through FOLLOWS and IS_VISIBLE_BY. These will give two different
sets, and my first impression was that FOLLOWS gives you the right answer.
In other words you want to query for 'all messages by users I follow'? In
that
Thanks Craig,
I'd like to clarify my question (I don't think it changes your answer
though).
I wanted all messages visible to me created by users I follow. Thus, the
FOLLOWS relationship is not enough. I'd need to see messages that are
visible to me and then check if they were created by users
Hello,
I'm interested in using neo4j for a content management project. I'd
like to track relationships between content assets (nodes) in order to
search for depending elements.
Furthermore, I'd like to get a set of isolated nodes (incoming =
outgoing relations = 0) for which one can assume that
Hi,
foreach KEY in the lucene index
retrieve the node n
if(degree(n)==0)
found!
should work ...
Lorenzo
On Wed, Mar 17, 2010 at 5:05 PM, Greg Stich grgs...@googlemail.com wrote:
Hello,
I'm interested in using neo4j for a content management project. I'd
like to track relationships
Hi Lincoln,
So it sounds like you don't need the IS_VISIBLE relations after all. The
traverser works by following all relationships of the specified types and
directions from each current node (as you traverse, or walk the graph). You
can have a complex graph and traverse to high depth very fast
And in the java API you can also iterate over the
GraphDatabaseService.getAllNodes result. Could be expensive though.
On Wed, Mar 17, 2010 at 5:14 PM, Lorenzo Livi lorenz.l...@gmail.com wrote:
Hi,
foreach KEY in the lucene index
retrieve the node n
if(degree(n)==0)
found!
should work
Hey,
You might want to consider Blueprints Pipes for a more controlled traverser
framework that doesn't require the use of for-loops and allows you to specify
arbitrary paths through a graph.
http://wiki.github.com/tinkerpop/blueprints/pipes-traversal-framework
For the example
I guess I could say that the approach is totally different, but in reality
you start at the same point, working out what query you want. But after that
things change. Let's consider two cases, the huge network and the paging
examples you used below.
For the first, keep in mind that if you scale
Ok I get it. I keep not thinking about relationships flexibly enough. I
need to take a little time to get used to thinking about problems this way.
Thanks for your help!
On Wed, Mar 17, 2010 at 5:43 PM, Craig Taverner cr...@amanzi.com wrote:
I guess I could say that the approach is totally
Hey Cary
It's a little cheating
But in situtations like this we create TWO relationships to each node
One
NodeA - same_name_rel - NodeB
The other
NodeA - same_name_rel_unique_id - NodeB
This allows easy traversal
Does this make sense?
T
Sent from my iPhone so please excuse typos adn brevity
I notice this file growing rather large during system operation, even though
we are doing very small transactions. It seems that the transaction are
only flushed to the respective node, property, and relationship stores on
shutdown. This of course creates concern, since we are implementing an
Good point :)
In training our new devs (who typically have a RDBC background) it
often takes a leap of understanding for them to realise that whilst a
join is very expensive, creating and traversing a relationship is very
cheap
T
Sent from my iPhone so please excuse typos adn brevity
Tim
This is a cool idea. Seems a bit like the pattern matching stuff in neo4j,
except you setup a traversal pattern. We have done a similar thing in Ruby
with a set of nested closures that each define the starting node for the
traversal of the outer closure, allowing a kind of multi-step traversal (or
Hey Craig,
That looks like this thing called Linq (some Microsoft .NET thing --
http://en.wikipedia.org/wiki/Language_Integrated_Query ). It allows you to
talk all SQL-like using dot notation. I don't know much about it, but seems
super useful for those who like that type of graph searching.
Yes
Sent from my iPhone so please excuse typos adn brevity
Tim Langley
+44 7989 539363
On 17 Mar 2010, at 21:58, Cary Cherng cche...@gmail.com wrote:
So when you say same_name_rel_unique_id do you mean using dynamictypes
since you can't declare these same_name_rel_unique_id types ahead of
I was reminded recently of this 'context switch' between relational and
graph when I asked a group of developers I was training how to structure the
nodes behind a table of results, where each result was a number representing
the number of other results conforming to some criteria. So basically a
Hey Marko,
I've not looked at linq, and am not really a fan of using SQL-like syntax
for non-SQL things. I did take a peek at GQL and did not really like it. Way
too SQL-ish.
This syntax was devised by a developer new to Ruby, so this style is not
specifically Ruby-esque either. However, once I
The original questioner works in Scala where the pipe concept can easily be
expressed using for comprehensions.
val node = index.getSingleNode(id)
for(
i - node.getRelationships(FOLLOWS, OUTGOING) //binds the iteration over the
relations to i
if(i.getProperty(follow_code) != not
I really like that syntax, however I'm concerned that although the intent is
expressed concisely, behind the scenes it's still going to have to traverse
the entire relationship graph. The guards in the for comprehension will
translate to filter() calls but it still has to examine everything in
Hi,
The example I provided is in effect nothing but a couple of nested
iterations, so nothing like a real traversal, but certainly
comparable to the the java pipes or the Gremlin path expressions.
I am working on a Scala based traverser, having higher order
functions makes it possible
20 matches
Mail list logo
