You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BSON exists as a sustainable datatype for storing JSON as binary, serializing it into a format we can store at pure ease. JSON has proven to be an important storage necessity for things like settings, configuration and more.
Adding support for JSON through this format will allow users to store JSON objects and values sustainably, without having to use an external format for such.
Explanation
BSON examples are well provided as is, and can be used by individual database implementations to create their own parser (unless they use a module in their individual languages)
For example, this is a BSON data structure.
Document Size Type Field Name Value Size Value Null Terminator End of Object
16 00 00 00 02 68 65 6C 6C 6F 06 00 00 00 77 6F 72 6C 64 00 00
0 4 5 10 14 19 20
This can be deserialized into the provided JSON structure:
{
"hello": "world"
}
With this nice, simple look; It would fit right in with how data is formatted.
Pseudo-code
# BSON Example
\x16\x00\x00\x00//totaldocumentsize
\x02//0x02=typeStringhello\x00//fieldname
\x06\x00\x00\x00world\x00//fieldvalue (sizeofvalue, value, nullterminator)
\x00//0x00=typeEOO ('end of object')
Rationale and Alternatives
Why is this design the best in the space of possible designs?
While other provided options exist, we can consider the other given options, our options being UBJSON and BSON.
What other designs have been considered and what is the rationale for not choosing them?
UBJSON is a proposed successor, adding better support for the JSON specifications, and with an easier implementation. Could be used as an alternative?
What is the impact of not doing this?
Developers won't have a sustainable way of storing things like JSON or formatted structures of this type.
Metadata
Current Implementations
This section is reserved for whenever a database implementation adds it.
Timeline
3/2/2020 - Created RFC
The text was updated successfully, but these errors were encountered:
Seems like a good idea to add large scale support for object storing. Personally I think BJSON would be the better option here as it should in theory be closer to the format of all the other implemented types/blocks.
RFC0001 - JSON Datatype (through BSON)
RFC Stage: Stage 1
Introduction and Summary
BSON exists as a sustainable datatype for storing JSON as binary, serializing it into a format we can store at pure ease. JSON has proven to be an important storage necessity for things like settings, configuration and more.
Adding support for JSON through this format will allow users to store JSON objects and values sustainably, without having to use an external format for such.
Explanation
BSON examples are well provided as is, and can be used by individual database implementations to create their own parser (unless they use a module in their individual languages)
For example, this is a BSON data structure.
This can be deserialized into the provided JSON structure:
With this nice, simple look; It would fit right in with how data is formatted.
Pseudo-code
Rationale and Alternatives
Why is this design the best in the space of possible designs?
What other designs have been considered and what is the rationale for not choosing them?
What is the impact of not doing this?
Metadata
Current Implementations
This section is reserved for whenever a database implementation adds it.
Timeline
3/2/2020 - Created RFC
The text was updated successfully, but these errors were encountered: