[DRIVERS-342] add Json result : Simple type mode Created: 05/Dec/16 Updated: 15/Apr/19 Resolved: 04/Dec/17 |
|
| Status: | Closed |
| Project: | Drivers |
| Component/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | guillaume dufour | Assignee: | Bernie Hackett |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Description |
|
Hello, i try to respond to the jira Hope it can help other people ;o) As @rozza said: So here is the issue after 9 months on wait without any response.... |
| Comments |
| Comment by Bernie Hackett [ 04/Dec/17 ] |
|
I'm closing this as a duplicate of DRIVERS-351, which requires the relaxed mode. |
| Comment by Jeffrey Yemin [ 04/Dec/17 ] |
|
Relaxed extended JSON solves the specific issue of serializing BSON Int64 values as JSON numbers instead of using $numberLong. |
| Comment by Bernie Hackett [ 04/Dec/17 ] |
|
With the introduction of the MongoDB Extended JSON spec, is this ticket resolved? ross.lawley jeff.yemin, does the Java driver implementation of the spec resolve |
| Comment by Ralph Jennings [ 04/Apr/17 ] |
|
Ideally, we wouldn't need to convert anything to JSON ourselves and could just use jackson in the library to get a MongoCollection<MyJacksonSerializableObject> (whereas right now we are forced to get a MongoCollection<Document> and turn the document into jackson-compatible – non mongo-extended – JSON text and use a jackson ObjectMapper to turn that back into a MyJacksonSerializableObject, unless we want to write yet another set of parser/conversion classes for mongo). |
| Comment by guillaume dufour [ 05/Dec/16 ] |
|
The problem is emfjson is base on jackson.
I don't test a lot for Date because I don't have the problem. (No date in my data) |
| Comment by Ross Lawley [ 05/Dec/16 ] |
|
Hi dufgui, Thanks for adding this ticket, once again I'd like to apologise for the lack of response on your PR, behind the scenes we have been looking at extended json but unfortunately, I neglected to update the issue and let you know. Currently, converting a document to extended json does produce valid Json and allows for all Bson types to be round tripped without losing the type information. I'd like your help in understanding more about the issues or pain it is that causing you when using the extended json? From the tests in the PR it seems to only be numerics and dates that are handled differently. Is that for better interoperability with other Json libraries? Does it matter that the fidelity could be lost when round tripping the numeric data types? Thanks, Ross |
| Comment by guillaume dufour [ 05/Dec/16 ] |
|
Sorry it's a feature not a bug |