Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON Datatype (through BSON) #1

Open
bernkastel02 opened this issue Feb 3, 2021 · 4 comments
Open

JSON Datatype (through BSON) #1

bernkastel02 opened this issue Feb 3, 2021 · 4 comments
Labels
good first issue Good for newcomers rfc All of the RFCs

Comments

@bernkastel02
Copy link

bernkastel02 commented Feb 3, 2021

RFC0001 - JSON Datatype (through BSON)

RFC Stage: Stage 1

  • Start Date: 03/02/2021
  • RFC Pull Request: (none, until proper stage)
  • Champions: @AuSakura

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.

 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               // total document size
  \x02                           // 0x02 = type String
  hello\x00                      // field name
  \x06\x00\x00\x00world\x00      // field value (size of value, value, null terminator)
  \x00                           // 0x00 = type EOO ('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

@bernkastel02 bernkastel02 added good first issue Good for newcomers rfc All of the RFCs labels Feb 3, 2021
@SMJSGaming
Copy link

SMJSGaming commented Feb 3, 2021

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.

@bernkastel02
Copy link
Author

UBJSON would work too, if it's actually any close to finished.

@bernkastel02
Copy link
Author

bernkastel02 commented Feb 3, 2021

oh
image

guess that's a no then; guess we should consider removing it as an option for an alternative

@bernkastel02
Copy link
Author

it's probably fine to move this to stage 1 considering all aspects of it are defined and it's been nearly a week since it's creation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers rfc All of the RFCs
Projects
None yet
Development

No branches or pull requests

2 participants