Been trying to debug a problem I am having.
Added to Server:
Meteor.N4JDB.listen(function(query, opts){
console.log('Incoming query: ' + query, opts);
});
Which shows:
I20150921-01:17:13.550(0)? Incoming query: MATCH (person:Person) WHERE ID(person)= { id } RETURN person { id: '66' }
I20150921-01:17:13.599(0)? Exception in callback of async function: Error: [Meteor.neo4j.run]: [500]
I20150921-01:17:13.599(0)? at packages/ostrio:neo4jreactivity/driver.coffee:659:21
I20150921-01:17:13.599(0)? at packages/ostrio:neo4jreactivity/driver.coffee:7:12
I20150921-01:17:13.599(0)? at runWithEnvironment (packages/meteor/dynamics_nodejs.js:108:1)
@dr-dimitru Check out the api branch of my fork at https://github.com/blackslate/ostrio-neo4jdriver.git
You'll see that I am working on a tool to display all the commands for the driver:
For now, only Neo4jDB() is complete.
Now that you have added all the new commands, I'll have plenty more work to do.
Note that the failure to throw exceptions means that the client cannot tell if the Neo4jDB() command succeeded or not
If you are expecting issue with fibers (Error: Cannot find module 'fibers'), install version with postfix -fiber, like: ostrio:neo4jdriver@1.0.2-fiber
Also: VeliovGroup/ostrio-neo4jdriver#26
So, just use ostrio:neo4jdriver@1.0.2
version, without -fiber
$ git checkout dev
Switched to branch 'dev'
Your branch is up-to-date with 'origin/dev'.
$ git log --oneline
fd663f4 readme.md
d6ed58a Add known issues
fdab9f8 UPD logo, add min.version
e0b6f9d logo
a63753b v1.0.2-fiber
Can you install my API Explorer and:
I believe it should give a possibility to type-in methods and execute them.
I'm not sure how you would implement this, since the client needs to use Meteor.call(...)
to get the server to execute the typed-in method. Different methods produce different results (cursor, objects of different sorts, array, ...) and some require quite complex arguments. Getting the server code to recognize all of these would require a a complex switch system.
Perhaps you could explain your ideas in more detail, so that I can see how they could be workable.
simpler... than [to] predefine everything
One very good reason to predefine everything is that a newcomer can see at a glance what is possible. If s/he has to type in methods manually, then it assumes that s/he already knows the methods and their syntax, in which case, why bother using an API Explorer?