On Friday, September 3, 2010, <[email protected]> wrote: > 1. They are "durable" but not "permanent", in the sense that if a node > is deleted, its ID will be re-used, unlike autoincremented keys in a > database, which are typically not re-used. Perhaps a poor choice of > words. >
In fact if I'm reading this right, they are both durable and permanent: as long as the node exist it will always be associated with that ID. The only caveat is that IDs can be reused once their initial node was purged from the system. This is a very important aspect as I can imagine many systems that can use a small subset of the existing nodes as entry points. Basically by using the cached IDs you'll be able to get to these without the need of using indexing/traversals. > > 3. Third parameter = value of the K-V pair you're using to index the > node. > I figured that out myself, but I still believe that the new method I've suggested would be welcome. Real question is: how many time you store a set of properties in the node, but want to index it by a completely unrelated/not persistent value? I'd speculate that this scenario is very very rare. > > 4. The reference node is merely one approach to a graph structure. > You can have any number of standalone nodes. Reasonable to allow > deleting the default reference node, though it might be a good idea to > make this a configurable option on DB creation. > If the "reference node" is not mandatory then why creating it by default? If you take as a reference the most well known hierarchical model, the FS, there it makes a lot of sense to have a root node (which is undeletable). But as I read this and noticed from the tests, the Neo4j "reference node" serves no purpose at all. > > > 5/6. Haven't done much with Lucene yet, about to get started soon. > Please keep sharing your experiences. Considering whether or not to > use SOLR, also. > I want to keep things as simple as possible, so for my current experiments I'll not look beyond what is already available in Neo4j. This aside, if I'd be to look into using a 3rd party indexing tool, my first option would be ElasticSearch (disclaimer: I do know the lead developer of ElasticSearch and his experience in indexing tools). I hope others will jump in and comment/answer on my suggestions and questions. Thanks, :- alex > > > -------- Original Message -------- > Subject: [Neo4j] API Questions and a bit more > From: Alexandru_Popescu_â <[1][email protected]> > Date: Fri, September 03, 2010 4:53 am > To: [2][email protected] > Hi all, > Last night I had some time to play with Neo4j (1.1) API. I do have a > couple of questions and comments that I'd like to share with you: > 1. The documentation I've found mentions that `Node` IDs are not > "permanent". I'm wondering why are IDs exposed them? > 2. I was surprised to see a `Node`.delete() failing. The reason was it > had relationships. I think adding a method `Node`.delete(boolean > force) would > make code much easier. The method would automatically: > - remove all relationships > - clean up indexes > Note 1: I've been able to implement locally such a method in an > utility class and it seems to work without any problems. Anyways > another thing that I've found a bit weird was that I had to use > separate reference to GraphDatabaseService and 2 IndexServices (a > simple LuceneIndexService and a LuceneFulltextIndexService). I think > it would once again simplify a lot of things if these IndexServices > would be available through the GraphDatabaseService API. > Note 2: as far as I can say this would be a non-breaking API change > 3. I was a bit confused when trying to index a new node as I wasn't > sure what's the last parameter in `IndexService.index(Node, String, > Object)`. > While understanding the flexibility this would offer, I'd speculate > that most of the time you'd want to actually index the values set in > the Node, so an > API like `IndexService.index(Node, String... properties)` would once > again simplify a lot of code. > Note: as far as I can say this is a non-breaking API change > 4. Q: while running my tests, I've tried to clean up data behind. Thus > I've discovered that I can delete the so called "reference node". That > made me wonder: if it is a default node, why allowing to be deleted? > 5. Q: by looking at the documentation I couldn't figure out for sure > if you are allowed to use both a LuceneIndexService and > LuceneFullIndexService. My tests seem to work while using both, but > I'm not sure if that is what's suppose to happen. > 6. I've run into a test where LuceneFullIndexService doesn't seem to > return what I'm expecting. But I'm not a Lucene specialist so maybe > I'm doing something wrong. Code below: > package com.mypopescu.neo4j; > import org.junit.AfterClass; > import org.junit.BeforeClass; > import org.junit.Test; > import org.neo4j.graphdb.GraphDatabaseService; > import org.neo4j.graphdb.Node; > import org.neo4j.graphdb.Relationship; > import org.neo4j.graphdb.Transaction; > import org.neo4j.index.IndexHits; > import org.neo4j.index.IndexService; > import org.neo4j.index.lucene.LuceneFulltextIndexService; > import org.neo4j.kernel.EmbeddedGraphDatabase; > import [3]java.io.File; > import static [4]org.hamcrest.CoreMatchers.is; > import static org.junit.Assert.assertThat; > /** > * @author Alex Popescu > * @since Sep 3, 2010 > */ > public class LuceneFulltextIndexServiceTest { > static GraphDatabaseService gds; > static IndexService fulltextIndex; > @BeforeClass > public static void setup() { > gds= new EmbeddedGraphDatabase("data/neodb/neodb-tmp"); > fulltextIndex= new LuceneFulltextIndexService(gds); > } > @Test > public void fullTextIndex() { > Transaction tx= gds.beginTx(); > try { > Node ndOne= gds.createNode(); > ndOne.setProperty("ft", "some text in here to be fully indexed"); > fulltextIndex.index(ndOne, "ft", ndOne.getProperty("ft")); > Node ndTwo= gds.createNode(); > ndTwo.setProperty("ft", "some other text in there not to > be indexed uniquely"); > fulltextIndex.index(ndTwo, "ft", ndTwo.getProperty("ft")); > tx.success(); > } > finally { > tx.finish(); > } > IndexHits<Node> ns= fulltextIndex.getNodes("ft", "some text"); > assertThat(ns.size(), is(2)); > for(Node n : ns) { > System.out.printf("Full text n...@%s: {%s}%n", n.getId(), > n.getProperty("ft")); > } > ns= fulltextIndex.getNodes("ft", "some text indexed"); > assertThat(ns.size(), is(2)); > for(Node n : ns) { > System.out.printf("Full text n...@%s: {%s}%n", n.getId(), > n.getProperty("ft")); > } > ns= fulltextIndex.getNodes("ft", "indexed text"); > assertThat(ns.size(), is(2)); > for(Node n : ns) { > System.out.printf("Full text n...@%s: {%s}%n", n.getId(), > n.getProperty("ft")); > } > ns= fulltextIndex.getNodes("ft", "uniquely text"); > assertThat(ns.size(), is(1)); > for(Node n : ns) { > System.out.printf("Full text n...@%s: {%s}%n", n.getId(), > n.getProperty("ft")); > } > // THIS ONE IS FAILING > ns= fulltextIndex.getNodes("ft", "uniquely OR text"); > assertThat("actually it should find 2", ns.size(), is(2)); > for(Node n : ns) { > System.out.printf("Full text n...@%s: {%s}", n.getId(), > n.getProperty("ft")); > } > } > @AfterClass > public static void shutdown() { > fulltextIndex.shutdown(); > gds.shutdown(); > } > } > 7. I was wondering what is the best way to clean up a temporary test > database. > My apologies in advance for such a long email (I usually don't do > this). And thanks in advance for all your answers, > :- alex > _______________________________________________ > Neo4j mailing list > [5][email protected] > [6]https://lists.neo4j.org/mailman/listinfo/user > > References > > 1. mailto:[email protected] > 2. mailto:[email protected] > 3. http://java.io/ > 4. http://org.hamcrest.CoreMatchers.is/ > 5. mailto:[email protected] > 6. https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
