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

How to handle property result in lineage #34

Open
pmaria opened this issue Apr 6, 2023 · 0 comments
Open

How to handle property result in lineage #34

pmaria opened this issue Apr 6, 2023 · 0 comments

Comments

@pmaria
Copy link
Contributor

pmaria commented Apr 6, 2023

The problem

When building lineage in the current way, we represent source or orchestrated properties in the following structure:

{
  "subject": {
    // Object reference
  },
  "property": ... // name of the property
  "value": ... // value of the property
}

There are several challenges here.

Challenge 1: Unknown schema of key properties of object references

In the object reference, we cannot predict the schema of the identifying properties.

The referenced object could have one or more identifying properties. So it is also not possible to map to a single object key.

Currently we have a temporary "solution" which only works for object types with a single identifying property. Here we extract the value of the identifying property and return that as the value of the objectKey in the ObjectReference object. For example;

{
  "subject": {
     "objectKey": "12345",
     "objectType: "Foo"
  },
  "property": ... // name of the property
  "value": ... // value of the property
}

This is not future-proof

Challenge 2: Value type variability

When returning a value for a source or orchestrated property, we cannot know what the value type will be. This could be e.g. one of the scalar types, or an object type, or something else.

For this we currently have a solution that introduces an intermediary node which contains properties named Xvalue where X indicates the type of value. For example:

{
  "subject": {
    "objectKey": "12345",
    "type": "Foo"
  },
  "property": "bar",
  "value": {
    "stringValue": null,
    "booleanValue": true,
    "integerValue": null,
    "objectValue": null,
    ...
  }
}

This is obviously not an ideal solution. And furthermore, the objectValue suffers from the same issue as described in Challenge 1, in that the schema of the referenced object cannot be known upfront.

Possible solutions

Not really sure. We could look into using GraphQl's Custom scalars.
This would however be a burden on clients. That being said, so is the current approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant