[JAVA-2489] Add to Enum<JsonMode> Created: 13/Apr/17  Updated: 22/Jun/17  Resolved: 22/Jun/17

Status: Closed
Project: Java Driver
Component/s: BSON, JSON
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Edem Nsefik Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to JAVA-1772 Make it easier to change JsonWriter b... Closed
related to JAVA-2447 Implement Extended JSON specification Closed

 Description   

Currently ENum<JsonMode> has the Values 'STRICT' or 'SHELL' as a parameter value to be passed for example to JsonWriterSettings(JsonMode.SHELL)

We need a 3rd option call it SIMPLE or NOTEXTENDED in which the bson extended json values are returned as raw values without using the bson extended json datatypes as in JsonMode.SHELL or returning a json document for the bson extended json datatypes as in JsonMode.STRICT

For example a document with a field of type Long will render the following json
JsonMode.SHELL -

{ "field1" : NumberLong("10000000000000") }

JsonMode.STRICT - { "field1" :

{ "$numberLong" : "10000000000000" }

JsonMode.SIMPLE -

{ "field1" : 10000000000000 }

Currently, I am having to do regex substitution on a json returned using JsonMode.SHELL.



 Comments   
Comment by Jeffrey Yemin [ 22/Jun/17 ]

I linked to the related tickets, which I believe will satisfy this use case.

Comment by Jeffrey Yemin [ 25/Apr/17 ]

Hi Edem,

In scope of another issue addressed in the upcoming 3.5 release of the driver, applications will be able to output whatever JSON is required for each type, using custom converters. The code will look something like this:

        JsonWriterSettings settings = JsonWriterSettings.builder()
                                              .indent(true)
                                              .int64Converter((value, writer) -> writer.writeNumber(value.toString()))
                                              .decimal128Converter((value, writer) -> writer.writeString(value.toString()))
                                              .objectIdConverter((value, writer) -> writer.writeString(value.toHexString()))
                                              .dateTimeConverter((value, writer) -> writer.writeString(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm'Z'").format(new Date(value))))
                                              .build();
        Document doc = new Document("_id", new ObjectId())
                               .append("i", 12)
                               .append("l", Long.MAX_VALUE)
                               .append("dec", Decimal128.parse("234234234.3434234"))
                               .append("date", new Date());
 
        String json = doc.toJson(settings);

and the output would look like this:

{
  "_id" : "58ffc3825ac0fa0f8baaa365",
  "i" : 12,
  "l" : 9223372036854775807,
  "dec" : "234234234.3434234",
  "date" : "2017-04-25T17:45Z"
}

I think that will provide more flexibility for applications with specific output requirements than we could achieve with an additional OutputMode, which might work for some applications but be inappropriate for others.

Comment by Edem Nsefik [ 25/Apr/17 ]

Great to hear that this is being worked on across the driver range.

This feature request is really about outputting simple JSON without the need to necessarily go back to the BSON equivalent.
So the BSON extended JSON types like ObjectID or Decimal128 could be represented as String values or numbers where appropriate

As for fidelity, I'd leave that to the user types that will interplay with the simple JSON. If the BSON is Long it presumably will be read into a user type Long(64bits) regardless of its size, otherwise we'd get errors trying to read a big Long into an Int(32bits)

Comment by Craig Wilson [ 13/Apr/17 ]

We are currently working on exactly this type of thing across all our drivers.

A few questions for you:
1. What would you want to see when your documents have types that cannot be natively represented in JSON, like ObjectID or Decimal128?
2. Do you care about type fidelity? It's entirely possible that we write out a small Long(64 bits) value and, when read, it gets interpreted as an Int(32 bits).

Craig

Generated at Thu Feb 08 08:57:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.