z3z1ma
commented
3 years ago export function parseOperators(operands, operators) {
let initial = operands[0];
const stack = [];
for (let i = 1; i < operands.length; i++) {
const operator = operators[i - 1];
const operand = operands[i];
const top = stack[stack.length - 1];
if (top) {
if (top[0] === operator) {
top.push(operand);
} else {
const a = OPERATOR_PRECEDENCE[operator];
const b = OPERATOR_PRECEDENCE[top[0]];
if (b < a) {
top[top.length - 1] = [operator, top[top.length - 1], operand];
stack.push(top[top.length - 1]);
} else {
do {
stack.pop();
} while (
stack.length > 0 &&
OPERATOR_PRECEDENCE[stack[stack.length - 1][0]] > a
);
if (stack.length > 0) {
stack[stack.length - 1].push(operand);
} else {
initial = [operator, initial, operand];
stack.push(initial);
}
}
}
} else {
initial = [operator, initial, operand];
stack.push(initial);
}
}
return initial;
}
export const OPERATOR_PRECEDENCE = {
not: 17,
"*": 15,
"/": 15,
"+": 14,
"-": 14,
and: 6,
or: 5,
};So looking at the above compiler, lets look at the output we are looking for. Here we can introspect an existing metric I have created.
[
{
"description": "Unit uptime is understood as count of communicating non-impacted panels over communicating panels.",
"archived": false,
"table_id": 53,
"definition": {
"source-table": 53,
"aggregation": [
[
"aggregation-options",
[
"/",
[
"sum",
[
"field",
1674,
null
]
],
[
"sum",
[
"field",
1676,
null
]
]
],
{
"display-name": "kpi_unit_uptime"
}
]
]
},
"creator": {
"email": "alex@...",
"first_name": "Alex",
"last_login": "...",
"is_qbnewb": false,
"is_superuser": true,
"id": 2,
"last_name": "...",
"date_joined": "...",
"common_name": "..."
},
"database_id": 2,
"show_in_getting_started": false,
"name": "Unit Uptime",
"caveats": null,
"creator_id": 2,
"updated_at": "...",
"query_description": {
"table": "fct_core_unit_uptime_stats",
"aggregation": [
{
"type": "aggregation",
"arg": "kpi_unit_uptime"
}
]
},
"id": 9,
"how_is_this_calculated": null,
"created_at": "...",
"points_of_interest": null
}
]With a little deep diving, I am pretty confident we can compile the expected input without needing to use their exact source code. The above code can translate 1 to 1 to python pretty easily.
The challenge is translating yml meaningfully to the expectation whilst making it simple and readable to the end user. Kind of spitballing below but it can get a little complicated if we dont approach it from a readability first perspective. So I guess my end opinion is that the compilation in python isnt as much the constraint in my eyes as is the format for defining these in the yml.
models:
- name: my_model
# Model level meta tag for cross column metrics?
meta:
metrics:
- name: kpi_profit
aggregation:
operands:
# maybe operand[0] is a nested operation
- operands:
- price
- quantity
operators:
- *
# operand[0] _could_ just be constant / field name too?
# - order_value
operators:
- sum
columns:
- name: price
meta:
metrics:
- name: most_expensive
aggregation:
type: max
- name: inflated_price_sum
aggregation:
operands:
- "self"
- 2.54
operators:
- *
type: sum
remigabillet
buremba
fabrice-etanchaud
jankatins
willbryant
ValdarT
janmechtel
gouline
Metabase Metrics (and in particular custom aggregations) are very useful to our end-users. I'm finding myself spending a lot of time in Metabase managing Metrics, the UI is very inconvenient.
I'd like to be able to define a list of Metabase Metrics on DBT models as schema model
metaproperties. I wonder if this fits this project's scope. The primary challenge is parsing the Metabase expressions which are defined as string (ex:Distinct(case([step] = "hired", [candidate_user_id])) into trees that the API can handle. I think it's easiest to maintain if I compile the JS parser from metabase source code into a small node script that can be committed and called from this project.This would add a good amount of complexity so it's probably beyond the scope of the project. I thought I would share for the sake of discussion.