risingwavelabs / risingwave

Best-in-class stream processing, analytics, and management. Perform continuous analytics, or build event-driven applications, real-time ETL pipelines, and feature stores in minutes. Unified streaming and batch. PostgreSQL compatible.

https://go.risingwave.com/slack

Apache License 2.0

7k stars 576 forks source link

Tracking: Introduce per-module error type for frontend #2366

Open lmatz opened 2 years ago

lmatz commented 2 years ago

As mentioned in #1367.

Tracking:

[x] #3247
[x] https://github.com/singularity-data/risingwave/issues/2035
[ ] Introduce HandleError Type
[ ] Introduce PlanError Type
[x] Introduce ScheduleError Type
[x] #3082
[x] #3089

TennyZhuang commented 2 years ago

2035 can be tracked in the issue

likg227 commented 2 years ago

How about OptimizeError?

lmatz commented 2 years ago

How about OptimizeError?

Maybe an enum of PlanError? It seems the optimization rules return Option instead of Result, similar to Calcite returning a Null in the event of a failure of rule application.

But we will see whether it is necessary later and we can add it then.

likg227 commented 2 years ago

We do need it to check whether apply can be unnested or not. https://github.com/singularity-data/risingwave/pull/2187#discussion_r861475292

likg227 commented 2 years ago

The reason our current optimizer returns Option is for writting code easily........

BugenZhao commented 8 months ago

After #14953, I believe there's a stronger motivation for addressing this issue.