Running Cypher query. - Githubissues

Hi,

I used this library to create my neo4j graph and it worked well.

Now, I would like to query it thanks to a cypher query. The fact is I would like to run this query :

    START d=node(47), e=node(98)
MATCH p = shortestPath( d-[*..15]->e )
RETURN p;

But I always got this error when I'm executing it thanks to the library

      throw arguments[0];
                   ^
TypeError: Cannot call method 'replace' of undefined
at Neo4j.addNodeId (/Users/guillaumelefloch/Documents/workspace/Projet-           BMA/BmaServeur/node_modules/node-neo4j/main.js:350:25)
at Neo4j.cypherQuery.request.post.set.send.end.result.body.data (/Users/guillaumelefloch/Documents/workspace/Projet-BMA/BmaServeur/node_modules/node-neo4j/main.js:307:42)
at Array.forEach (native)
at Function.addIds (/Users/guillaumelefloch/Documents/workspace/Projet-BMA/BmaServeur/node_modules/node-neo4j/main.js:306:50)
at next (/Users/guillaumelefloch/Documents/workspace/Projet-BMA/BmaServeur/node_modules/node-neo4j/node_modules/step/lib/step.js:51:23)
at Step (/Users/guillaumelefloch/Documents/workspace/Projet-BMA/BmaServeur/node_modules/node-neo4j/node_modules/step/lib/step.js:122:3)
at Request.Neo4j.cypherQuery [as callback] (/Users/guillaumelefloch/Documents/workspace/Projet-BMA/BmaServeur/node_modules/node-neo4j/main.js:303:25)
at Request.<anonymous> (/Users/guillaumelefloch/Documents/workspace/Projet-BMA/BmaServeur/node_modules/node-neo4j/node_modules/superagent/lib/node/index.js:130:10)
at Request.EventEmitter.emit (events.js:96:17)
at IncomingMessage.Request.end (/Users/guillaumelefloch/Documents/workspace/Projet-BMA/BmaServeur/node_modules/node-neo4j/node_modules/superagent/lib/node/index.js:566:12)

Do you know what could my problem be? and if there is an other to realise what I want?

Thanks!

I'll investigate that this evening, let me get back to you.

Thanks! I looked at the main.js file but I did'nt see anything wrong ... On Feb 2, 2013 12:31 PM, "Philipp Küng" notifications@github.com wrote:

I'll investigate that this evening, let me get back to you.

— Reply to this email directly or view it on GitHubhttps://github.com/philippkueng/node-neo4j/issues/2#issuecomment-13028123.

Well it's not wrong but the resultset of a cypher query returning nodes and one returning relationships look rather different. After the library gets the response it does some manipulation to make it easier to work with, eg. adds an id property. For creating this id it needs the self property which is not available with cypher queries returning relationships. It does this work in the addNodeId function.

Normal Response

{
    "columns": ["friends"],
    "data": [
        [{
            "outgoing_relationships": "http://localhost:7474/db/data/node/380/relationships/out",
            "data": {
                "name": "foobar2"
            },
            "traverse": "http://localhost:7474/db/data/node/380/traverse/{returnType}",
            "all_typed_relationships": "http://localhost:7474/db/data/node/380/relationships/all/{-list|&|types}",
            "property": "http://localhost:7474/db/data/node/380/properties/{key}",
            "self": "http://localhost:7474/db/data/node/380",
            "properties": "http://localhost:7474/db/data/node/380/properties",
            "outgoing_typed_relationships": "http://localhost:7474/db/data/node/380/relationships/out/{-list|&|types}",
            "incoming_relationships": "http://localhost:7474/db/data/node/380/relationships/in",
            "extensions": {},
            "create_relationship": "http://localhost:7474/db/data/node/380/relationships",
            "paged_traverse": "http://localhost:7474/db/data/node/380/paged/traverse/{returnType}{?pageSize,leaseTime}",
            "all_relationships": "http://localhost:7474/db/data/node/380/relationships/all",
            "incoming_typed_relationships": "http://localhost:7474/db/data/node/380/relationships/in/{-list|&|types}"
        }],
        [{
            "outgoing_relationships": "http://localhost:7474/db/data/node/381/relationships/out",
            "data": {
                "name": "foobar3"
            },
            "traverse": "http://localhost:7474/db/data/node/381/traverse/{returnType}",
            "all_typed_relationships": "http://localhost:7474/db/data/node/381/relationships/all/{-list|&|types}",
            "property": "http://localhost:7474/db/data/node/381/properties/{key}",
            "self": "http://localhost:7474/db/data/node/381",
            "properties": "http://localhost:7474/db/data/node/381/properties",
            "outgoing_typed_relationships": "http://localhost:7474/db/data/node/381/relationships/out/{-list|&|types}",
            "incoming_relationships": "http://localhost:7474/db/data/node/381/relationships/in",
            "extensions": {},
            "create_relationship": "http://localhost:7474/db/data/node/381/relationships",
            "paged_traverse": "http://localhost:7474/db/data/node/381/paged/traverse/{returnType}{?pageSize,leaseTime}",
            "all_relationships": "http://localhost:7474/db/data/node/381/relationships/all",
            "incoming_typed_relationships": "http://localhost:7474/db/data/node/381/relationships/in/{-list|&|types}"
        }]
    ]
}

Response when asking for relationships

{
    "columns": ["p"],
    "data": [
        [{
            "start": "http://localhost:7474/db/data/node/57",
            "nodes": ["http://localhost:7474/db/data/node/57", "http://localhost:7474/db/data/node/56", "http://localhost:7474/db/data/node/55"],
            "length": 2,
            "relationships": ["http://localhost:7474/db/data/relationship/26", "http://localhost:7474/db/data/relationship/27"],
            "end": "http://localhost:7474/db/data/node/55"
        }]
    ]
}

There are now two options, one is to simply return the different resultset as is. Which makes it hard and inconsistent to work with or options two where we make subsequent queries for each relationship giving you back all the attributes. Option 2 however is far slower. What's your use case?

It's a routing graph for a french city. The goal is get bus lines and bus stops for a itineary.

How could we make the first option work? I can manage the parsing in the server.

However if the second option is not hard to fix I will use it. is that much more slower?

I still don't get why it's not working for me.. On Feb 2, 2013 1:59 PM, "Philipp Küng" notifications@github.com wrote:

Well it's not wrong but the resultset of a cypher query returning nodes and one returning relationships look rather different. After the library gets the response it does some manipulation to make it easier to work with, eg. adds an id property. For creating this id it needs the self property which is not available with cypher queries returning relationships. It does this work in the addNodeId function.

Normal Response

{ "columns": ["friends"], "data": [ [{ "outgoing_relationships": "http://localhost:7474/db/data/node/380/relationships/out", "data": { "name": "foobar2" }, "traverse": "http://localhost:7474/db/data/node/380/traverse/{returnType}", "all_typed_relationships": "http://localhost:7474/db/data/node/380/relationships/all/{-list|&|types}", "property": "http://localhost:7474/db/data/node/380/properties/{key}", "self": "http://localhost:7474/db/data/node/380", "properties": "http://localhost:7474/db/data/node/380/properties", "outgoing_typed_relationships": "http://localhost:7474/db/data/node/380/relationships/out/{-list|&|types}", "incoming_relationships": "http://localhost:7474/db/data/node/380/relationships/in", "extensions": {}, "create_relationship": "http://localhost:7474/db/data/node/380/relationships", "paged_traverse": "http://localhost:7474/db/data/node/380/paged/traverse/{returnType}{?pageSize,leaseTime}", "all_relationships": "http://localhost:7474/db/data/node/380/relationships/all", "incoming_typed_relationships": "http://localhost:7474/db/data/node/380/relationships/in/{-list|&|types}" }], [{ "outgoing_relationships": "http://localhost:7474/db/data/node/381/relationships/out", "data": { "name": "foobar3" }, "traverse": "http://localhost:7474/db/data/node/381/traverse/{returnType}", "all_typed_relationships": "http://localhost:7474/db/data/node/381/relationships/all/{-list|&|types}", "property": "http://localhost:7474/db/data/node/381/properties/{key}", "self": "http://localhost:7474/db/data/node/381", "properties": "http://localhost:7474/db/data/node/381/properties", "outgoing_typed_relationships": "http://localhost:7474/db/data/node/381/relationships/out/{-list|&|types}", "incoming_relationships": "http://localhost:7474/db/data/node/381/relationships/in", "extensions": {}, "create_relationship": "http://localhost:7474/db/data/node/381/relationships", "paged_traverse": "http://localhost:7474/db/data/node/381/paged/traverse/{returnType}{?pageSize,leaseTime}", "all_relationships": "http://localhost:7474/db/data/node/381/relationships/all", "incoming_typed_relationships": "http://localhost:7474/db/data/node/381/relationships/in/{-list|&|types}" }] ] }

Response when asking for relationships

{ "columns": ["p"], "data": [ [{ "start": "http://localhost:7474/db/data/node/57", "nodes": ["http://localhost:7474/db/data/node/57", "http://localhost:7474/db/data/node/56", "http://localhost:7474/db/data/node/55"], "length": 2, "relationships": ["http://localhost:7474/db/data/relationship/26", "http://localhost:7474/db/data/relationship/27"], "end": "http://localhost:7474/db/data/node/55" }] ] }

There are now two options, one is to simply return the different resultset as is. Which makes it hard and inconsistent to work with or options two where we make subsequent queries for each relationship giving you back all the attributes. Option 2 however is far slower. What's your use case?

— Reply to this email directly or view it on GitHubhttps://github.com/philippkueng/node-neo4j/issues/2#issuecomment-13029202.

Let me check how much slower it is. Will implement a fix this evening that shouldn't change the API.

Something completely different, have you seen GTFS? It might be covering your current use case plus is currently used by many transport companies, so it's pretty robust.

On Saturday, February 2, 2013, glefloch wrote:

It's a routing graph for a french city. The goal is get bus lines and bus stops for a itineary.

How could we make the first option work? I can manage the parsing in the server.

However if the second option is not hard to fix I will use it. is that much more slower?

I still don't get why it's not working for me.. On Feb 2, 2013 1:59 PM, "Philipp Küng" <notifications@github.com<javascript:_e({}, 'cvml', 'notifications@github.com');>> wrote:

Well it's not wrong but the resultset of a cypher query returning nodes and one returning relationships look rather different. After the library gets the response it does some manipulation to make it easier to work with, eg. adds an id property. For creating this id it needs the self property which is not available with cypher queries returning relationships. It does this work in the addNodeId function.

Normal Response

{ "columns": ["friends"], "data": [ [{ "outgoing_relationships": " http://localhost:7474/db/data/node/380/relationships/out", "data": { "name": "foobar2" }, "traverse": " http://localhost:7474/db/data/node/380/traverse/{returnType}", "all_typed_relationships": " http://localhost:7474/db/data/node/380/relationships/all/{-list|&|types}",

"property": "http://localhost:7474/db/data/node/380/properties/{key}", "self": "http://localhost:7474/db/data/node/380", "properties": "http://localhost:7474/db/data/node/380/properties", "outgoing_typed_relationships": " http://localhost:7474/db/data/node/380/relationships/out/{-list|&|types}",

"incoming_relationships": " http://localhost:7474/db/data/node/380/relationships/in", "extensions": {}, "create_relationship": " http://localhost:7474/db/data/node/380/relationships", "paged_traverse": " http://localhost:7474/db/data/node/380/paged/traverse/{returnType}{?pageSize,leaseTime}",

"all_relationships": " http://localhost:7474/db/data/node/380/relationships/all", "incoming_typed_relationships": " http://localhost:7474/db/data/node/380/relationships/in/{-list|&|types}" }], [{ "outgoing_relationships": " http://localhost:7474/db/data/node/381/relationships/out", "data": { "name": "foobar3" }, "traverse": " http://localhost:7474/db/data/node/381/traverse/{returnType}", "all_typed_relationships": " http://localhost:7474/db/data/node/381/relationships/all/{-list|&|types}",

"property": "http://localhost:7474/db/data/node/381/properties/{key}", "self": "http://localhost:7474/db/data/node/381", "properties": "http://localhost:7474/db/data/node/381/properties", "outgoing_typed_relationships": " http://localhost:7474/db/data/node/381/relationships/out/{-list|&|types}",

"incoming_relationships": " http://localhost:7474/db/data/node/381/relationships/in", "extensions": {}, "create_relationship": " http://localhost:7474/db/data/node/381/relationships", "paged_traverse": " http://localhost:7474/db/data/node/381/paged/traverse/{returnType}{?pageSize,leaseTime}",

"all_relationships": " http://localhost:7474/db/data/node/381/relationships/all", "incoming_typed_relationships": " http://localhost:7474/db/data/node/381/relationships/in/{-list|&|types}" }] ] }

Response when asking for relationships

{ "columns": ["p"], "data": [ [{ "start": "http://localhost:7474/db/data/node/57", "nodes": ["http://localhost:7474/db/data/node/57", " http://localhost:7474/db/data/node/56", " http://localhost:7474/db/data/node/55"], "length": 2, "relationships": ["http://localhost:7474/db/data/relationship/26", " http://localhost:7474/db/data/relationship/27"], "end": "http://localhost:7474/db/data/node/55" }] ] }

There are now two options, one is to simply return the different resultset as is. Which makes it hard and inconsistent to work with or options two where we make subsequent queries for each relationship giving you back all the attributes. Option 2 however is far slower. What's your use case?

— Reply to this email directly or view it on GitHub< https://github.com/philippkueng/node-neo4j/issues/2#issuecomment-13029202>.

— Reply to this email directly or view it on GitHubhttps://github.com/philippkueng/node-neo4j/issues/2#issuecomment-13029317.

Yes in fact some of the data are gtfs data that a add into a sql table. And some others data are added thanks to an API.. I used a graph cause it was one of the goal of the project..

And I used nodejs cause it seems really cool and I want to learn it! On Feb 2, 2013 2:17 PM, "Philipp Küng" notifications@github.com wrote:

Let me check how much slower it is. Will implement a fix this evening that shouldn't change the API.

Something completely different, have you seen GTFS? It might be covering your current use case plus is currently used by many transport companies, so it's pretty robust.

On Saturday, February 2, 2013, glefloch wrote:

It's a routing graph for a french city. The goal is get bus lines and bus stops for a itineary.

How could we make the first option work? I can manage the parsing in the server.

However if the second option is not hard to fix I will use it. is that much more slower?

I still don't get why it's not working for me.. On Feb 2, 2013 1:59 PM, "Philipp Küng" <notifications@github.com<javascript:_e({}, 'cvml', 'notifications@github.com');>> wrote:

Well it's not wrong but the resultset of a cypher query returning nodes and one returning relationships look rather different. After the library gets the response it does some manipulation to make it easier to work with, eg. adds an id property. For creating this id it needs the self property which is not available with cypher queries returning relationships. It does this work in the addNodeId function.

Normal Response

{ "columns": ["friends"], "data": [ [{ "outgoing_relationships": " http://localhost:7474/db/data/node/380/relationships/out", "data": { "name": "foobar2" }, "traverse": " http://localhost:7474/db/data/node/380/traverse/{returnType}", "all_typed_relationships": " http://localhost:7474/db/data/node/380/relationships/all/{-list|&|types}",

"property": "http://localhost:7474/db/data/node/380/properties/{key}",

"self": "http://localhost:7474/db/data/node/380", "properties": "http://localhost:7474/db/data/node/380/properties", "outgoing_typed_relationships": " http://localhost:7474/db/data/node/380/relationships/out/{-list|&|types}",

"incoming_relationships": " http://localhost:7474/db/data/node/380/relationships/in", "extensions": {}, "create_relationship": " http://localhost:7474/db/data/node/380/relationships", "paged_traverse": "

http://localhost:7474/db/data/node/380/paged/traverse/{returnType}{?pageSize,leaseTime}",

"all_relationships": " http://localhost:7474/db/data/node/380/relationships/all", "incoming_typed_relationships": " http://localhost:7474/db/data/node/380/relationships/in/{-list|&|types}"

}], [{ "outgoing_relationships": " http://localhost:7474/db/data/node/381/relationships/out", "data": { "name": "foobar3" }, "traverse": " http://localhost:7474/db/data/node/381/traverse/{returnType}", "all_typed_relationships": " http://localhost:7474/db/data/node/381/relationships/all/{-list|&|types}",

"property": "http://localhost:7474/db/data/node/381/properties/{key}",

"self": "http://localhost:7474/db/data/node/381", "properties": "http://localhost:7474/db/data/node/381/properties", "outgoing_typed_relationships": " http://localhost:7474/db/data/node/381/relationships/out/{-list|&|types}",

"incoming_relationships": " http://localhost:7474/db/data/node/381/relationships/in", "extensions": {}, "create_relationship": " http://localhost:7474/db/data/node/381/relationships", "paged_traverse": "

http://localhost:7474/db/data/node/381/paged/traverse/{returnType}{?pageSize,leaseTime}",

"all_relationships": " http://localhost:7474/db/data/node/381/relationships/all", "incoming_typed_relationships": " http://localhost:7474/db/data/node/381/relationships/in/{-list|&|types}"

}] ] }

Response when asking for relationships

{ "columns": ["p"], "data": [ [{ "start": "http://localhost:7474/db/data/node/57", "nodes": ["http://localhost:7474/db/data/node/57", " http://localhost:7474/db/data/node/56", " http://localhost:7474/db/data/node/55"], "length": 2, "relationships": ["http://localhost:7474/db/data/relationship/26", " http://localhost:7474/db/data/relationship/27"], "end": "http://localhost:7474/db/data/node/55" }] ] }

There are now two options, one is to simply return the different resultset as is. Which makes it hard and inconsistent to work with or options two where we make subsequent queries for each relationship giving you back all the attributes. Option 2 however is far slower. What's your use case?

— Reply to this email directly or view it on GitHub<

https://github.com/philippkueng/node-neo4j/issues/2#issuecomment-13029202>.

— Reply to this email directly or view it on GitHub< https://github.com/philippkueng/node-neo4j/issues/2#issuecomment-13029317>.

— Reply to this email directly or view it on GitHubhttps://github.com/philippkueng/node-neo4j/issues/2#issuecomment-13029375.

Ah ok, interesting.

As a solution to our problem I suggest implementing REST API Batch operations. Basically when running a cypher query returning only links to relationships, as your current query is doing, it's making another request. This time a batch request fetching all the data for each relationship in one go, since that's most likely what you want anyway. Since this subsequent request is only a single one it should be fairly fast.

I'll be home in about two-to-three hours and will start to implement the fix.

Oh ok Great Thank you very much!!!

On 2 February 2013 18:42, Philipp Küng notifications@github.com wrote:

Ah ok, interesting.

As a solution to our problem I suggest implementing REST API Batch operations. Basically when running a cypher query returning only links to relationships, as your current query is doing, it's making another request. This time a batch request fetching all the data for each relationship in one go, since that's most likely what you want anyway. Since this subsequent request is only a single one it should be fairly fast.

I'll be home in about two-to-three hours and will start to implement the fix.

— Reply to this email directly or view it on GitHubhttps://github.com/philippkueng/node-neo4j/issues/2#issuecomment-13034181.

Hi @glefloch

Have worked on your issue. I'm fully there yet but at least it's not throwing an error anymore with your query.

About the batch thing, it still needs a bit of refinement which i'm probably getting to tomorrow or over the coming week. (hope tomorrow though :)

The newest release with the fix in it is 1.0.1. I'll keep you posted about the rest.

Ok great thanks you very I can work without the batch thing don't worry about it.

I just have a question, can we update npm package or do we have to remove them and then reinstall them? Thank you! On Feb 2, 2013 11:38 PM, "Philipp Küng" notifications@github.com wrote:

Hi @glefloch https://github.com/glefloch

Have worked on your issue. I'm fully there yet but at least it's not throwing an error anymore with your query.

About the batch thing, it still needs a bit of refinement which i'm probably getting to tomorrow or over the coming week. (hope tomorrow though :)

The newest release with the fix in it is 1.0.1. I'll keep you posted about the rest.

— Reply to this email directly or view it on GitHubhttps://github.com/philippkueng/node-neo4j/issues/2#issuecomment-13038649.

Just define the new version in your package.json file which is being generated when you run npm init. Then issue npm update and npm check updates all your packages to the newest version declared. Alternatively, remove node-neo4j from your node_modules folder and install it again, then npm should fetch the last version by itself.

Ok great thank you! I will do this tonight On Feb 3, 2013 11:10 AM, "Philipp Küng" notifications@github.com wrote:

Just define the new version in your package.json file which is being generated when you run npm init. Then issue npm update and npm check updates all your packages to the newest version declared. Alternatively, remove node-neo4j from your node_modules folder and install it again, then npm should fetch the last version by itself.

— Reply to this email directly or view it on GitHubhttps://github.com/philippkueng/node-neo4j/issues/2#issuecomment-13044875.

Hi @glefloch,

I've now added batch query functionality in version 1.0.2 just now. However in case you want to use it in conjunction with the cypher query response you need to write the batch query in your code yourself, because cypher and batch query results can be very different, so that any automatic post processing within node-neo4j is prone to fail.

Let me know in case you need any further help.

philippkueng / node-neo4j

Running Cypher query. #2