Saved object relationships

[mikecote]

A standard attribute is needed within each saved object that indicates what references to other saved objects it has. This will facilitate saved object export to know what other objects it needs to export for each.

From the UI side, the initial implementation can have hooks in the saved object class to extract references (pre save) and to put them back in (post read) to avoid having too many breaking changes.

In the future this could allow an expand feature where you don't have to go back to the server to get nested objects.

Dashboard example:

{
  ...
  "attributes": {
    ...
    panelsJSON: [{ ... panelRef: 'panel_0' ...}]
  },
  "references": [{
      "name": "panel_0",
      "type": "visualization",
      "id": "dbf71bb0-ffad-11e8-acfd-d359b3d9069"
  }]
}

Prototype: #27155.

[elasticmachine]

Pinging @elastic/kibana-platform

[epixa]

@mikecote This approach seems good to me.

@legrego Is this compatible with spaces? Particularly for that downgrade to OSS workflow that we nitpicked forever.

[legrego]

Is this compatible with spaces? Particularly for that downgrade to OSS workflow that we nitpicked forever.

This looks to be compatible with spaces, including the downgrade scenarios. A couple of things to keep in mind:

1. I'm assuming that saved objects can only reference other objects in the same space. In other words, no cross-space references.
2. The saved object ids under the references section should not have the space identifier included. Mike's example above looks good. The following is a bad example:

{
  ...
  "attributes": {
    ...
    panelsJSON: [{ ... panelReference: 'panel_0' ...}]
  },
  "references": {
    "panel_0": {
      "id": "marketing:visualization:dbf71bb0-ffad-11e8-acfd-d359b3d9069",
      "type": "visualization"
    }
  }
}

It's possible that we'll want to include the referenced object's namespace (the OSS version of a Space ID) in the raw document that we save to Elasticsearch, and then strip it out in the SavedObjectsRepository before being consumed. This could facilitate future use-cases, where we'd need to know the referenced object's namespace. Or perhaps a separate field for this information:

{
  ...
  "attributes": {
    ...
    panelsJSON: [{ ... panelReference: 'panel_0' ...}]
  },
  "references": {
    "panel_0": {
      "id": "dbf71bb0-ffad-11e8-acfd-d359b3d9069",
      "type": "visualization",
      "namespace": "marketing"
    }
  }
}

[mikecote]

I'm assuming that saved objects can only reference other objects in the same space. In other words, no cross-space references.

The saved object ids under the references section should not have the space identifier included.

@legrego You are correct on both of these.

It's possible that we'll want to include the referenced object's namespace (the OSS version of a Space ID) in the raw document that we save to Elasticsearch, and then strip it out in the SavedObjectsRepository before being consumed.

This seems easily doable, I will give that a try and reach out if I have any questions. Thanks!

[mikecote]

@legrego was speaking with @spalger and it seems better to leave the namespace out of the references at this time to avoid confusion. Since all references belong in the same namespace, we can rely on the root namespace of the saved object to tell which namespace each reference belongs into. If ever we change our minds in the future, we can write up an easy migration.

If there is a piece I missed or misunderstood that you think would make namespace important, I am open for discussion.

[legrego]

@mikecote thanks for the explanation, and I mostly agree. No objections here if that's the path we want to take.

My understanding of Migrations as they exist today is that each saved object type can only be migrated by a single plugin. In other words, once a plugin declares a migration for a particular saved object type, no other plugins can add migrations for that type. This isn't necessarily a bad thing, but if we needed this migration in the future, each plugin would have to define/duplicate that migration logic in order to be compliant. We can easily document this for first and third-party plugin authors, but it could be somewhat tedious. There's a lot of ifs here, and we may never need this, but I wanted to make sure we understood the implications.

[mikecote]

@legrego I see what you mean now, I have the same situation at this moment to migrate existing saved objects to use references. The base saved object class manages index patterns so I will need to find a way to make migrations run on any type of saved object. I will investigate and keep that in mind.

[epixa]

Both of these things are "core" details, so we could update the saved object service to allow for core migrations that can be applied universally to all objects.

[mikecote]

@epixa Agreed, I will go that path when I create the migrations.