node_auto_index 500 error on query after initial install

[Dave Stern (FiftyThree)]

We have a script that does a fresh install of neo4j for development. After we do this, our web app makes an initial query for nodes that match a certain attribute. This always fails with a 500 error until we manually create an index called "node_auto_index". Should this be filed as a bug report?

[Jacob Hansson]

On Wed, Nov 7, 2012 at 4:55 PM, Dave Stern (FiftyThree) <da...@fiftythree.com> wrote:

We have a script that does a fresh install of neo4j for development. After we do this, our web app makes an initial query for nodes that match a certain attribute. This always fails with a 500 error until we manually create an index called "node_auto_index". Should this be filed as a bug report?

--
 
 

Can you provide the query you send, and also, if possible, the full message returned as part of the 500 error response? It should contain a rather lengthy error message.

/jacob

--
Jacob Hansson
Phone: +46 (0) 763503395
Twitter: @jakewins

[Dave Stern (FiftyThree)]

Here is a slightly modified version of the query from our logs (forgive any punctuation mistakes, the query does work when there is an index):

START nodes=node:node_auto_index('email_indexed:ema...@example.net OR other.email_indexed:ema...@example.net OR other2.email_indexed:ema...@example.net')

RETURN nodes

The response body:

   body:

    { message: 'Index `node_auto_index` does not exist',

      exception: 'MissingIndexException',

      stacktrace:

       [ 'org.neo4j.cypher.internal.executionplan.builders.IndexQueryBuilder.checkNodeIndex(IndexQueryBuilder.scala:53)',

         'org.neo4j.cypher.internal.executionplan.builders.IndexQueryBuilder.createStartPipe(IndexQueryBuilder.scala:80)',

         'org.neo4j.cypher.internal.executionplan.builders.IndexQueryBuilder.apply(IndexQueryBuilder.scala:37)',

         'org.neo4j.cypher.internal.executionplan.ExecutionPlanImpl.prepareExecutionPlan(ExecutionPlanImpl.scala:46)',

         'org.neo4j.cypher.internal.executionplan.ExecutionPlanImpl.<init>(ExecutionPlanImpl.scala:32)',

         'org.neo4j.cypher.ExecutionEngine$$anonfun$prepare$1.apply(ExecutionEngine.scala:61)',

         'org.neo4j.cypher.ExecutionEngine$$anonfun$prepare$1.apply(ExecutionEngine.scala:61)',

         'org.neo4j.cypher.internal.LRUCache.getOrElseUpdate(LRUCache.scala:31)',

         'org.neo4j.cypher.ExecutionEngine.prepare(ExecutionEngine.scala:61)',

         'org.neo4j.cypher.ExecutionEngine.execute(ExecutionEngine.scala:55)',

         'org.neo4j.cypher.ExecutionEngine.execute(ExecutionEngine.scala:58)',

         'org.neo4j.cypher.javacompat.ExecutionEngine.execute(ExecutionEngine.java:86)',

         'org.neo4j.server.rest.web.CypherService.cypher(CypherService.java:79)',

         'java.lang.reflect.Method.invoke(Method.java:597)' ] } }

[Wes Freeman]

Just checking: Do the 500 errors continue after you restart the neo4j service?

Wes

--
 
 

[Dave Stern (FiftyThree)]

No! Great call.  So why does restarting resolve the issue?

On Thursday, November 8, 2012 4:24:04 PM UTC-5, Wes Freeman wrote:

Just checking: Do the 500 errors continue after you restart the neo4j service?

Wes

On Thu, Nov 8, 2012 at 4:19 PM, Dave Stern (FiftyThree) <da...@fiftythree.com> wrote:

Here is a slightly modified version of the query from our logs (forgive any punctuation mistakes, the query does work when there is an index):

START nodes=node:node_auto_index('email_indexed:ema...@example.net OR other.email_i...@example.net OR other2.email_...@example.net')

--
 
 

[Dave Stern (FiftyThree)]

Actually, premature response. I had to reset everything and then restart. The errors do persist. False alarm on the solution. Sorry.

[Michael Hunger]

I think the issue is from a change in the neo4j internals that don't cause indexes to be created by default (without anything stored in them) before the first getIndex() is called, and as cypher checks upfront if the index is there ....

I think for the auto-indexes that they should be created at db-startup even if there is nothing in there.

I hit the same issue with the console.

A workaround is to add an indexed property to (for instance the root node, and remove it again).

start n=node(0)  

set n.name='foo' 

delete n.name 

return n

Did you raise an github issue about it?

Thanks

Michael

--
 
 

[Dave Stern (FiftyThree)]

I just added it, thank you for the workaround.

[Aran Mulholland]

Michael,

Is it enough to add any indexed property to the node, or would you have to add an indexed property for every indexed property you have in the graph?

For example if you were indexing on both name and email

would you have to 

start n=node(0)  

set n.name='foo' 

set n.email='foo' 

delete n.name

delete n.email 

return n

--
 
 

[Michael Hunger]

It is only to create the index, so one property is enough.

Michael

--
 
 

[Aran Mulholland]

Thanks Michael

So just so my understanding is correct: 

1. The node_auto_index is one index but it exists for multiple properties.

2. Creating any of the properties that the node_auto_index indexes will create the index for all properties.

3. After this index if created running the command 

eval db.index().getNodeAutoIndexer().isEnabled()

should return true.

(please correct me if I'm wrong, I'd like to grok this)

Thanks

--
 
 

[Michael Hunger]

Excactly,

actually 

db.index().getNodeAutoIndexer().setEnabled(true) 

should already create the index, so that it is available for use (e.g. by cypher) in the first place.

Michael

--