Hacker Newsnew | past | comments | ask | show | jobs | submit | clkao's commentslogin

There's the slim ci best practice and ways to deploying only what's changed in dbt, but these require some config and underlying knowledge.

Verifying schema changes pre-production is only part of the issues, figuring out the actual data changes caused by code logic changes is trickier.


the uw data lab behind vega also has a new library mosaic[1] that seems pretty exciting. My impression was it allows flexible data transformation/slicing in both the client side and server side, with the same dsl.

[1] https://github.com/uwdata/mosaic


Oh wow, that's very cool. Being able to push down queries all the way to parquet while existing purely on the clientside via duckdb wasm is very cool. This enables purely static visualizations with full interactivity and full query optimization.


previous discussion: https://news.ycombinator.com/item?id=34694926


I find it interesting that this comment section and that comment section seem to focus on different things, despite being triggered by the same input.


https://www.relajet.com/ - started by a friend with hearing loss


Thank you clkao :) Relajet is our company name, otoadd is our hearing aid brand.


Thanks for the question! GX is a great tool providing data testing, which is also useful during dbt PR, similar to dbt tests. PipeRider provides additional comparison about data profiles between the merge base and the PR, and also presenting more dbt-specific information.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: