https://prefect.io logo
#prefect-community
Title
# prefect-community
j

Jai P

04/26/2022, 5:39 PM
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

Anna Geller

04/26/2022, 5:41 PM
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

Kevin Kho

04/26/2022, 5:41 PM
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

Jai P

04/26/2022, 5:44 PM
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

Kevin Kho

04/26/2022, 5:47 PM
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

Jai P

04/26/2022, 8:04 PM
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

Kevin Kho

04/26/2022, 8:20 PM
Yeah exactly so they aren’t “Skipped” cuz they aren’t added
j

Jai P

04/26/2022, 9:49 PM
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

Kevin Kho

04/26/2022, 9:54 PM
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

Jai P

04/26/2022, 9:54 PM
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

Kevin Kho

04/26/2022, 9:56 PM
Yes that is completely right. Just wondering, how important is it for you to have all of those connected in the Radar plot?
j

Jai P

04/26/2022, 10:03 PM
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

Kevin Kho

04/26/2022, 10:06 PM
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
5 Views