cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.

Query with multiline string not interpreted by neo4j browser

Hi there, I'm currently trying to run a multi-line query through an apoc's iterate function (targetting 70M nodes hence the need).

I encounter a weird situation when trying to launch the query from the browser, it seems that the multi-line induces a bad interpretation of the script.

Here is the code I'm trying to run, and below that is the rendering of the browser :

CALL apoc.periodic.iterate(
"MATCH (p:RABBIT)",
"SET p.mail = REDUCE(s = '', c IN split(p.mail,'') |
	s + CASE c
      WHEN '-' THEN '@'
      ELSE c
    END
)", {batchSize:100, iterateList:true, parallel:true})

2X_d_d722f793cbff5aebe309811eca442693b91f08ee.png

The upcomming error, if one needed to see it ... No surprise in it since the parenthesis is not well interpreted.

Has anyone already encountered this situation ? Or could one try to reproduce it ?
A similar issue seems to have been raised here : https://github.com/neo4j/neo4j-browser/issues/924, but according to the OP it didn't affect the final result, more like a visual glitch.

Thanks in advance,

2 REPLIES 2

shan
Graph Buddy

Yes I have seen this before. You can have a multi-line cypher but you cannot have a multi-line string value unless you use + to concatenate them. Here's an example:

CALL apoc.periodic.iterate(
"MATCH (t:Test) return t",
"SET " +
"t.type=1", {batchSize:100, iterateList:true, parallel:true})

I personally just keep the whole string in one line.

Alright kinda disapointing, even more since I actually have more than 20 lines of conditions in my CASE querystring. But thanks for the reply

I hope this little issue gets fixed in the future.

EDIT: Reason found ! It was actually a mistake on my side in the 1st inner argument of the apoc function, I forgot to RETURN the variable p onto wich works the 2nd argument.

CONCLUSION : There is indeed a graphic bug, but it doesn't affect the overall query processing !