-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(hogql): local evaluation (HogVM part 2) #16275
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All seems well!
describe('HogQL Bytecode', () => { | ||
test('execution results', () => { | ||
const fields = { properties: { foo: 'bar' } } | ||
expect(executeHogQLBytecode(['_h', op.INTEGER, 2, op.INTEGER, 1, op.PLUS], fields)).toBe(3) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be nice to re-use the generated bytecode from the python tests e.g. by storying them in a JSON file keyed by HogQL expression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely agree. I'd like to get to a state where we can confidently say the same code executes the same way on all platforms. Let's leave this for a future refactor. Thanks for the review! 👍
Problem
The HogQL local evaluation PR (aka HogVM) is getting out of control. I'll split it into at least
threefour. This is part two, and it contains the HogVM local evaluation engine. Part 3 will add cohort support. Part 4 will connect this to actions.Changes
---> View the README for HogVM for more details. <---
Next steps
in cohort
working. The VM shouldn't know about our data model, but just ask the lightweight wrapper around it for an async answer tois 'Timmy' in cohort 2
.How did you test this code?
Added tests.