Skip to content
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

Expression forks #57491

Merged
merged 4 commits into from
Feb 18, 2020
Merged

Expression forks #57491

merged 4 commits into from
Feb 18, 2020

Conversation

streamich
Copy link
Contributor

@streamich streamich commented Feb 12, 2020

Summary

Closes #56747

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@streamich streamich requested a review from a team as a code owner February 12, 2020 19:29
@streamich streamich added Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) release_note:skip Skip the PR/issue when compiling release notes review Team:AppArch v7.7.0 v8.0.0 labels Feb 13, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-arch (Team:AppArch)

@streamich streamich requested a review from ppisljar February 13, 2020 12:05
Copy link
Member

@ppisljar ppisljar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code LGTM

Copy link
Contributor

@crob611 crob611 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good to me as well.

Trying to think through all of the possible scenarios that could come up. Should we ever allow adding to the main instance, or should that be reserved strictly for expressions plugin itself? Thinking of the scenario where Canvas is using a fork, but another plugin is just adding it's stuff directly to main.

@streamich
Copy link
Contributor Author

@crob611 the idea here is that, both, Lens and Canvas would use forks. There would be default functions in the global registry provided by expressions plugin but also anyone would be able to add more functions to the global registry. Thus, for example, Canvas could add essql function to the global registry so that Lens also has access to it. Though functions registered in the local forks would not be visible to other instances, for example, Lens would register all its lens_* functions in its local registry, thus Canvas will not see those.

That was how I thought about it. But if you have further concerns, say Canvas does not want to make any expression functions available in their autocomplete besides the default ones and the ones explicitly registered by Canvas, we could do that too. We could add some method that returns an instance of ExpressionsService which contains only default functions and does not sync with the global registry. But in that case, I'm a bit concerned that we are losing the ability to easily extend expressions plugin by simply registering functions and types in the global registry.

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@streamich streamich merged commit 6aec465 into elastic:master Feb 18, 2020
streamich added a commit that referenced this pull request Feb 18, 2020
* feat: 🎸 add .fork() methods to ExpressionsService

* feat: 🎸 expose .fork() method in plugin contract
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) release_note:skip Skip the PR/issue when compiling release notes review v7.7.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fork Expressions service
5 participants