Override not editable fields during updates

[lampajr]

Fixes https://github.com/opendatahub-io/model-registry/issues/199

Description

As per related issue description, this PR aims to fix the update issue for InferenceService and ServeModel.
Created OverrideNotEditableFor<Entity> converters that take <existing, update> and override the NOT editable fields in the update object by taking those values from the existing.

With this approach I was able to remove the Name override in the core functions.

NOTE: everytime we add a new field in the openapi spec that can be editable, we should ignore it in the OverrideNotEditableFor<Entity> converters.

Since I have updated the goverter version, I recommend to run make clean/deps and then make build to download te proper version of goverter.

How Has This Been Tested?

make test

Merge criteria:

• The commits and have meaningful messages; the author will squash them after approval or will ask to merge with squash.
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work

[tarilabs]

Great catch! Thank you so much

As discussed offline, if there is a quick way via introspection/parsing to determine the // annotation so to make sure is updated with the list of fields using pointer semantic in the struct, it would be awesome.
If that takes too much time, could be postponed for later

[lampajr]

As discussed offline, if there is a quick way via introspection/parsing to determine the // annotation so to make sure is updated with the list of fields using pointer semantic in the struct, it would be awesome. If that takes too much time, could be postponed for later

+1 I will try to investigate if there is an easy way to ensure that all fields that are editable are NOT overridden, keep you posted here.

[lampajr]

+1 I will try to investigate if there is an easy way to ensure that all fields that are editable are NOT overridden, keep you posted here.

I think I have found a possible approach for testing this using reflection and inspection of the goverter methods directives. Hope to provide a proposal on Monday :)

[codecov-commenter]

Codecov Report

Attention: 52 lines in your changes are missing coverage. Please review.

Comparison is base (06ea855) 74.33% compared to head (2e01650) 72.53%.

Files	Patch %	Lines
internal/converter/openapi_converter_util.go	0.00%	35 Missing ⚠️
pkg/core/core.go	52.77%	11 Missing and 6 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #200      +/-   ##
==========================================
- Coverage   74.33%   72.53%   -1.81%     
==========================================
  Files          15       16       +1     
  Lines        2159     2210      +51     
  Branches       68       68              
==========================================
- Hits         1605     1603       -2     
- Misses        405      452      +47     
- Partials      149      155       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tarilabs]

Awesome! I understand works as expected, and the parser used is even in Go stdlib

[tarilabs]

I suspect there must be a way to make Field(s) iterable with range but it's not important for now

[lampajr]

TBH I couldn't find a different way to iterate over those fields, at least using the reflect pkg and types. But yeah we can figure out if we can improve it in a later iteration

[tarilabs]

I understand this extract all code comments pertaining to Methods. Nice, just as expected also from JavaParser AST I believe structure is analogous

[lampajr]

yeah correct, it extracts all of them and then I just had to filter the one we are insterested in.

[lampajr]

Going to merge this to unblock the development of opendatahub-io/model-registry#173