Closed hannomalie closed 7 years ago
AFAIK this is how MongoDB represents 64 bit integers, so it looks like that the previous behavior was wrong and now the information is represented accurately:
https://docs.mongodb.com/manual/reference/mongodb-extended-json/
However my colleague @ujibang is more expert on this subject and might add his point of view.
Starting with latest releases of mongodb driver, long numbers are represented in json that way.
Regarding the plain json representation (that doesn't change how longs are represented) the correct query parameter is ?rep=pj starting 3.0
Thank you very much for your fast answer - so the behaviour is caused by a change in mongo, that's good news. However, I was not able to use "?rep=pj" successfully - is there any documentation for this new feature?? In case of requesting a collection url, what is expected to be the returned answer (could you please provide an example output for regular json and hal format, from collection url and maybe from a document url)?
$ http dbapi.io/db/coll?rep=pj\&pagesize=2
HTTP/1.1 200 OK
...
{
"_embedded": [
{
"_etag": {
"$oid": "58c686cbc9e77c0005bfcfa1"
},
"_id": {
"$oid": "58c686cb21a6f5bde9942692"
},
"brand": "x9tec",
"code": "x9",
"description": "novo produto"
},
{
"_etag": {
"$oid": "58c6868fc9e77c0005bfcfa0"
},
"_id": {
"$oid": "58c6868f21a6f5bde9942691"
},
"brand": "xxx1",
"code": "xx",
"description": "xxxxxxxxxx"
}
],
"_etag": {
"$oid": "587f62dfc9e77c0006fc44c3"
},
"_id": "coll",
"_returned": 2
}
$ (master) http dbapi.io/db/coll?rep=hal\&pagesize=2
HTTP/1.1 200 OK
...
{
"_embedded": {
"rh:doc": [
{
"_etag": {
"$oid": "58c686cbc9e77c0005bfcfa1"
},
"_id": {
"$oid": "58c686cb21a6f5bde9942692"
},
"brand": "x9tec",
"code": "x9",
"description": "novo produto"
},
{
"_etag": {
"$oid": "58c6868fc9e77c0005bfcfa0"
},
"_id": {
"$oid": "58c6868f21a6f5bde9942691"
},
"brand": "xxx1",
"code": "xx",
"description": "xxxxxxxxxx"
}
]
},
"_etag": {
"$oid": "587f62dfc9e77c0006fc44c3"
},
"_id": "coll",
"_returned": 2
}
I think the plain JSON actually comes using the np
parameter, doesn't it?
http://dbapi.io/db/coll?pagesize=2&np
[{
"_id": {
"$oid": "58c686cb21a6f5bde9942692"
},
"_etag": {
"$oid": "58c686cbc9e77c0005bfcfa1"
},
"code": "x9",
"description": "novo produto",
"brand": "x9tec"
}, {
"_id": {
"$oid": "58c6868f21a6f5bde9942691"
},
"_etag": {
"$oid": "58c6868fc9e77c0005bfcfa0"
},
"code": "xx",
"description": "xxxxxxxxxx",
"brand": "xxx1"
}]
@mkjsix the plain json comes with the query parameter rep=pj
. this is however optional if the configuration file specifies the default setting:
default-representation-format: PLAIN_JSON
the np query parameter avoids resources properties to be included in the response (np stands for "No Properties"); in this case the response is just the _embedded property returned directly as an array.
example:
GET /db/collection
{
"_id": "collection",
.... other properties of the collection
"_embedded": [
{ <doc1> },
{ <doc2> },
....
{ <docN> }
]
}
GET /db/collection?np
[
{ <doc1> },
{ <doc2> },
....
{ <docN> }
]
Maybe this representation without properties is what @hannespernpeintner was really looking for
I'm closing this, please re-open in case.
Hi!
We tried to update from restheart 2.0.2 to restheart 3.0.0 and noticed a strange and unexpected behaviour.
Our configurations use HAL as default representation format - we configured it in our configuration files with "default-representation-format: HAL". This seem to work, but long fields (values mongodb can't store as int32) somehow appear now in the following format in the queried document:
"our_value": { "$numberLong": "1489155634526" }
This differs from the behaviour we had with version 2.x and we somehow doubt that this is expected and wanted behaviour . We tried to append "?pj" as stated on "http://www.softinstigate.com/blog/2016/09/07/plain-json-representation-in-upcoming-RESTHeart-3.0/" to query plain json, but somehow, this doesn't change anything at all...the returned data is still HAL.
Is there any chance these two issues are bugs, or do you have any idea what we are doing potentially wrong?
Thanks! Hannes