-
Notifications
You must be signed in to change notification settings - Fork 594
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(udf): move UDF implementations to expr_impl
#16759
Changes from all commits
2f91a28
7dffa28
882d8b4
dc71c16
c6b1a15
dc2e5ca
0291a23
498a3d4
ed88714
6261b2a
ef675c0
f13b617
801ad00
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,11 +8,15 @@ license = { workspace = true } | |
repository = { workspace = true } | ||
|
||
[features] | ||
default = ["rw-static-link"] | ||
rw-static-link = ["workspace-config/rw-static-link"] | ||
rw-dynamic-link = ["workspace-config/rw-dynamic-link"] | ||
embedded-deno-udf = ["risingwave_expr/embedded-deno-udf"] | ||
embedded-python-udf = ["risingwave_expr/embedded-python-udf"] | ||
default = ["rw-static-link"] | ||
all-udf = ["external-udf", "wasm-udf", "js-udf", "deno-udf", "python-udf"] | ||
external-udf = ["risingwave_expr_impl/external-udf"] | ||
wasm-udf = ["risingwave_expr_impl/wasm-udf"] | ||
js-udf = ["risingwave_expr_impl/js-udf"] | ||
deno-udf = ["risingwave_expr_impl/deno-udf"] | ||
python-udf = ["risingwave_expr_impl/python-udf"] | ||
Comment on lines
+11
to
+19
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. TBO I don't very like feature flags, but acceptable since there are already existing ones. 1 flag is as bad as N flags... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My consideration is that each UDF backend brings many dependencies, and most of our developers don't touch UDF at all. So it would be better to skip them in local development. The same thing could be applied to connectors. For example, I almost never use any connector in my development. Those dependencies could be skipped as well to save my disk. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. BTW, I think it's time to split connector implementations off and design a clear interface for it, as there are now community developers willing to develop new connectors. 🤔 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
BTW, #12981 🤔 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I noticed this PR. It's a little pity it was not merged, but I think it's in the right direction. |
||
|
||
[package.metadata.cargo-machete] | ||
ignored = ["workspace-hack", "workspace-config", "task_stats_alloc"] | ||
|
@@ -32,7 +36,6 @@ risingwave_common = { workspace = true } | |
risingwave_compactor = { workspace = true } | ||
risingwave_compute = { workspace = true } | ||
risingwave_ctl = { workspace = true } | ||
risingwave_expr = { workspace = true } | ||
risingwave_expr_impl = { workspace = true } | ||
risingwave_frontend = { workspace = true } | ||
risingwave_meta_node = { workspace = true } | ||
|
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.
Interesting. Does it mean that we used to release versions without support for embedded
UDF?
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.
I'm considering whether we should make it a default feature but always use
--no-default-features
for RiseDev builds, so that we can avoid such mistakes in the future...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.
Oh yes, the released version did not contain python UDF and deno UDF.
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.
But making these features as default will cause them to be built by rust-analyzer...
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.
I don't think it's worth it:
default
features is to make developers happy, which can be hard to fix.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.
Can also suggest developers to set
rust-analyzer.cargo.noDefaultFeatures
in the editor. 😕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.
The UDF module is touched by few people, so it makes sense to require manual enabling on the features.
However, imagine we're going to add conditional compiles for the connector module, which is actively developed and maintained by a considerable amount of developers. We still need the effort to inform them how to enable these features, especially the IDE part, which is not better than the approach above.
The point is the most of developers do not pay much attention to the compile time. If something comes naturally, it's good. If it requires extra effort, they might give up. Thus in my opinion, it's fine to treat it as a hidden treasure needed to be discovered by some manual efforts. 😄
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.
I 100% agree. However, my opinion from this fact is that it's better to offer "free" fast compile time for developers. If they are not good at it, we'd better make the default faster. Saving every one's time does good to the whole world!
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.
I'm thinking whether it's possible to offer IDE experience without config for feature flags. e.g.,
cfg_or_panic(madsim)
.One idea is that: we put each connector impl in separated crate, which is an optional dependency. If so, maybe the IDE can work without config.
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.
Let's go to #16841