Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • S Schema
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 23
    • Issues 23
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 13
    • Merge requests 13
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Open Subsurface Data Universe SoftwareOpen Subsurface Data Universe Software
  • Platform
  • System
  • Schema
  • Issues
  • #51
Closed
Open
Issue created Jun 10, 2021 by Aman Verma@amavermaMaintainer1 of 5 checklist items completed1/5 checklist items

ADR: New API to handle system schemas

Status

  • Proposed
  • Trialing
  • Under review
  • Approved
  • Retired

Context:

Public schemas are schemas which are available to all the tenants out of the box. Today the public schema includes schema from OSDU or SLB and are located in Schema service repository here: https://community.opengroup.org/osdu/platform/system/schema-service/-/tree/master/deployments/shared-schemas

How it's done today:

  • Deployment expects existence of a special partition (generally termed as common) which will be used to load public schemas
  • Schema service has only one endpoint today /schema. Based on the data-partition-id passed in the request headers, it's decided whether the schema is public or private.
  • If the data-partition-id passed is "special partition", then the created schema is public, otherwise it's private. This is indicated by a field named SCOPE in crated schema.

Issue with current design:

  1. The API behavior of /schema endpoint changes based on the data-partition-id header and can be confusing to users. Users might end up unknowingly creating public schemas by passing data-partition-id of special partition.
  2. The special partition is expected to be provisioned for provisioning public schemas.

Proposal:

There are two types of schemas in the system, public (or system) schemas and private schema. The proposal is to create a dedicated API to created/ update system schemas. Hence-

  • The new API shall be termed as /schemas/system
  • To create/ updated public schema- /schemas/system endpoint shall be used
  • To read public schema- existing GET /schema endpoint shall be used (same as current behaviour)
  • The new API shall not accept data-partition-id as a header. Service would be aware where the public schemas are located.
  • The authorization of new end point shall be different from exiting schema.editor/viewer role.

Sequence diagram for creating public schemas image

Sequence diagram for reading public schema

image

Edited Feb 24, 2022 by Abhishek Chowdhry
Assignee
Assign to
Time tracking