The history of this project goes back nearly 10 years and the general picture of many of our open issues (#17 in particular) show that we have a lot of ways that we could change the database schema to be better.
in order to do this, we need the ability to change the schema without creating a ripple effect of breaking changes that get sent downstream.
We already use materialized views to support some of 8Knot's larger queries.
As discussed in #313, I want to create a stable schema tha we move all current materialized views to, and then use as a home for creating new views (regular or materialized) that surface only the tables and columns that have been cleaned up and are ready to become part of a stable API surface that CollectOSS can commit to maintaining.
The stable schema will be a place that follows principles like:
- consistent column naming (identifier columns have a consistent naming convention across tables)
- no typos in column names
- Schemas that are as normalized as possible for query efficiency
The goal between these principles and the official stablilty gaurantee is to make the stable schema a more attractive target for downstreams to develop against compared to the internal/non-gauranteeed data schema that we currently have
This Database API surface can then be thoroughly unit tested to ensure nothing changes, ensuring downstreams don't break because of schema changes (unless they are done intentionally as part of a known breaking change with a corresponding major version bump).
This is a tracking issue for the overall stable schema effort.
The history of this project goes back nearly 10 years and the general picture of many of our open issues (#17 in particular) show that we have a lot of ways that we could change the database schema to be better.
in order to do this, we need the ability to change the schema without creating a ripple effect of breaking changes that get sent downstream.
We already use materialized views to support some of 8Knot's larger queries.
As discussed in #313, I want to create a
stableschema tha we move all current materialized views to, and then use as a home for creating new views (regular or materialized) that surface only the tables and columns that have been cleaned up and are ready to become part of a stable API surface that CollectOSS can commit to maintaining.The stable schema will be a place that follows principles like:
The goal between these principles and the official stablilty gaurantee is to make the stable schema a more attractive target for downstreams to develop against compared to the internal/non-gauranteeed
dataschema that we currently haveThis Database API surface can then be thoroughly unit tested to ensure nothing changes, ensuring downstreams don't break because of schema changes (unless they are done intentionally as part of a known breaking change with a corresponding major version bump).
This is a tracking issue for the overall stable schema effort.