IF ELSE statements

[gronke]

PR Info

• Dependencies:
  • Triggers #824

New Features

• IF ELSE statements

Breaking Changes

• Add SimpleExpr::IfElse variant to public enum

[Expurple]

Haven't reviewed the rest yet. Consider running cargo semver-checks to find and document the breaking changes.

Disclaimer: I'm not a maintainer

[Expurple]

I don't like this panic. See #829 (comment). Although, I don't know anything about the backend design in sea_query. Maybe that's just how we do things here.

Maybe, SimpleExpr just shouldn't contain non-portable variants and we should come up with a different way of handling IfElseStatement.

@tyt2y3 @Huliiiiii, do you have any thoughts?

[Huliiiiii]

Yes, our usual approach is to panic when features are not supported.

There are two ways to solve this problem:

1. Make IfElseStatement behind the feature gate
2. Modify these kind of functions to return result (breaking)

[Expurple]

Make IfElseStatement behind the feature gate

I think, it doesn't solve all the issues. It's nice that you won't be able to use if-else if you activate only sqlite backend. But if you activate e.g. sqlite+postgres backends, then this syntax becomes available and you can pass it to the sqlite backend and hit a runtime panic.

Ideally, it should be impossible to pass. But I'm not sure how achievable for us and convenient for the user is that. Someone needs to experiment and document the results.

Modify these kind of functions to return result (breaking)

This is a more achievable route that we could explore and see if it's annoying for the user. Sadly, I don't have time for this right now

[gronke]

We could implement backend specific features, closely resembling local specifics. Later then we could build a general IfElseStatement that normalizes the expression of logic and polyfills for each backend.

My personal use case for If-Else statements are triggers. Triggers could be made conditional on SQLite with WHEN clauses by splitting up the one trigger into multiple. Elsewhere our conditions could break down to CASE expressions. Would love to hear whether that would be a general direction to consider.

Meanwhile we could prepare such step by building backend specific features that only later become available globally. It would be nice to avoid panicking, but it would also be possible to solve that later by introducing a polyfill.