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

Reuse index.json in fullIndex.json #7

Closed
manoj-pillay-10gen opened this issue Apr 4, 2023 · 2 comments
Closed

Reuse index.json in fullIndex.json #7

manoj-pillay-10gen opened this issue Apr 4, 2023 · 2 comments

Comments

@manoj-pillay-10gen
Copy link
Owner

Currently, we have to duplicate code between index.json and fullIndex.json . Instead. there may be a way to extend siblings of a schema to eliminate duplication and drift caused from maintaining redundant copies.

fullIndex.json is more than ornamental, because the API which needs the auto-generate YAML spec requires the additional components available in fullIndex.json.

@manoj-pillay-10gen
Copy link
Owner Author

Can do something like https://stackoverflow.com/questions/52566472/how-to-extend-a-schema-in-json-schema however, will need 3 schema:

  • BaseIndex ( minimum fields without additionalProperty or required restrictions).
  • AtlasEditorIndex (inherits base using allOf, but adds required and additionalProperty and whatever else necessary)
  • FullSearchIndex (inherits base using allOf, adds name, collectionName and database fields alongside its own required and additionalProperty settings.)

@manoj-pillay-10gen
Copy link
Owner Author

We solved this problem, but it required adding the following bloat: https://github.com/manoj-pillay-10gen/simple-search-index-validator/blob/main/schema/fullIndex.json#L12-L17

Note that this is not necessary if using JSON Schema draft 2019-09 onwards. We could replace additionalProperties:false with unEvaluatedProperties:false in order to permit subschema elements but not any unknown elements. Unfortunately monaco-editor which uses https://github.com/microsoft/vscode-json-languageservice is yet to support drafts 2019-09 or 2020-12 . See microsoft/vscode#98724 . Consequently, we will have to deal with the bloat to permit use of elements in the subschema while avoiding any other field definitions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant