Skip to content

Index pattern serialize and de-serialize#68844

Merged
mattkime merged 50 commits intoelastic:masterfrom
mattkime:index_pattern_serialize
Jun 25, 2020
Merged

Index pattern serialize and de-serialize#68844
mattkime merged 50 commits intoelastic:masterfrom
mattkime:index_pattern_serialize

Conversation

@mattkime
Copy link
Copy Markdown
Contributor

@mattkime mattkime commented Jun 11, 2020

Summary

IndexPattern.toSpec() and IndexPatternService.specToIndexPattern(indexPatternSpec)

part of #68003

Checklist

For maintainers

Copy link
Copy Markdown
Contributor

@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.

minor comments but really excited to see this !


export interface IndexPatternSpec {
_id: string;
_type: string;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

whats a type ? are this saved object properties ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yes, its a saved object property.

_id: string;
_type: string;
_source: {
title: string;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

why are this under _source ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

feels like we might just want whats under _source ? could we restore index pattern withoiut the other stuff ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@ppisljar I agree that we could do that and it would likely be sufficient for your needs. However, that would be a different IndexPattern - one that couldn't be saved. I'd prefer to have just one kind of index pattern. We could consider having different types after some of the planned refactoring.

Copy link
Copy Markdown
Contributor

@ppisljar ppisljar Jun 16, 2020

Choose a reason for hiding this comment

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

what do you mean it couldn't be saved ? if

export interface IndexPatternSpec {
  id: string;
  title: string;
  timeFieldName?: string;
  fields: FieldSpec[];
  version: string;
}

and then specToIndexPattern takes this in and gives you back indexPattern instance that can be saved.

lets try to make this IndexPatternSpec a bit easier to handle and more futureproof if possible. the information on how saved object looks like does not need to be exposed to the consumer (IndexPatternSpec can have a different shape as long as it contains sufficient information to reconstruct index pattern out of it)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

version can also be removed as that's a saved object thing

Copy link
Copy Markdown
Contributor Author

@mattkime mattkime Jun 16, 2020

Choose a reason for hiding this comment

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

I guess I didn't understand what you were asking for, happy to implement IndexPatternSpec as explained above.

That said, I think we need to keep version as its used when updating an index pattern saved object.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

we should always assume the latest version when creating index pattern from spec.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

version is used to ensure there aren't write collisions.

@mattkime mattkime changed the title Index pattern serialize Index pattern serialize and de-serialize Jun 11, 2020
@mattkime mattkime marked this pull request as ready for review June 12, 2020 04:27
@mattkime mattkime requested a review from a team as a code owner June 12, 2020 04:27
@elasticmachine
Copy link
Copy Markdown
Contributor

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

@mattkime mattkime added Feature:Data Views Data Views code and UI - index patterns before 8.0 v8.0.0 v7.9.0 release_note:skip Skip the PR/issue when compiling release notes labels Jun 12, 2020
@mattkime
Copy link
Copy Markdown
Contributor Author

@elasticmachine merge upstream

@mattkime
Copy link
Copy Markdown
Contributor Author

I'm also not clear on why we have version since we'd always be creating the latest version from the spec. @mattkime you had mentioned this was to avoid write conflicts; could you provide more background on the use case there?

Here's an example version value - WzE3NTgsMV0= - the specific value, as best I can tell, is random, or maybe its a hash of the saved object content. It changes each time the saved object is updated. If you try to save but version doesn't match it will be rejected - someone else already updated it.

Why does this pertain to IndexPatterns? It has logic for reattempting saving when there are conflicting save attempts.


perhaps I should change the value in IndexPatterns to be savedObjectVersion

@mattkime
Copy link
Copy Markdown
Contributor Author

Overall naming consistency nit

FieldFormats uses .toJSON as best I can tell. To me, serialized/deserialize means to and from string. Same for .toJSON although it returns a spec. That said, I'm happy to go along with how its done elsewhere.

@lukeelmers
Copy link
Copy Markdown
Contributor

To me, serialized/deserialize means to and from string

Yeah I know @ppisljar and I have discussed this before too. Since technically we are returning serializable state but not serialized state. I've seen usage of toJSON as well, which is handy in the case where you are actually serializing it (via JSON.stringify).

This is something I don't feel strongly about either, just falls into the same category for me of "stuff we should try to make consistent"

Perhaps toJSON and fromJSON instead of serialize and deserialize? @ppisljar do you have any thoughts on this?

@mattkime
Copy link
Copy Markdown
Contributor Author

mattkime commented Jun 23, 2020

Perhaps toJSON and fromJSON instead of serialize and deserialize?

I literally can't use that with the Field class because its used for serializing to saved object which is a different format. Index Pattern uses it as well but it just returns the id.

@mattkime
Copy link
Copy Markdown
Contributor Author

++ I realize the existing type for this is Record<string, any>, but it would be really nice if it could be tightened up based on the return value of toSpec.

I'm going to see if I can tighten up the types on toSpec without impacting other code.

@elastic elastic deleted a comment from kibanamachine Jun 24, 2020
@ppisljar
Copy link
Copy Markdown
Contributor

i don't have preference about naming the functions, but i agree it would be nice if we would be consistent about it. Actually toSpec might be the best suggestion so far, i don't like serialize as it doesn't serialize, toJSON is nice as Luke mentions but can't be used everywhere.

@mattkime
Copy link
Copy Markdown
Contributor Author

@elasticmachine merge upstream

@kibanamachine
Copy link
Copy Markdown
Contributor

💚 Build Succeeded

Build metrics

@kbn/optimizer bundle module count

id value diff baseline
data 207 -1 208

History

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

Copy link
Copy Markdown
Contributor

@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
Copy Markdown
Contributor

@lukeelmers lukeelmers left a comment

Choose a reason for hiding this comment

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

Changes LGTM! Using toSpec and fromSpec works for me - we can look into changing those in aggs & visualize for consistency.

Copy link
Copy Markdown
Member

@kertal kertal left a comment

Choose a reason for hiding this comment

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

KibanaApp Code LGTM, didn't test the test, I trust good ol' jenkins to do so

@mattkime mattkime merged commit b02e2d9 into elastic:master Jun 25, 2020
gmmorris added a commit to gmmorris/kibana that referenced this pull request Jun 25, 2020
* master: (90 commits)
  [Encrypted Saved Objects] Adds support for migrations in ESO (elastic#69513)
  [SIEM] Replace WithSource with useWithSource hook (elastic#68722)
  [Endpoint]EMT-451: add ability to filter endpoint metadata based on presence of unenrolled events (elastic#69708)
  rename old siem kibana config to securitySolution (elastic#69874)
  Remove unused Resolver code (elastic#69914)
  [Observability] Fixing dynamic return type based on the appName (elastic#69894)
  [SECURITY SOLUTION][INGEST] Task/endpoint list tests (elastic#69419)
  Fixes special clicks and 3rd party icon sizes in nav (elastic#69767)
  [APM] Catch annotations index permission error and log warning (elastic#69881)
  [Endpoint][Ingest Manager] minor code cleanup (elastic#69844)
  [Logs UI] Logs ui context menu (elastic#69915)
  Index pattern serialize and de-serialize (elastic#68844)
  [QA] Unskip functional tests (elastic#69760)
  [SIEM][Detection Engine] - Update DE to work with new exceptions schema (elastic#69715)
  Fixes elastic#69639: Ignore url.url fields above 2048 characters (elastic#69863)
  PR: Provide limit warnings to user when API limits are reached. (elastic#69590)
  [Maps] Remove broken button (elastic#69853)
  Makes usage collection methods available on start (elastic#69836)
  [SIEM][CASE] Improve Jira's labelling (elastic#69892)
  [Logs UI] Access ML via the programmatic plugin API (elastic#68905)
  ...
mattkime added a commit to mattkime/kibana that referenced this pull request Jun 25, 2020
* serialize and deserialize index patterns

# Conflicts:
#	src/plugins/data/common/index_patterns/index_patterns/index_pattern.ts
#	src/plugins/data/common/index_patterns/index_patterns/index_patterns.ts
#	src/plugins/data/common/index_patterns/types.ts
#	src/plugins/data/public/index.ts
mattkime added a commit that referenced this pull request Jun 25, 2020
* Index pattern serialize and de-serialize (#68844)
gmmorris added a commit to gmmorris/kibana that referenced this pull request Jun 26, 2020
* master:
  [Encrypted Saved Objects] Adds support for migrations in ESO (elastic#69513)
  [SIEM] Replace WithSource with useWithSource hook (elastic#68722)
  [Endpoint]EMT-451: add ability to filter endpoint metadata based on presence of unenrolled events (elastic#69708)
  rename old siem kibana config to securitySolution (elastic#69874)
  Remove unused Resolver code (elastic#69914)
  [Observability] Fixing dynamic return type based on the appName (elastic#69894)
  [SECURITY SOLUTION][INGEST] Task/endpoint list tests (elastic#69419)
  Fixes special clicks and 3rd party icon sizes in nav (elastic#69767)
  [APM] Catch annotations index permission error and log warning (elastic#69881)
  [Endpoint][Ingest Manager] minor code cleanup (elastic#69844)
  [Logs UI] Logs ui context menu (elastic#69915)
  Index pattern serialize and de-serialize (elastic#68844)
@mattkime mattkime mentioned this pull request Jul 13, 2020
12 tasks
@mattkime mattkime mentioned this pull request Sep 24, 2020
63 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Feature:Data Views Data Views code and UI - index patterns before 8.0 release_note:skip Skip the PR/issue when compiling release notes v7.9.0 v8.0.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants