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
The Metadata Service provides a generic and flexible schema-driven data store for metadata that can be easily integrated with other backend and/or frontend components.
Metadata Service overview
The core design of the metadata service is primarily driven by schema. That is, all metadata instances must adhere to a schema. Metadata schemas are organized logically and physically into schema spaces, where a given schema space contains a set of schemas, and each instance of a schema space’s schemas is co-located relative to the configured storage mechanism.
Externally, both in its persisted and serialized forms, a metadata instance is represented as a JSON structure. Within the metadata service, however, this JSON structure is represented as a Metadata class instance. The Metadata class can be extended via subclassing to enable custom behaviors that are triggered following load operations and/or before and after create, update, and delete operations on a per schema level. That is, it is the respective schema that identifies the name of the class to use as the internal representation.
As previously mentioned, the metadata service has a pluggable storage mechanism. By default, metadata instances are stored within the file system. However, alternative storage mechanisms can be configured for, say, NoSQL DB or traditional, table-oriented, databases.
Schemaspaces and their schemas can be dynamically introduced via entrypoints. When the system starts, it will identify applicable entrypoints and load their corresponding objects to seed the list of configured schemaspaces and schemas.
Design proposal
We are proposing a similar design as the one used by terminals
The component will be implemented as a separate repository
The component will be integrated and enabled by default to jupyter server
Additional references
More details about the existing Metadata service implementation
Proposal
The Metadata Service provides a generic and flexible schema-driven data store for metadata that can be easily integrated with other backend and/or frontend components.
Metadata Service overview
The core design of the metadata service is primarily driven by schema. That is, all metadata instances must adhere to a schema. Metadata schemas are organized logically and physically into schema spaces, where a given schema space contains a set of schemas, and each instance of a schema space’s schemas is co-located relative to the configured storage mechanism.
Externally, both in its persisted and serialized forms, a metadata instance is represented as a JSON structure. Within the metadata service, however, this JSON structure is represented as a Metadata class instance. The Metadata class can be extended via subclassing to enable custom behaviors that are triggered following load operations and/or before and after create, update, and delete operations on a per schema level. That is, it is the respective schema that identifies the name of the class to use as the internal representation.
As previously mentioned, the metadata service has a pluggable storage mechanism. By default, metadata instances are stored within the file system. However, alternative storage mechanisms can be configured for, say, NoSQL DB or traditional, table-oriented, databases.
Schemaspaces and their schemas can be dynamically introduced via entrypoints. When the system starts, it will identify applicable entrypoints and load their corresponding objects to seed the list of configured schemaspaces and schemas.
Design proposal
We are proposing a similar design as the one used by terminals
Additional references
More details about the existing Metadata service implementation
The text was updated successfully, but these errors were encountered: