Thread
#prefect-community
    j

    Jai P

    5 months ago
    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)?
    Anna Geller

    Anna Geller

    5 months ago
    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 🎉
    Kevin Kho

    Kevin Kho

    5 months ago
    You don’t necessarily need case because you can use the native Python
    if
    inside a flow now.
    @flow
    def myflow():
        a = task_one()
        if a.result() == ...
            ....
    j

    Jai P

    5 months ago
    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..
    Kevin Kho

    Kevin Kho

    5 months ago
    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

    5 months ago
    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
    Kevin Kho

    Kevin Kho

    5 months ago
    Yeah exactly so they aren’t “Skipped” cuz they aren’t added
    j

    Jai P

    5 months ago
    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:
    @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_ford on
    task_two
    or
    task_three
    Kevin Kho

    Kevin Kho

    5 months ago
    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

    5 months ago
    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
    Kevin Kho

    Kevin Kho

    5 months ago
    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

    5 months ago
    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
    Kevin Kho

    Kevin Kho

    5 months ago
    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