vaticle / typedb

TypeDB: the polymorphic database powered by types
https://typedb.com
Mozilla Public License 2.0
3.72k stars 337 forks source link

Add a way to store metadata about the schema in a database #6814

Open izmalk opened 1 year ago

izmalk commented 1 year ago

Problem to Solve

With active development of a database schema, it can be hard to track all the versions of a schema. While for files it's not a problem with modern VCS, like git, for a database there is no way to know what kind of a schema loaded in it other than read all schema and compare it type by type.

Comments that you can have in a TQL file will not be stored in your database and can't be exported later on for a database.

Adding metadata can help with managing big schemas and can even later on be used for the modularization of schemas.

Current Workaround

We can have an attribute of a version. And instantiate it in a database with the schema version. The attribute will not be a part of the database logic so it will not be owned by anything (orphaned). Can potentially be deleted if we add garbage collection for orphaned attributes. And storing metadata inside your schema is not an elegant solution.

Proposed Solution

Have a way to store some metadata for a database. The most obvious application I see is to store schema name and version (as in name: IAM, version: 0.3). But it really can be used to store any metadata. Maybe even the license notice.

We can think of a way to limit our users not to use this feature to try to make key-value storage out of TypeDB. I would limit the number of metadata parameters to somewhat around 10.

Additional Information

A database schema metadata should be accessible through Driver API, seeable in TypeDB Studio, TypeDB Console, and exportable with a schema.

The implementation of this feature can be quite different. We can use RocksDB directly or we can use the internal/system database.

james-whiteside commented 1 year ago

I disagree with limiting the amount of metadata, unless there's a good performance reason for doing so. I can see people very quickly running aground on that and resorting to combining metadata items into strings to store them under one item. If people really really want to use TypeDB for kv storage instead of a purpose built database like Redis, I see no reason to stop them.