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

SavedObjectsRepository.incrementCounter supports array of fields #84326

Merged
merged 9 commits into from
Dec 1, 2020

Conversation

rudolf
Copy link
Contributor

@rudolf rudolf commented Nov 25, 2020

Plugin API changes

The SavedObjectsRepository.incrementCounter method no longer accepts a string field name, an array of field names to increment must be provided.

For maintainers

@rudolf rudolf added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. Feature:Saved Objects v7.11.0 labels Nov 25, 2020
@rudolf rudolf marked this pull request as ready for review November 26, 2020 07:17
@rudolf rudolf requested a review from a team November 26, 2020 07:17
@rudolf rudolf requested a review from a team as a code owner November 26, 2020 07:17
@rudolf rudolf requested a review from a team November 26, 2020 07:17
@rudolf rudolf requested review from a team as code owners November 26, 2020 07:17
@rudolf rudolf requested a review from a team November 26, 2020 07:17
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

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

KibanaApp changes LGTM, didn't test

Copy link
Member

@afharo afharo left a comment

Choose a reason for hiding this comment

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

Telemetry changes LGTM!

Comment on lines 1522 to 1528
* When using incrementCounter for collecting usage data, you need to ensure
* that usage collection happens on a best-effort basis and doesn't
* negatively affect your plugin or users (see the example):
* - Swallow any exceptions thrown from the incrementCounter method and log
* a message in development.
* - Don't block your application on the incrementCounter method (e.g.
* don't use `await`)
Copy link
Member

Choose a reason for hiding this comment

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

I love this remark 🧡

Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't that a bit misplaced though? I would expect that kind of comment/guidelines to be in the usage collection plugin's README instead of being documented in a core API?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah I agree, this doesn't really belong in the SavedObjectsRepository's documentation. But I everywhere where this method was called teams awaited this promise and I'm afraid they won't read the docs in the plugin's readme.

We could maybe move this to the usage data plugin's docs and add a link to the docs. Because the link will be from tsdocs -> markdown it might be best to link to the github url for that file. WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yea, I would go with something like

When using incrementCounter for collecting usage data, you need to ensure 
that usage collection happens on a best-effort basis and doesn't  negatively 
affect your plugin or users. Please refer to the [usage collection documentation](link) for more details.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Copy link
Contributor

@jloleysens jloleysens left a comment

Choose a reason for hiding this comment

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

Upgrade Assistant changes look good to me!

Copy link
Contributor

@streamich streamich left a comment

Choose a reason for hiding this comment

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

AppArch changes LGTM.

Copy link
Contributor

@scottybollinger scottybollinger left a comment

Choose a reason for hiding this comment

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

LGTM from Enterprise Search

Comment on lines 1522 to 1528
* When using incrementCounter for collecting usage data, you need to ensure
* that usage collection happens on a best-effort basis and doesn't
* negatively affect your plugin or users (see the example):
* - Swallow any exceptions thrown from the incrementCounter method and log
* a message in development.
* - Don't block your application on the incrementCounter method (e.g.
* don't use `await`)
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't that a bit misplaced though? I would expect that kind of comment/guidelines to be in the usage collection plugin's README instead of being documented in a core API?

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

✅ unchanged

History

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

@jportner
Copy link
Contributor

jportner commented Dec 1, 2020

@rudolf We spoke offline about adding a flag to initialize specified fields to 0.

In addition to that: while implementing #80945, I've found another improvement we could make to the incrementCounter method.

When a "legacy URL alias" is resolved, we want to increment a counter and update a timestamp. I thought I would mention it here in case you think it makes sense to add support for updating a timestamp field in this PR.

Copy link
Contributor

@pgayvallet pgayvallet left a comment

Choose a reason for hiding this comment

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

initialize option changes LGTM

@rudolf
Copy link
Contributor Author

rudolf commented Dec 1, 2020

When a "legacy URL alias" is resolved, we want to increment a counter and update a timestamp. I thought I would mention it here in case you think it makes sense to add support for updating a timestamp field in this PR.

We could certainly add a parameter like timestampFieldNames. Though it feels like we would need to rename the method since we're no longer just incrementing a counter. Something like scriptedUpdate(type: string, id: string: actions: [{type: 'increment_counter'|'update_timestamp', field: string}]) might be a nice abstraction so that we can later add additional useful action types which require scripting.

For "legacy URL alias" do we require a generic public method on the repository (like incrementCounter/scriptedUpdate), or could we put this scripting inside the resolve() method?

@rudolf rudolf merged commit 4507865 into elastic:master Dec 1, 2020
@rudolf rudolf deleted the incrementcounter branch December 1, 2020 10:28
rudolf added a commit that referenced this pull request Dec 1, 2020
) (#84613)

* SavedObjectsRepository.incrementCounter supports array of fields

* Fix TS errors

* Fix failing test

* Ensure all the remarks make it into our documentation

* SavedObjectsRepository.incrementCounter initialize option

* Move usage collection-specific docs out of repository into usage collection plugins readme

* Update api docs

* Polish generated docs
@jportner
Copy link
Contributor

jportner commented Dec 1, 2020

For "legacy URL alias" do we require a generic public method on the repository (like incrementCounter/scriptedUpdate), or could we put this scripting inside the resolve() method?

Good point, we don't really need a generic public method for this!

@bhavyarm
Copy link
Contributor

@rudolf how do I test this please? Thanks!

@rudolf
Copy link
Contributor Author

rudolf commented Jan 19, 2021

@bhavyarm this changes the shape and functionality of an API that I think is exclusively used for telemetry so there's no user-facing changes that can be tested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Saved Objects release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.11.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.