refactor: rename 'expression' for clarity

[chris-fei-rokt]

Instructions

1. PR target branch should be against development
2. PR title name should follow this format: https://github.com/mParticle/mparticle-workflows/blob/main/.github/workflows/pr-title-check.yml
3. PR branch prefix should follow this format: https://github.com/mParticle/mparticle-workflows/blob/main/.github/workflows/pr-branch-check-name.yml

Summary

• Rename Expression to Condition
• Rename Operand to Expression
• Remove what were previously Expressions that didn't cleanly fit. For example DateExpression, "Represents an expression that evaluates to a date or date-based condition". Fairly certain these are not being used
• Renamed group_by to group_by_model per prior discussions

Testing Plan

• Was this tested locally? If not, explain why.
• {explain how this has been tested, and what, if any, additional testing should be done}

Reference Issue (For mParticle employees only. Ignore if you are an outside contributor)

• Closes https://go.mparticle.com/work/REPLACEME

[danielsiemens]

let's rename the parent folder to be expression

[chris-fei-rokt]

Ah yes, I was leaving the folder rename for later to minimize diffs

[danielsiemens]

should we rename operand to expression?

[chris-fei-rokt]

No, I think it's ok

[danielsiemens]

This feels a bit semantically awkward in my brain. I wonder if we should rename the attribute something like filter: Condition?

[olegk-rokt]

condition: Condition ?

[chris-fei-rokt]

This doesn't bother me. The root audience key is the entry point into defining the criteria for an audience, which is a Condition

[cbowie-mp]

Should this be expression still? In my mind, condition is a filter operation. Likely only relevant to aggregate operations. I would say:

• Expression == thing the operator is acting on
• Condition == expression that determines which things are operated on (aka, filters the input)

[olegk-rokt]

My vote is to leave it as is. In my mind logical condition can only contain conditions and Condition == expression that returns boolean

[chris-fei-rokt]

No, Condition applies everywhere, not just aggregate operations. The root expression for an audience evaluates to a boolean to determine membership, e.g.

{
  "operator": "and",
  "conditions": [
    { .. condition 1 .. },
    { .. condition 2 .. },
  ]
}

is itself a Condition

[cbowie-mp]

The root expression for an audience evaluates to a boolean to determine membership

I didn't notice this was directly on the audience, but I agree the top level should be a condition. Not a fan of the current syntax, honestly - I would do:

"audience" : {
    "condition": { some bool expression },
}

That way the top level isn't forced to follow the expression syntax, which is more flexible for the future.

I think the other expressions should only use condition as a filter though - so any nested and/or would NOT use condition since they aren't checking a condition, just evaluating an expression. Condition implies check to me, but there are only two checks currently, on aggregates and at the base query.