firstly, let's take this simple query as example:
ObjectId('62663def4e578b0a1cb482c5').valueOf();
output in DataGrip v2021.3.1:
{"$oid": "62663def4e578b0a1cb482c5"}
output in Navicat for MongoDB v16.0.14:
62663def4e578b0a1cb482c5
output in mongosh 1.5.0:
ObjectId("62663def4e578b0a1cb482c5")
secondly, with typeof operator, i.e.:
typeof ObjectId('62663def4e578b0a1cb482c5').valueOf();, we can see the data type of the output. they are object in both DataGrip and Mongosh but string in Navicat for MongoDb.
This is an obvious issue and problematic when developers write complex queries, I believe there must be tickets raised for similar issue(but i haven't found one).
Why it it like this? It could be due to different mongoDB driver version integrated in each client but I searched around and haven't found any solid official documents. Could anyone help on this?
mongosh and MongoDB JDBC driver that is used in DataGrip have the same core so they should be very similar (and your examples show that. {"$oid": "62663def4e578b0a1cb482c5"} is just json representation of ObjectId type).
I don't remember what Navicat uses. I might guess that they have a wrapper for MongoDB NodeJS driver or they directly use old shell called mongo.
I would say that mongosh should have the most correct behaviour since it's a new shell that was developed very recently. If you think that this behaviour is incorrect try to create an issue in mongosh issue tracker https://jira.mongodb.org/projects/MONGOSH/issues/
If you think that behaviour of Navicat is incorrect, try to create an issue in their bug tracker
Related
I try write this command:
DELETE FROM locations ORDER BY id DESC LIMIT 1
on knex.js.
I write this code:
knex('locations').delete().orderBy('id', 'desc').limit(1).toString()
But it return
DELETE FROM locations
Why?
Because LIMIT is not supported by Postgres and Knex is supposed to be compatible with both MySQL and PostgreSQL. See GitHub issue:
[...] this syntax isn't supported in Postgres, so that might be a bit unexpected if it's possible in one database and not another [...]
Please open a new feature request if you need this functionality to be changed.
It was mentioned there that it works since 0.6 but I can't verify that, it seems still to be not working, and that seems to be a design choice. (Personally I find this quite problematic because there is no error, you just silently get everything deleted.)
The only way to handle a DELETE LIMIT statement would be as raw query with knex.raw then.
I am currently working on a kotlin multi project solution.
I have one project defining some data classes and defining an api to access a mongodb. The objectId is created automatically. This project is using morphia:1.3.2.
Entries are stored using this function:
fun store(myClass: MyClass) = db.save(myClass).let { myClass.id?.toHexString() ?: "0" }
Now I'm using this project in a spring-boot kotlin project.
I created a small web page with some filters. These filters should be applied on my query. So far so good, everything is working.
The results of my query are returned via my Rest-controller without any conversions. In my web page I want to print the ObjectId foreach result.
But the ObjectId is not a String as it used to be, it is an object.
id:
counter:15304909
date:"2018-08-27T23:45:35.000+0000"
machineIdentifier:123456
processIdentifier:1234
time:1535413535000
timeSecond:1535413535
timestamp:1535413535
Is it possible to force morphia to return the objectId in the String representation? Or is there a on Option to activate the correct mapping? Or do I have to touch each result one by one and convert the object id to the hexadecimal string representation? I hope that there is a better, and quicker solution then this.
I am also not able to remap the object to a valid id, due to an java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986 exception. The request looks like this:
myClass?id={"timestamp":1535413631,"machineIdentifier":123456,"processIdentifier":1234,"counter":16576969,"time":1535413631000,"date":"2018-08-27T23:47:11.000+0000","timeSecond":1535413631}
I'm a little bit out of ideas, how to fix this issue.
Depending on your REST framework, you would need to provided a serializer for writing out that ObjectId as its String version, say. Most such frameworks make that transparent once it's configured so you need only worry about returning your objects out of your REST service and the framework will serialize properly.
I, personally, wouldn't muck about by trying to change how it's serialized in the database. ObjectId is a pretty good _id type and I wouldn't change it.
I have to work on one Node Js project where I have to use two database in single application, One database is MongoDb and the other one is postgreSql. Till now I have only used only one dababase in one project. I just want to know that "Is it possible to use two different database as mentioned above in one Node Js project". If yes can you please provide me essential configs and plugin required to setup the project ?
yeah... NoSQL & another RDBMS together...because
NoSQL: fast and simple, but has little to none structure to enforce constraints on data.
RDBMS: satisfies all ACID properties, keeping your data safe and clean. But performance goes down rapidly as traffic and data set size grow.
for doing so ..
you can use an ODM (Object Document Mapper) like mongoose to deal with mongoDB
& an ORM (Object Relational Mapper) like sequalize to deal with mysql , postgre
As provided in the docs.. you got to install both
npm i -s mongoose sequelize
So I've got a Postgres function in place designed to merge two JSONB objects recursively, and it works just fine on the production server but fails on my local Postgres installation. The function itself is written in plv8 (a v8 Javascript engine basically) and expects two arguments in JSONB format to merge; the problem is that the JSON is passed in as a string and not as an object, which essentially breaks the entire function.
This only happens on my local computer though, a fresh Postgres 9.4.5 installation. The production server is running 9.4.4, which shouldn't cause such a major change across versions...ideas on where to go to see what's broken here?
EDIT: Can now confirm that reverting to 9.4.4 doesn't make this behave any differently locally
Hard to say. Possibilities:
Different casts - you can define custom casts - CREATE CAST statement - try to check result of psql command \dC *json*
New bug introduced in 9.4.5
FWIW, upgrading to 9.5 seems to solve instances of this issue for me.
I am having trouble finding information online as how to use Mongo ObjectID instances on the front-end.
I can't answer these questions:
(1) is it safe to serialize/deserialize ObjectID objects to/from JSON?
(2) How can I require the ObjectID module with AMD/RequireJS on the front-end?
(3) Is it better to just use strings on the front-end and just convert strings to ObjectIDs on the backend?
So yes I am having trouble working with and manipulating ObjectID objects on the frontend because I don't have the ObjectID module on the frontend, or at least this is a perceived problem. I haven't seen any examples of how to do this nor have I seen much talk of it online at all. Perhaps I am not approaching the problem correctly.
No. Your JSON parser will likely fail, as JSON only stores certain datatypes, and ObjectID isn't one of them...
Although, note that if you're stringifying your data it is possible that your MongoDB driver would in fact back this by returning a string from the ObjectID... Here is an example in NodeJS:
var ObjectID = require("mongodb").ObjectID,
myObject = {test:ObjectID("55153a8014829a865bbf700d")};
console.log(JSON.stringify(myObject));
// {"test":"55153a8014829a865bbf700d"}
No. I'm not sure there are any modules out there yet that give the ability to use ObjectID's in browser JS. Although perhaps you can port this NodeJS to browser JS compatibility?
Yes. For now, I would say yes. You can just use the string on the front-end; although, like I said ealier, if you can port the ObjectID peice to be browser compliant (which shouldn't be too hard), I don't think there would be any issues there.