How to manage SQL code versioning and testing in RisingWave?
I'm currently using cube.js for analytics and have a repository with SQL code that we version for deployment purposes. I'm interested in possibly replacing or extending this setup with RisingWave (RW), but I'm unsure how to handle versioning and testing of SQL business logic in RW. Specifically, I'm looking for the best practices for managing SQL code versions and automatically testing SQL business logic in RW, considering that migration tools like yoyo may not be suitable since RW doesn't support all PostgreSQL features and we can't write to RW in the same way. Here's an example of what we currently do with cube.js:
-- Example SQL code for a cube
SELECT * FROM transactions WHERE amount > 100;
And we use semantic versioning for our cube versions in a git repository. How can I achieve similar version control and testing for SQL in RW?
Tobias Lindener
Asked on Feb 25, 2024
To manage SQL code versioning in RisingWave, you can use dbt
(data build tool), which allows you to manage your SQL as code and provides git-based version control support. It's suitable for creating materialized views or sinks in RW. For testing SQL business logic, dbt
can also be used to execute and test your SQL code. While RW doesn't support cube.js yet, you can rewrite your cube SQL into several SQL statements for testing in RW. For schema migration, RisingWave supports integration with tools like Bytebase, and is actively supporting others like Liquibase and AtlasGo. Although dbt
is not a full-fledged database change management tool like some others mentioned, it can help organize and execute SQL scripts. If you need more advanced migration management features like rollback or verify, you might need to look into other tools or use custom scripts until a suitable integration is available for RW.