I’ve been tracking XTDB development for quite some time and huge respect for such bold and fresh take on DB implementation.
In “A First Look at XTDB v2” live session, XT2 was mentioned in context where it fits well in domain of frequently evolving schemas. I work at company that has this approach at core of our product.
In our product we are providing Data Modeling by deploying data models and modifying (PostgreSQL) db and exposing towards frontend through GraphQL interface with 8-9 generic queries/methods while still preserving ability to extend with custom GraphQL resolvers for specific customer need.
Anywho, our customers are frequently changing schema, and this includes changing entity (table) and attribute (field) names.
To sum it up:
* Does XT2 support renaming "fields" and "tables"?
* Will XT2 support above someday?
* How does/will implementation affect bitemporality?
Thank you very much for your work and have a blast in upcoming '24
Hey @gersak thanks for the kind words and feedback!
This is definitely a large and important topic worthy of a longer write-up, but for the moment I can offer…
No, not currently. There is no support for lightweight aliasing, and any kind of migration for non-trivial amounts of data can’t be atomic unless you are able to stop the world to prevent concurrent transactions. Given that, the main practical alternative for now is to instead always transform consistently on read (in your query/application), and only incrementally migrate the underlying data in the course of regulate writes/updates.
Eventually it should be possible for us to push this same pattern (or similar) into the engine as v2 matures. I would certainly prefer to have a seamless & transparent (& async/background) migration story.
We would likely ignore valid-time entirely from a migration perspective, such that an entire valid-time timeline of versions always reflects a consistent schema (vs. allowing different versions of the schema over valid-time).
Additionally, some form of INFORMATION_SCHEMA is already firmly on the roadmap, and it will very likely respect system-time versioning.
FWIW, this is how we generally approach schema migrations today with MySQL – so it’s good to know this continues to be a practical approach with XTDB as well.
