Weird bug with properties used both in `with` and `if`

[jollygreenlaser]

Weird bug with properties used both in `with` and `if`

[msullivan]

Could you provide a definition of Status or tweak it to not use a scalar that's missing? Thanks!

[jollygreenlaser]

@msullivan done

[msullivan]

Thanks! It looks like this is some sort of insane path factoring related bug. Ahhhhhh: because .status is path factored out, it is "visible" from its use in the nested select, which combined with the union as part of the if condition, is causing trouble.

I'm digging into it more, but if you put the reference to .status in the if condition inside a subquery ((select .status) or {.status}) it prevents the issue.

A reduced version is

select C {
  bs := (
    with complete := .status
    select {
      complete := complete,
    }
  ) if .status != 'Private' else {}
};

[jollygreenlaser]

Smart. Forgot to mention, I got around it by throwing the if check as a part of the filter on the select. Seems to be mildly faster too.

[msullivan]

Smart. Forgot to mention, I got around it by throwing the if check as a part of the filter on the select. Seems to be mildly faster too.

Yeah, that is a generally cleaner approach and will typically be faster. FILTER (WHERE in SQL) is a pretty fundamental concept in SQL, and IF is not.

[msullivan]

Another note: the ability to have an object with a shape in the then clause of an if and and empty set in the else clause and have it preserve the output shape was introduced completely by accident in 4.0. I didn't realize it worked until the issue. Normally an if always loses the output shape.

Arguably it's a bug that it doesn't here.