Re: [Neo] Something fun to try in neo4j : collatz conjecture

Laurent, have you looked at the BatchInserter for doing big initial populations? It is MUCH faster than the normal Neo4j transactional approach, see http://wiki.neo4j.org/content/Indexing_with_BatchInserter Would that help? Cheers, /peter neubauer COO and Sales, Neo Technology GTalk: neub

Re: [Neo] Indexing on Doubles in Neo4j

Last year we wrote a multi-dimensional index for floats, similar in principle to the timeline index, but working on multiple floats (and doubles). We used it to index locations. Now we are hoping to include the same concepts in the new Neo4j Spatialproje

Re: [Neo] Something fun to try in neo4j : collatz conjecture

nope. "The LuceneIndexBatchInserter is designed for being performant when inserting large amounts of data with minimal lookups from the index during that time." problem : i do a lot of lookup while inserting :) -- Ker2x On Tue, Mar 23, 2010 at 10:43 AM, Peter Neubauer wrote: > Laurent, > have

Re: [Neo] Something fun to try in neo4j : collatz conjecture

Awh, kinda not very fast inserting then. From looking at the code, this kinda sux for fast inserting since you need to go in and out of indexes. Not sure how to speed that up. Could you keep some of the index in memory maybe? Cheers, /peter neubauer COO and Sales, Neo Technology GTalk: neu

Re: [Neo] Something fun to try in neo4j : collatz conjecture

Why not use a graph based index? Properly structured it should provide fast reads all the time (property structured kind-of means you have the most likely reads in cache, which is dependant on the type of data). On Tue, Mar 23, 2010 at 10:56 AM, Peter Neubauer wrote: > Awh, > kinda not very fast

Re: [Neo] Something fun to try in neo4j : collatz conjecture

i will try and benchmark :) -- Ker2x On Tue, Mar 23, 2010 at 11:09 AM, Craig Taverner wrote: > Why not use a graph based index? Properly structured it should provide fast > reads all the time (property structured kind-of means you have the most > likely reads in cache, which is dependant on the

[Neo] displaying very large graph

Hi, I'm Gephi main developper. I think Gephi fits to your needs because it can handle very large graphs, and propose innovative layout algorithms. On our 8gb ram machine, we handle 300K nodes and 1.5M edges, rendering is slow but it's still fine. But the problem you're describing is a layout issu

Re: [Neo] Indexing on Doubles in Neo4j

Rick, Thanks for the suggestion, but we need a wider range of measures than those supplied here, so I'm following the tinkerpop team's lead and implementing the JUNG Graph interface, but using traversers under the hood. JUNG has a much fuller set of algorithms and seems to be more actively support

Re: [Neo] Indexing on Doubles in Neo4j

Craig, Please keep me (or just the list) updated on this. Thanks, Alex On Tue, Mar 23, 2010 at 5:43 AM, Craig Taverner wrote: > Last year we wrote a multi-dimensional index for floats, similar in > principle to the timeline index, but working on multiple floats (and > doubles). We used it to i

Re: [Neo] Indexing on Doubles in Neo4j

Interesting, a JUNG adapter would be something that maybe more people are interested in? Cheers, /peter neubauer COO and Sales, Neo Technology GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twit

[Neo] Continuing REST API development

So, we finally got some time on our hands and will put some of that into continuing the development of the Neo4j REST API! Our focus at the moment will be: - GET / will return URIs for creating nodes and the reference node as well as the index starting point. - Indexing: Implement the

Re: [Neo] Continuing REST API development

Cool. While I'm not a complete REST purist, a cautionary suggestion: An HTTP "GET", in general, should never create or mutate anything. PUT and DELETE should/could, or an RPC-ish invocation via POST. And, since some browsers are fickle about supporting PUT/DELETE, a GET with a "hint" parameter

[Neo] Conneg in REST API

Just another thought: if we're going to use multiple representation formats, then we should use content negotiation. Jim ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo] Continuing REST API development

Hi Mattias, > - GET / will return URIs for creating nodes and the reference node as > well as the index starting point. Sounds sensible. What about using Atom feeds as the representation for a node set and AtomPub for handling node creation etc? > - To have a browse:able representation

Re: [Neo] Continuing REST API development

2010/3/23 Jim Webber > Hi Mattias, > > > - GET / will return URIs for creating nodes and the reference node as > > well as the index starting point. > > Sounds sensible. What about using Atom feeds as the representation for a > node set and AtomPub for handling node creation etc? > > > -

Re: [Neo] Continuing REST API development

As tempting (and as necessary) as it might be to do transacted "stuff", there are good ways and bad ways to do it. It is important that each REST-ful invocation be thought of as effectively stateless. That said, using an RPC-like approach where you have atomic invocations to: - Create a unit of

[Neo] Indexing in the REST API

I'm adding indexing to the REST API now and we just come up with a first solution where you POST a node URI to /index/{key}/{value}. What you get back is an "index URI" which is kind of an intermediate URI so that you can do GET on the index URI and get back a node representation, just as if you wo

Re: [Neo] Indexing in the REST API

Why not just process the DELETE on the index URI as a delete on the node URI by doing the lookup/cross-reference on the server side? I heard that Neo4J is pretty good at tracking relationships like that. ;-) -Original Message- From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists

Re: [Neo] Indexing in the REST API

DELETE on a node URI means delete the Node. DELETE on an index URI means remove a particular key-value pair from the index for a Node. i.e. two different things 2010/3/23 Rick Bullotta > Why not just process the DELETE on the index URI as a delete on the node > URI > by doing the lookup/cross-r

Re: [Neo] Indexing in the REST API

Ah, got it. In that case, I would just use an extended URI instead of passing a parameter, as in: If the index URI = /index/MyIndex ...and the node URI = /node/12134 ...the compound URI to delete could be either: /index/MyIndex/node/12134 ...or... /index/MyIndex/12134 Rick -Original Me

Re: [Neo] Indexing in the REST API

What we are fishing for here is some input on how we could get rid of the "index URI". They were added to the design we are working with now for the sole purpose of enabling us to remove a node from an index association. We create index associations for nodes by POSTing the node URI to /index/{key

Re: [Neo] Indexing in the REST API

Make sense. I would plan ahead, however, and allow for more than one index (named indexes, different index types, etc.). As in the previous post, I'd suggest using an extended URI syntax instead of passing URI's as parameters. -Original Message- From: user-boun...@lists.neo4j.org [mailto

Re: [Neo] Indexing in the REST API

2010/3/23 Rick Bullotta > Ah, got it. In that case, I would just use an extended URI instead of > passing a parameter, as in: > > If the index URI = /index/MyIndex > > ...and the node URI = /node/12134 > > ...the compound URI to delete could be either: > > /index/MyIndex/node/12134 > > ...or...

Re: [Neo] Indexing in the REST API

Not sure I'm following the question, but let me take a guess: To find all "indexes": GET /index To find all "nodes in an index" GET /index/IndexName/*/* To find all values for a given key: GET /index/IndexName/key To find all nodes that contain any value for a given key: GET /index/IndexNam

[Neo] New Domain modeling blog post

Hi folks, there is a new post on modeling domain data in Neo4j, http://blog.neo4j.org/2010/03/modeling-categories-in-graph-database.html in case you are interested. Happy hacking! Cheers, /peter neubauer COO and Sales, Neo Technology GTalk: neubauer.peter Skype peter.neubauer Phone

[Neo] Collaboration Neo4j/Gephi (was: displaying very large graph)

Hi! I've had a look at Gephi and it looks really interesting. One particular thing I found interesting is the support for "dynamic graphs". I'm hoping to be able to use that for creating animated sequences of how a traversal moves through a graph. Not only would this be cool for demonstrations, bu

Re: [Neo] Something fun to try in neo4j : collatz conjecture

i ordered a SSD Intel X25-V (114€) According to http://www.anandtech.com/storage/showdoc.aspx?i=3773 it's a very good one, considering the very low price (for a SSD). Not the best (of course), but still faster than my HDD Velociraptor 10krpm. 40GB (~30GB formated) should be enough for all my perso

Re: [Neo] Indexing in the REST API

What I meant was that URIs shouldn't be handcrafted by the client, but instead retrieved (discoverable) from the server. And the original question was if it's ok to send a payload to a DELETE request. In that case the intermediate index URI can be skipped in favor of a URI template which is discov

Re: [Neo] Indexing in the REST API

Below is similar to the way we do "discovery". The results returned from our REST-ful interface are hyperlinks in the case of HTML output, or a collection of strings representing URI's in JSON and XML format. My general feeling is that the primary use for "payloads" should be in POSTs and in RPC-

Re: [Neo] Collaboration Neo4j/Gephi (was: displaying very large graph)

Hi, Yes writing a dynamic GEXF file from the logs you are describing would work. The GEXF dynamic support work like that: for each node or edges you can define one or several time intervals. Intervals can be dates or numbers. Better support and interaction with dynamics is one of the top project's

[Neo] Neo4j meetup on Thu Mar 25 @ Twitter HQ San Francisco

Friends -- If anyone of you are in the San Francisco bay area, please join me at a Neo4j meetup hosted by Twitter on Thursday. It'll be cool. For more info, check out: http://blog.neo4j.org/2010/03/neo4j-meetup-at-twitter-hq-thu-mar-25.html Please join us! Cheers, -- Emil Eifrém, CEO [e...

Re: [Neo] Continuing REST API development

I'm a fan of the AllegroGraph REST API, documented at http://www.franz.com/agraph/support/documentation/current/new-http-server.html. Take a look and see what's in there that you might provide, too. Bill ___ Neo mailing list User@lists.neo4j.org https:/