Remove some InstanceType fields to simplify events

[alexandra-bucur]

Signed-off-by: Alexandra Bucur alexandra-nona.bucur@ing.com

Description

In order to improve performance when it comes to events sent through the cohort, I removed typeDefDescription, typeDefDescriptionGUID, typeDefSuperTypes, validStatusList and validInstanceProperties fields from InstanceType class.

Testing

JUnits, FVTs, CTS repository workbench, Notebook labs for building a data catalog - passed.

[sonatype-lift]

🛠 Lift Auto-fix

Some of the Lift findings in this PR can be automatically fixed. You can download and apply these changes in your local project directory of your branch to review the suggestions before committing.¹

# Download the patch
curl https://lift.sonatype.com/api/patch/github.com/odpi/egeria/7321.diff -o lift-autofixes.diff

# Apply the patch with git
git apply lift-autofixes.diff

# Review the changes
git diff

Want it all in a single command? Open a terminal in your project's directory and copy and paste the following command:

curl https://lift.sonatype.com/api/patch/github.com/odpi/egeria/7321.diff | git apply

Once you're satisfied commit and push your changes in your project.

Footnotes

1. You can preview the patch by opening the patch URL in the browser. ↩

[mandy-chessell]

Just a few layout issues - but the rest looks good

[cmgrote]

Is this considered a backwards-compatible change? (Or maybe it doesn't need to be given we're bumping to v4.0?)

This has an impact on repository connectors that are, for example, storing all of these details as part of the instance type. (And in cases like XTDB relying on them to do validation of the details of instances — supertypes, valid properties, etc.)

^^ My fear with simply replacing this with retrieving the current / most up-to-date version of a typedef to do such validations is whether they may have changed over time — could be a problem for repositories that support historical instances (where the "schema" (typedef) may have changed since the historical version of an entity was stored, and thus the validation of that historical version of the entity should (presumably) still be done against the historical "schema" (typedef) that was used when it was stored — not the most current / up-to-date version of the typedef in the repository?)

[alexandra-bucur]

@cmgrote Hi Chris! Let's discuss this on the next developers call.