-
Notifications
You must be signed in to change notification settings - Fork 603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(risingwave): port to sqlglot #8171
refactor(risingwave): port to sqlglot #8171
Conversation
ACTION NEEDED Ibis follows the Conventional Commits specification for release automation. The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification. |
This is the initial PR for ibis to support risingwave. [RisingWave](https://github.com/risingwavelabs/risingwave) is a distributed SQL streaming database engineered to provide the simplest and most cost-efficient approach for processing and managing streaming data with utmost reliability. After a few weeks of investigation, here's my phasic results. 1. As Risingwave is largely compatible with Postgres, Ibis can be easily extended to support Risingwave. The main work is to add a new dialect for Risingwave, which is similar to the `postgres` dialect. I've almost finished this part in this PR. With this PR, Ibis can be used to connect to Risingwave and run some basic queries. I've manually tested some queries which works well and add some tests imitating Postgres Backend. I would appreciate if you can help test more queries. 2. As ibis relies on SQLalchemy to support Postgres, we follow its implementation to support Risingwave. However, there are also some differences in semantics between Risingwave and Postgres, which require some modification in either ibis or SQLalchemy. `sqlalchemy-risingwave` is designed to reduce this mismatch. So in this PR, I introduce the new dependencies `sqlalchemy-risingwave` to ibis. 3. Ibis has no support for Materialized View natively. However Materialized View is a core concept in RW, people use RW because of its convenient auto-updated Materialized View. Now, if a user wants to create a new MV, he needs to use a raw SQL. Adding DDLs like `CreateMaterializedView`, `CreateSource` and `CreateSink` in the [base ddl file](https://github.com/ibis-project/ibis/blob/main/ibis/backends/base/sql/ddl.py) may help. We would appreciate it if you can help offer some suggestions. Besides this, I also met some obstacle that may need your help. 1. Risingwave hasn't supported `TEMPORARY VIEW` yet, so I changed some implementations relying on `TEMPORARY VIEW` to a normal view. For example, for the `_metadata()` functions, RW backend's implementation is `con.exec_driver_sql(f"CREATE VIEW IF NOT EXISTS {name} AS {query}")`. While in PG it's `con.exec_driver_sql(f"CREATE TEMPORARY VIEW {name} AS {query}")`. Do you have any suggestions for other ways to work around this? Besides, I didn't quite get what `_metadata()` is doing here. I would appreciate it if you could explain it a bit. 2. There's some mismatch between the `postgres` dialect and `risingwave` dialect, which are still not fully tested in this PR. We'll continue to work on it. 3. ~~This PR requires some new features of Risingwave v1.6.0 and sqlalchemy-risingwave v1.0.0 which are not released yet. They'll be released soon.~~ Done. BTW, how should I indicate this backend is only for risingwave > 1.6? 4. I don't quite understand the test pipeline of Ibis. I copied the test cases from the `postgres` dialect and modified them to fit the `risingwave` dialect, and some of them are commented temporarily due to the lack of support. I also added an SQL script to help set up the test environment, which creates tables and loads data. But I don't know how to run it in the test pipeline. Any suggestions or guidance are welcomed. I suppose the test pipeline would require a docker image of Risingwave. We can provide one if needed. 5. I'm a newbie in the ibis community, this PR may not be perfect considering others. Any comments are welcomed and I sincerely appreciate your time and patience. closes ibis-project#8038
Remove risingwave-specific minio service in favor of existing minio service.
…roject#8140) Fix the failing tests on main
a bunch of tests that previously failed with a `ValueError` now return results but the results are incorrect. This seems bad.
Looking into the rebase now... |
why would this not work for postgres but would work for risingwave?
oops, I don't think I stomped on this. We definitely just fixed a bunch of the same stuff. That'll teach me to ignore my email |
3376022
to
432d151
Compare
Nah, you're good. I had already pushed the fix in a previous commit! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, great work!
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
Co-authored-by: Kexiang Wang <[email protected]> Co-authored-by: Phillip Cloud <[email protected]> Co-authored-by: Jim Crist-Harif <[email protected]>
xref #7909
a lot of new passing tests -- some flakiness in
groupconcat
when it's used in a window.failing tests are all assertion errors in
test_array
.