Hi thanks for ur reply. Have exported the json file from Studio3T from the existing mongodb collection we already have and uploaded it to S3. It usually exports as _id:ObjectId(""), and long datatype as “age”: NumberLong(10) etc… Even from Mongodb compass it exports in the same way.
Hi @P_Vivek, there is an unfortunate misunderstanding about JSON file structure versus json content we use in mongodb queries. It is actually eJSON when we want to use ObjectId, NumberLong, and other data types.
Hi @Yilmaz_Durmaz thanks for ur clarification. The issues is studio3t is generating ejson while exporting, I’m uploading that json file to s3, when reading that as s3 object I’m getting above error.
Hey @P_Vivek , I’m not sure that’s exactly what’s happening here, can you share the full error with the correlationID value?
Atlas Data Federation can read both Extended JSON and JSON, I am expecting that Studio3t is doing something unusual and maybe exporting incorrect extended json somehow.
Hi @Benjamin_Flast Atlas Data Federation is not reading Extended Json. Studio 3T has another option to export usual Json format it is working fine in Data Federation.
Pls let me know how to make extended Json to work in Data Federation.
Below is the extended Json studio3T is exporting…
That’s not extended json, its not even json. This is the format for mongosh/studio3t. If you’re using the tool as documented and not getting the correct results use their support/raise a bug, its what you paid for.
Once your tools is exporting correct json or you switch to another tool that does then the Data Federation will work with its output.
Tip: If you cannot parse your export with something like jq its not json.
Hi again @P_Vivek , Let me extend (pun intended ) my last statement about the misunderstanding of JSON/eJSON with an example.
JSON format has only 5 value types: numbers, true/false, objects enclosed in {}, arrays enclosed in [] and everything else is string enclosed in quotes"". and then all keys are strings again. oh, and its root is also an object.
{ "key": { "just_a_sub_key": "value" } }
eJSON is a perfect JSON file with a trick: sub-keys in sub-objects can have a meaning.
{ "key": { "ejson_sub_key": "value" } }
$oid and $date are two of those meaningful sub keys. if you read with a JSON reader they are just some subkeys, but if you read with an eJSON parser, the “values” they refer to will be converted to ObjectId and Date objects further down your program.
a quick warning here is this: if you see any non-quoted variable name (other than true/false and numbers) then that file is not a valid JSON/eJSON file. you may say they are actually partial JavaScript files and are meant to be read without any parsing, mostly by the programs they are written for.