https://prefect.io
Join Slack
hey all! question about the eventual introduction of the `case` statement in prefect 2.0: is there a...
# ask-community
j
hey all! question about the eventual introduction of the 
case
statement in prefect 2.0: is there a rough timeline for when that may be introduced? Also, are there any major differences that are planned between how they work in prefect 1.0, where i think you can only conditionally go between tasks (to, say, possibly supporting subflows)?
a
there is no need for that - you can run any if/else statements both in your tasks and in your flows in Prefect 2.0 🎉
k
You don’t necessarily need case because you can use the native Python 
if
inside a flow now.
Copy code
@flow
def myflow():
    a = task_one()
    if a.result() == ...
        ....
j
ah yes! i saw that was possible, but i could've sworn in the documentation it said 
case
was coming, and i wasn't sure in what case i'd use that over just native 
if
but now i can't find said quote in the documentation..
k
I don’t quite see a use case for 
case
because 
if
is more flexible. The previous 
case
only tested for equality. Not greater than or less than so you needed an intermediate task to achieve that.
j
hmmm, ok! i mean i like using 
if
statements more, but im curious if that has the same implication that it did in prefect 1.0 (meaning tasks/subflows not run due to an 
if
are marked as 
Skipped
)
but maybe that's not the intended experience, and the tasks aren't really "Skipped", they're not even considered as part of the execution path so they're never included
k
Yeah exactly so they aren’t “Skipped” cuz they aren’t added
j
got it! so i guess the one interesting thing is...because now you're essentially forced to call 
.result()
, does that possibly introduce some weirdness in execution/dependencies?
as an example:
Copy code
@flow
def my_flow():
    a = task_one()
    if a.result():
        task_two()
    else:
        task_three()
i won't necessarily see that 
task_one
was `wait_for`d on 
task_two
or 
task_three
k
You can still use 
wait_for
in 
task_two
and 
task_three
but they will wait for 
a
by default. 
.result()
is actually 
.wait().result()
implicitly
j
yup! i guess it was just pointing out that 
orion
wouldn't necessarily reflect the waiting
so as an engineer if you want to ensure that the dependency properly shows up in orion, you need the 
wait_for
. if you don't care about that particular thing...then it is fine because it implicitly happens anyways
k
Yes that is completely right. Just wondering, how important is it for you to have all of those connected in the Radar plot?
j
I don't actually know that it's that important for us yet, though i can imagine situations where someone wants to understand the flow execution visually, but can't because everything is laid out on the radar view at the same level
But given there's a simple workaround that isn't that code intensive, I think we can work around that
k
That’s true but I noticed this as well when doing something like A -> B -> C and all are mapped and then some number of A raise SKIP. Lineage gets broken. But we will explicit create a SKIP state though in the future that connects it
đź‘Ť 1
20 Views
Open in Slack
PreviousNext
Powered by

Prefect Community

Bring your towel and join one of the fastest growing data communities. Welcome to our second-generation open source orchestration platform, a completely rethought approach to dataflow automation.

Powered by