using:
node.js - version 8.0.0
neo4j-driver: 1.3.0
neo4j database: community edition, version: 3.2.0
i am running a cypher (not important what exactly is the cypher) and getting back a result.
after parsing the result using the follwing code:
result.records[0].get('instanceStock').properties
i am getting the following json:
{
"quantity":{
"low":10,
"high":0
}
}
the value 10 is the correct one which actually reside inside the db.
what is the meaning of the "low" and "high" properties?
why the correct answer reside inside the "low" property?
This has to do with how 64bit integers are handled in JS. More explanation here :
https://github.com/neo4j/neo4j-javascript-driver/tree/ad0317a675d50443ca97f157f119957354b74ae3#numbers-and-the-integer-type
Related
I upgraded CosmosDB Node.js SDK from 2.1.5 to 3.5.2 and the following code is no longer working.
client.items.query(myQuery, { partitionKey: "MyPartitionKey" }).toArray()
I changed the code to the following but it still does not transpile (typescript) and apparently the cause is that FeedOptions no longer contains partitionKey property!
client.items.query(myQuery,{ partitionKey: "MyPartitionKey" }).fetchAll()
I looked it up in the internet but could not find an up to date example.
Any idea how to fix this?
Turns out in v3 of the sdk there is no need to explicitly assign partitionkey value. If partitionkey engages in where clause, it will automatically be regarded.
githib issue reference
I can't find any up-to-date example from MS or github source code which is really challenging.
There is no any partitionkey property in FeedOptions class in the cosmos db node sdk v3 any more.After my deep research on the github source code of FeedOptions,i found that it extends another interface SharedOptions:
And it contains initialHeaders property so that i'm supposed that we could set partition key value following the REST API Header Lists.
Anyway,please refer to my working code:
const feedOptions = {
initialHeaders: {"x-ms-documentdb-partitionkey": '["a"]'}
};
const queryIterator = await container.items.query(querySpec,feedOptions);
while (queryIterator.hasMoreResults()) {
console.log(await queryIterator.fetchNext());
}
Surely,you could replace it with .fetchAll() method.
I just updated Node after not doing so for a while and had to reinstall MongoDB and other modules. Where I previously would only get an array of database objects when using the find() function, I'm now getting a JSON object that includes "results", "ops", "insertedCount", and "insertedIds". I can't remember what I might have done when I initially set it up or maybe this is just an annoying change with Mongo, but I'd like to return to only getting an array of database objects so that I don't have to test my entire server. I've tried several npm parse modules with no success.
Here's an example:
{ result: { ok: 1, n: 1 },
ops:
[ { user: '595ee2fec2924e5435dfdd2d'},
_id: 595f0fe55e84fa2468b17ce8 } ],
insertedCount: 1,
insertedIds: [ 595f0fe55e84fa2468b17ce8 ] }
Whereas previously, it would have only returned:
[ { user: '595ee2fec2924e5435dfdd2d'},
_id: 595f0fe55e84fa2468b17ce8 } ]
You can simply get the ops array.
result.ops;
You may also need to make sure to follow your call stack correctly as those objects are only returned on an insert.
You can take the resulting object and strip it down to just the array by accessing the ops attribute.
runMyQuery().then(function(res) {
return res.ops;
});
The previous example makes a lot of assumptions, so don't expect a copy-paste solution.
The most correct solution would be to continue running your project with the exact versions of everything your package.json depends on.
That said, I'm assuming you're encountering this issue is because you're running Node locally on your system and needed to upgrade it for another project or security fix. If this is the case, you may want to consider using a Node version management tool like nvm or nodenv. These allow you to have multiple versions of Node installed and associate them with individual projects so you don't run into compatibility issues.
For an even more powerful variation of this, you might want to virtualize your entire development environment using a virtual machine such as VirtualBox or a container system like Docker. Both let you create files that define how you'd like to provision your VMs or containers (what OS, what versions of software are installed, etc.). They're the most robust way of ensuring that when you come back to a project months, or even years later, it will still run exactly the way you left it.
Sounds like you inadvertently upgraded from MongoDB 3.X drivers to MongoDB 4.X drivers. The insert operations now return a much more developer friendly "InsertManyResult" object. Unfortunately, as far as I can see, this change did not make the documentation on breaking changes.
I have a web app that posts a JSON request to a Node/Express server, which then inserts a new document into a local MongoDB database using the latest version of the mongodb Node module. When I view the documents using MongoChef, all integers are wrapped with NumberInt(x).
"shirts" : {
"adult-x-large" : NumberInt(2),
"youth-small" : NumberInt(1),
"adult-small" : NumberInt(1),
"adult-medium" : NumberInt(1)
}
I'm sure these wrappers are useful for certain applications, but I really don't want my JSON filled with them. Is there a way to disable this? I'm not sure if this is a MongoDB issue, a MongoChef issue, or something else entirely.
It is just a display part in MongoChef. If you view the data in "TreeView", it should show the type as Int32 with just numeric value.
As long as the datatye is "Int32", it should be correct and as expected.
MongoChef JSON View:-
MongoChef Tree View:-
RoboMongo Json View:-
I'm using the Mongoose-Text-Search plugin (https://github.com/aheckmann/mongoose-text-search) to search through my mongodb database, but I'm getting a really confusing error message I've never seen before.
error: name=MongoError, ok=0, errmsg=error processing query: ns=testdb.data limit=100 skip=0
Tree: TEXT : query=test, language=, tag=NULL
Sort: { $s: { $meta: "textScore" } }
Proj: { $s: { $meta: "textScore" } }
planner returned error: failed to use text index to satisfy $text query (if text index is compound, are equality predicates given for all prefix fields?)
Can someone explain what this means? I think I'm using the text-search plugin correctly, but I can't for the life of me figure out what's wrong here.
Thanks!
It looks like you created COMPOUND full text search index in Mongodb. And because of this you have to request data from full text search index together with other field. Look here for details: http://docs.mongodb.org/manual/tutorial/limit-number-of-items-scanned-for-text-search/
There are some restrictions like you can't use $gt/$gte/$lt/$lte/$in/$type composed with $and/$or etc for the predicated field. Details here: https://jira.mongodb.org/browse/SERVER-13801
Upgrade to Mongo 2.6.4 and through away Mongoose-Text-Search plugin. The plugin was useful ONLY for Mongo 2.4.x and absolutely redundant for the modern Mongo version. Just use find() method for full text search.
I am running the following query using Cypher on Neo4j 2.0.1
MATCH (n) WHERE n.value = -4810333952080461631 OR n.value = -163182636343344959
RETURN n.value
Results:
-4810333952080462000
-163182636343344960
It seems that the values are getting rounded. I tried it through their web ui, and the node js neo4j client.
When I browse to the node through their web ui, I can see that it holds the correct value.
This was opened in an issue: https://github.com/neo4j/neo4j/issues/2009. The JSON returned is correct. If it's not correct coming from the client you're using (you don't mention which), there is possibly a bug in the client, where a value is converted to a double and losing precision.